Be careful with wildcard AAAA records! en

By merlijn85 on Friday 30 December 2011 10:17 - Comments (5)
Category: Netwerken, Views: 5.087

After some interesting debugging, I have found some not so predictable behavior of DNS questions from various basic unix utilities.

First I'll try to explain the situation this occured in. I deployed a test server (Ubuntu Linux in this case) and just named it - DNS setup was fine, and there was no search domain defined in /etc/resolv.conf or /etc/network/interfaces. For an unknown reason to me, the server still assumed the search domain was ''.

When I gave the server its IPv6 addresses, something weird started to happen. Suddenly I couldn't connect to hostnames that didn't define AAAA records. After tcpdumping and other methods of debugging I found that some programs (for example wget, but also apt-get and surely many many others) were actually doing asking these questions to the DNS recursors:


The first query does not return anything, because Google doesn't have IPv6 enabled by default at this point in time, hence the second query is executed. The second query does return something, as there is a wildcard AAAA record for * - pointing to one of my servers.

This caused the program to believe that actually has both IPv6 and IPv4 available - and the common default is to prefer IPv6 over IPv4. Hence the problem occured that many things were suddenly unavailable.

I'm pretty sure this is a fairly common problem for all flavours of Unix, and possibly other systems as well. Unfortunately this behavior can be desired from a technical point of view - but it would be better if it were to first check whether A records exist before using the search domain.

The obvious solution here is to get rid of your wildcard AAAA record - and in most cases this is probably a good idea. However if you need it for some reason, you can disable the use of the search domain feature for your DNS by setting "search ." in your /etc/resolv.conf. This actually forces an empty search domain, causing the second query in the example above to not be executed - and thus works around the problem.