2

I am running a recursive local name server using BIND on Ubuntu. I have an IPv4 network at the moment. It appears as though BIND defaults to listen for queries and recursively resolve names on both IPv4 and IPv6.

I'm getting a lot of errors in syslog such as

named[1907]: error (network unreachable) resolving 'DELETED.FOR.PRIVACY.in-addr.arpa/PTR/IN': 2001:503:ba3e::2:30#53

In this case, it can't even contact 2001:503:ba3e::2:30 (which is a.root-servers.net), the first server in the recursion process.

Sometimes (actually, maybe always, but I'm not sure), dig will return SERVFAIL when this happens. I don't care if I get those error messages, as long as BIND will fail over until it finds a reachable server, but that doesn't seem to be the case. My question is, since that IPv6 network is currently unreachable, why doesn't BIND revert to another name server that it can find? I thought that was the point of having several name servers. How many name servers does BIND try when it is resolving a query.

I'm aware that I can disable IPv6 in BIND, but that seems to be a bad practice because then my local network is no longer automatically ready for upgrading to IPv6.

Improve this question

1 Answer 1

Reset to default
2

If you do not clearly have IPv6 routing, it is a wise decision to deactivate it in any daemon asking for it; as it is not uncommon having problems with it, also partly because IPv6 has priority over IPv4 when it comes to talk with DNS names that have both IPv4 and IPv6 representation at the same time.

Even without having public IP addresses, it is not uncommon to see daemons trying to do IPv6 connections using as source the IPv6 Link-local address, and believe me I have witnessed along the years problems with that at least with Email and DNS services.

What is more concerning about the kind of errors you are seeing over IPv6, is that often timeouts kick out, and the IPv4 transaction could not even take place.

Furthermore, there is nothing to prevent you enabling IPv6 support again in the near future; also I would not necessary mix up things; having a IPv4 only DNS does not prevent it into resolving IPv6 addresses lest you have a multi stack IPv4/IPv6 machine somewhere in your network in a near future.

So go for it, and make BIND only IPv4; I would run named with -4; in Debian you can edit /etc/default/bind9 and change it to:

OPTIONS="-u bind -4"

I would also take out all the AAAA addresses from db.root as in:

grep -v "AAAA" /etc/bind/db.root > /tmp/a
mv /tmp/a /etc/bind/db.root

I would also edit /etc/gai.conf, and add the following line, to give priority to IPv4 over IPv6:

precedence ::ffff:0:0/96  100

I would advise also reading my answer here:

The first email bounces; the second and subsequent emails go through

As for timeouts, when a TCP DNS request times out, after x tries, the DNS RFC defines the same request will be retried using UDP n tries again.

Your IPv6 requests are timing out obviously because it still tries to do them, but your routing leads nowhere.

Besides roughly 6 tries and timeouts per IPv6 request, you can still fall in the next IPv6 root; in the root name servers list there are so many root name servers to try that it not may be a given that failing an IPv6 address it will automatically retry an IPv4 one - so I would risk to say your huge time variations on getting a full request are pretty much expected behaviour on this scenario.

Disclaimer: this is rough behaviour, I know well the resolver behavior, not so much the dirty details of the BIND code.

Only using tcdump and dnstracer you can have a better idea of what is happening. It might also be helpful looking at named.stats.

It is also worthy noting those timeouts/requests will add up in a busy production server.

However, IMO, you are just overthinking things, and making as certain a lot of suppositions.

The advised way is to not try to use a service you know it is not implemented on your side.

I advise running BIND in IPv4 mode only.

Improve this answer
7
  • I'm aware that disabling IPv6 should make queries resolve faster. I'm also aware that doing what you say solves my problem. However, without applying the above workaround, these SERVFAIL messages are returned by dig in 0-1400ms. Seems like that is a very short time for the resolver to query every possible nameserver in both IPv6 and IPv4, especially for the root servers where there are a number of backups. I feel like there may be a bigger problem with BIND that is preventing it from automatically falling back? I could understand if SERVFAIL was returned after 30 s, but not less than 1400ms.
    – user1748155
    Apr 21, 2017 at 3:29
  • @user1748155 added to the answer
    – Rui F Ribeiro
    Apr 21, 2017 at 5:23
  • I'm a little confused what you mean by "when a DNS request times out, after x tries, the DNS RFC defines the same request will be retried using UDP n tries again.". Doesn't DNS try using UDP first, not second?
    – user1748155
    Dec 9, 2017 at 19:33
  • 1
    It seems like what you are saying is the quick fail I'm seeing is happening because there are tons of IPv6 root name servers and IPv6 is failing quickly, many times, due to a no route to host, rather than a timeout. Also, there is a limit to how many name servers DNS will try before failing completely, so if it fails too many times (slowly or quickly), then it gives up, since it just happened to try only IPv6 servers and not IPv4 servers. Is this correct? Maybe the simple answer is that BIND doesn't try ALL nameservers, if there are a lot of them.
    – user1748155
    Dec 9, 2017 at 19:41
  • @user1748155 Exactly. Clean and optimising can save you many headaches tracing obscure situations.
    – Rui F Ribeiro
    Dec 9, 2017 at 20:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .