Without IPv6 half of the queries yield SERVFAIL

Peter pmc at citylink.dinoex.sub.org
Thu Aug 5 21:53:35 UTC 2021


Hi all,

  first off: I do not have IPv6 physical connectivity yet, but I would
like to run a nameserver nevertheless.

Sadly, it seems that without IPv6 connectivity, half of the queries
fail, in a random fashion.

There is no clue in the logfile about any reason for this behaviour,
only so much as:

client: error: query client=0x80db45160
   thread=0x80125ba00(pole.daemon.contact/A): query_gotanswer:
   unexpected error: SERVFAIL
query-errors: info: client @0x80db45160 192.168.98.10#17919
   (pole.daemon.contact): view intra: query failed (SERVFAIL)
   for pole.daemon.contact/IN/A at query.c:7376

Increasing the debug level does not give me more insight.

The failure happens randomly, half of the time. (Only after 'rndc flush',
obviousely, so it went undetected at first, taken for a network
hiccup.)

I finally resorted to full dnstap logging, and walked myself thru
the whole orgy of recursive resolving. The outcome:

This name in question, pole.daemon.contact, has four nameservers,
each of them has two IPv4 and one IPv6 addresses.

In the cases when the query is successful, the recursion happens just
as we would expect it: at some point an IP address for one of the four
nameservers is obtained, then from that IP address the desired A
record is queried and obtained, and after a bit more of validation
stuff (probably DNSSEC) the client gets the proper answer.

In the cases when the query yields SERVFAIL, the difference is that
the first arriving answer for one of the nameserver's addresses is an
answer to an AAAA query, not an A query (as mentioned, ther are four
possible nameservers, and each has A and AAAA records). At that point
the client is sent NXDOMAIN, disregarding that the other (A and AAAA)
records are just at that moment being received. So the query is fail,
and the service is outage, and it is bad.

The problem appears on different machines, all running FreeBSD 12.2
and BIND 9.16.18.

I tried to use this recommendation, https://kb.isc.org/docs/aa-00206,
marking all IPv6 addrs as bogus, but it does not make a difference in
behaviour.

Is there any means to tell named that we just don't have IPv6
connections yet (which actually should be obvious because there is
not IPv6 address on the interfaces, except for lo0)?

I know I can use -4 cmdline option, but that disables everything,
while I would rather like to slowly and tentatively enter IPv6 (but
on my pace, and not forced by a named insisting in all-or-nothing).
I would rather like named to continue and try the other seven address
options, and not just NXDOMAIN rightaway.


rgds,
PMc


More information about the bind-users mailing list