odd increase in SERVFAIL with "misc failure" reason

[Havard Eidnes]

> On 06/11/2024 18:26, Wolfgang Breyha via Unbound-users wrote:
>> I'm tempted to raise the bar to full 8 bits;-)
>
> Seems too low as well.
>
> dl.acronis.com. A
> reached
> "number of upstream queries 292"
> immediately after server reload.
>
> This happend while I was trying to see if at.mirror.cicku.me AAAA is
> reproducible if I flush caches using "unbound-control reload". Which in
> fact is and reached the formerly reported >200 requests as well.

Hmm, my gut reaction is that there must be something wrong with how
the resulting queries are attributed to the original recursive query.
E.g. if I ask a name server which doesn't know acronis.com about the A
record for dl.acronis.com, I get back:

$ dig dl.acronis.com. a +norec

; <<>> DiG 9.18.24 <<>> dl.acronis.com. a +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51324
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9c1f694d66e16b4e01000000672bc46570aadef12d60dc52 (good)
;; QUESTION SECTION:
;dl.acronis.com.                        IN      A

;; AUTHORITY SECTION:
com.                    89946   IN      NS      j.gtld-servers.net.
com.                    89946   IN      NS      a.gtld-servers.net.
com.                    89946   IN      NS      e.gtld-servers.net.
com.                    89946   IN      NS      l.gtld-servers.net.
com.                    89946   IN      NS      g.gtld-servers.net.
com.                    89946   IN      NS      f.gtld-servers.net.
com.                    89946   IN      NS      b.gtld-servers.net.
com.                    89946   IN      NS      c.gtld-servers.net.
com.                    89946   IN      NS      d.gtld-servers.net.
com.                    89946   IN      NS      h.gtld-servers.net.
com.                    89946   IN      NS      m.gtld-servers.net.
com.                    89946   IN      NS      i.gtld-servers.net.
com.                    89946   IN      NS      k.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.     64485   IN      A       192.5.6.30
b.gtld-servers.net.     64485   IN      A       192.33.14.30
c.gtld-servers.net.     64485   IN      A       192.26.92.30
d.gtld-servers.net.     64485   IN      A       192.31.80.30
e.gtld-servers.net.     64485   IN      A       192.12.94.30
f.gtld-servers.net.     64485   IN      A       192.35.51.30
g.gtld-servers.net.     64485   IN      A       192.42.93.30
h.gtld-servers.net.     64485   IN      A       192.54.112.30
i.gtld-servers.net.     64485   IN      A       192.43.172.30
j.gtld-servers.net.     64485   IN      A       192.48.79.30
k.gtld-servers.net.     64485   IN      A       192.52.178.30
l.gtld-servers.net.     64485   IN      A       192.41.162.30
m.gtld-servers.net.     64485   IN      A       192.55.83.30
a.gtld-servers.net.     64485   IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net.     64485   IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net.     64485   IN      AAAA    2001:503:83eb::30
d.gtld-servers.net.     64485   IN      AAAA    2001:500:856e::30
e.gtld-servers.net.     64485   IN      AAAA    2001:502:1ca1::30
f.gtld-servers.net.     64485   IN      AAAA    2001:503:d414::30
g.gtld-servers.net.     64485   IN      AAAA    2001:503:eea3::30
h.gtld-servers.net.     64485   IN      AAAA    2001:502:8cc::30
i.gtld-servers.net.     64485   IN      AAAA    2001:503:39c1::30
j.gtld-servers.net.     64485   IN      AAAA    2001:502:7094::30
k.gtld-servers.net.     64485   IN      AAAA    2001:503:d2d::30
l.gtld-servers.net.     64485   IN      AAAA    2001:500:d937::30
m.gtld-servers.net.     64485   IN      AAAA    2001:501:b1f9::30

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Nov 06 20:32:53 CET 2024
;; MSG SIZE  rcvd: 870

$

Now, how many of those NS records needs to be resolved to an address
to successfully make progress in resolving the original query?  One?
Two?  All of them?  And ... when unbound is configured to do DNSSEC
validation, is it then effectively prevented from using glue records
from the additional section?  I guess that at least in this case
"yes", since they are ... not in a subzone of .com.  And then we pile
on queries about DS and DNSKEY records, but still... 200ish queries to
resolve a single 3-layer name?  Even with two CNAME records inside the
Akamai maze that seems like an awful lot to blame on the original
recursive query?

Regards,

- Håvard