Be careful with wildcard AAAA records! en

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

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 testtest.mhofstra.nl - 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 '.mhofstra.nl'.

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:

AAAA? google.com
AAAA? google.com.mhofstra.nl
A? google.com

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 *.mhofstra.nl - pointing to one of my servers.

This caused the program to believe that google.com 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.

Volgende: GUADEC 2010 06-'10 GUADEC 2010

Comments


By Tweakers user H!GHGuY, Friday 30 December 2011 13:11

Ook windows doet dit:
# ipconfig /all
...
DNS-achtervoegselzoeklijst . . . .: <mijnprovider.landcode>
...

Het is gewoon standaard gedrag van DNS resolving.
Dit soort geintjes zijn ook een deel van de reden waarom IPv6 adoptie niet als een rotvaart gaat. Mensen zijn er namelijk niet happig op om dingen die 'gewoon werken' te breken door het correcte gedrag te forcen.

[Comment edited on Friday 30 December 2011 13:16]


By Tweakers user merlijn85, Friday 30 December 2011 20:19

Opzich als je de achtergrond kent ben ik best met je eens dat dit "expected behavior" kan zijn, maar alsnog klopt het volgens mij niet. De volgorde is nu blijkbaar:

1) AAAA? domain
2) AAAA? domain.searchdomain
3) A? domain
4) A? domain.searchdomain

Als je 2 en 3 omwisselt heb je volgens mij een meer robuust algorithme dat nergens fout zou moeten gaan.

Ook al is het standaard gedrag kwam ik erg weinig tegen met het googlen naar dit probleem - vandaar dat een blog met wat mogelijke oplossingen me wel zo aardig leek :-).

By Tweakers user Cybje, Friday 30 December 2011 20:47

Volgens mij wil je juist dat altijd de voorkeur aan IPv6 moet worden gegeven, omdat IPv4 in principe uitgefaseerd moet gaan worden. Dus de volgorde die het nu is, oftewel eerst AAAA op domain, daarna AAAA op domain.searchdomain en daarna pas de A records, is de gewenste volgorde.

By Tweakers user StarlightVideos, Saturday 31 December 2011 06:57

^Ja maar dat kan je de mongool die dit blog geschreven heeft niet kwalijk nemen. ;)

By Tweakers user merlijn85, Saturday 31 December 2011 12:10

StarlightVideos wrote on Saturday 31 December 2011 @ 06:57:
^Ja maar dat kan je de mongool die dit blog geschreven heeft niet kwalijk nemen. ;)
Dank voor je bijdrage, en voor je manieren.

En natuurlijk wil ik dat IPv6 de voorkeur krijgt, maar het is een beetje voorbarig om te praten over het uitfaseren van IPv4. Er zit eerst nog een flink aantal jaar aan te komen waarin we dual stack gaan draaien.

Daarbij laat ik mijn standpunt over hoe dit zou moeten gebeuren redelijk in het midden, maar persoonlijk vind ik het search domain niet een erg zinnige toevoeging aan de DNS. Daardoor beschouw ik het wel als een bug dat dit search domain wordt afgeleid uit mijn hostname, terwijl ik geen search domain opgeef in de /etc/resolv.conf.

Comments are closed