Alles wat te maken heeft met netwerken en wat ik daaraan bijdraag.

Be careful with wildcard AAAA records! en

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

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.

Precieze GeoIP resultaten

Door merlijn85 op zaterdag 13 februari 2010 08:54 - Reacties (16)
Categorie: Netwerken, Views: 6.448

In een klein verveeld moment vanmorgen, heb ik eens wat rondgespeeld met een aantal GeoIP tools. Voor wie niet weet wat dat, je geeft een IP als input en je krijgt informatie over waar op de wereld dit IP vandaan komt.

Om even een leuk voorbeeld te geven, bij Youtube kan je informatie opvragen over hoe snel jou internet is, en dat vergelijken met mensen uit dezelfde stad/provincie/land.

Vreemd genoeg zit er echter een behoorlijk verschil in hoe precies deze data is. Bij RIPE is publieke informatie beschikbaar over het land van herkomst, en over het algemeen administratieve info van de ISP. Zo zit ik bijvoorbeeld bij TweakDSL, en die zijn gevestigd in Almere. Een flink aantal van de GeoIP tools die ik heb geprobeerd komen dan ook met de conclusie dat ik me in Almere bevind. Echter is Google/Youtube in staat om ergens informatie vandaan te halen waardoor zij weten dat ik uit Den Haag kom. Sommige andere websites kunnen dit ook, maar deze geven uiteraard niet prijs waar deze informatie vandaan komt.

Inmiddels ben ik toch wel erg benieuwd waar deze informatie vandaan komt, immers zou alleen bij de ISP bekend moeten zijn waar een klant woont. Wordt deze informatie misschien stiekem doorverkocht aan bedrijven die GeoIP databases maken?

Een technische oplossing die mogelijk zou zijn, is om een traceroute uit te voeren en hierbij de te kijken naar de laatste hop voordat het bij de bestemming aankomt. Op deze manier kan je een router benaderen die redelijk in de buurt staat van de bestemming, en van de meeste routers is de precieze locatie bekend. Echter is dat een nogal dirty hack, en dit zou makkelijk geblokkeerd kunnen worden door een ISP of eindgebruiker (door ICMP/traceroute verkeer te blokkeren).

Iemand enig idee hoe deze websites aan hun data komen die beter is dan de algemeen beschikbare informatie van de ISP?