SERVFAIL IPv6 debugging

[Greg Choules]

Hi Bruce.
There's potentially a bunch of things to note here.
DNS conversations are independent of each other. The dig to your own server
(dig -6 ec.europa.eu) may be over v4 or v6. But the subsequent queries that
server makes (if any) may be over v4, or v6, or both. It depends how your
server is configured and what it's talking to.
DNSviz <https://dnsviz.net/d/europa.eu/dnssec/> is a handy tool for
visualizing what's happening in the delegation path down from the root to
your chosen domain and for europa.eu it highlights a couple of issues:
1) The NS RRSET in the child (europa.eu) is different to the NS RRSET in
the parent (eu)
2) One of the servers - 2001:978:2:1::93:2 - may have trouble with UDP
queries over v6. Having said that, from where I am I can make UDP queries
over v6 to it, both from dig and from my local BIND. However, it does
report a BADCOOKIE on the first attempt each time. For example:

dig @2001:978:2:1::93:2 europa.eu ds
;; BADCOOKIE, retrying.

; <<>> DiG 9.18.8 <<>> @2001:978:2:1::93:2 europa.eu ds
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21675
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6f81f2f4c5e1db7b7971793f63ca3c47a2566885353f2952 (good)
;; QUESTION SECTION:
;europa.eu. IN DS

;; ANSWER SECTION:
europa.eu. 86400 IN DS 14845 8 2
9EF3C28F5B3A3D33756D61715B1BDBDBB07E0555598D30256D1F2B71 95324846
europa.eu. 86400 IN DS 6250 8 2
0186EEFF28A83D2C950963CEEF2F2070DC0885AC8AD7106B03A9741C 25DC6B82

;; Query time: 21 msec
;; SERVER: 2001:978:2:1::93:2#53(2001:978:2:1::93:2) (UDP)
;; WHEN: Fri Jan 20 07:01:27 GMT 2023
;; MSG SIZE  rcvd: 162

So it *may* be that this server is the culprit. You will need to
gather more evidence though, to get a better idea. I would suggest that you
take a packet capture of all DNS traffic, flush the cache, then make digs @
your local server until you see the SERVFAIL and have fun in Wireshark.
If you can afford to put up with the noise, turn debugging up to the max -
rndc trace 99 - and see if anything pops out.
Also, when you say "even with dnssec turned off.." what do you mean,
exactly?

HTH
Greg

On Wed, 18 Jan 2023 at 12:32, Bruce Duncan <Bruce.Duncan at ed.ac.uk> wrote:

> Hi bind-users,
>
> Apologies if this is inappropriate for this list. I am trying to debug a
> failure to resolve an external name.
>
> It appears that when I try to resolve the name ec.europa.eu over IPv6
> using either dig +trace or with a caching named that it sometimes fails:
>
> [nimbus]root: dig -6 ec.europa.eu
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> -6 ec.europa.eu
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29328
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ec.europa.eu.            IN    A
>
> ;; Query time: 13 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Wed Jan 18 12:09:35 GMT 2023
> ;; MSG SIZE  rcvd: 41
>
> Sometimes I need to rndc flush and try again a few times before it
> fails. The named log says:
>
> 2023-01-18T12:09:35.145500+00:00 nimbus named[11833]: client
> @0x7f35e6fec700 ::1#35963 (ec.europa.eu): view internet: query failed
> (SERVFAIL) for ec.europa.eu/IN/A at ../../../bin/named/query.c:8580
>
> Various posts on the web suggest that query.c:8580 is related to dnssec
> validation, however even with dnssec turned off in /etc/named.conf the
> query still fails. I've tried setting rndc trace 9 but I get no more
> information about why the query has failed. Query logging is enabled but
> there is no information there either.
>
> I suspect there is some misconfiguration of the domain. dig -6 +trace
> sometimes complains that it can't find an address for some servers, but
> I don't understand why this would make the query fail completely sometimes.
>
> Any help appreciated!
>
> Thanks,
>
> Bruce
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230120/c7550b4c/attachment.htm>