SIDN Labs een kijkje achter de schermen

Voor het .nl-domein is zo’n IANA-procedure af en toe nodig, bijvoorbeeld wanneer een name server een ander IP-adres krijgt.

Ook hebben we in het verleden de name servers uit het 'domain-registry.nl-domein’ gehaald en in het veel kortere 'nic.nl-domein’ geplaatst. Dat scheelde een aantal bytes, die weer van pas kwamen voor het toevoegen van 'AAAA' glue-records ten behoeve van IPV6.

Dit keer was er nog een andere reden. We willen toe naar een andere setup met minder 'name server afhankelijkheden'. Wat we daarmee bedoelen kan het beste duidelijk gemaakt worden aan de hand van een afbeelding. Onze collega's van Verisign Labs hebben daarvoor een mooie tool in het leven geroepen met de indrukwekkende aanduiding: The Transitive Trust and DNS Dependency Graph Portal:

http://trans-trust.verisignlabs.com/

Deze tool visualiseert heel fraai hoe veelzijdig het resolven van een domeinnaam kan verlopen. Voor een .nl-domeinnaam moest eerst 'nic.nl' worden geresolved, maar daarvoor moeten eerst tal van andere domeinnamen worden afgelopen. Al met al vereist dat voor een resolver met een nog lege cache een flink aantal stappen, waarbij de resolver zelfs tot in Japan kan uitkomen alvorens hij resultaat heeft. Dat kan kostbare milliseconden vergen.
 


http://trans-trust.verisignlabs.com/pix/nl.-names.png

Hoewel het DNS prima werkt in de huidige situatie, geloven we dat het vereenvoudigen van de ‘name server afhankelijkheden’ een goede stap voorwaarts is. Het maakt de situatie meer 'lean and mean' en in het meest gunstigste geval levert het ook nog een sneller DNS op.

Als de transitie straks helemaal is voltooid, zal de situatie voor .nl meer lijken op die van (bijvoorbeeld) Zweden:

http://trans-trust.verisignlabs.com/pix/se.-names.png
 
De domeinnaam 'dns.nl' die we voor de nieuwe NS records gebruiken, is een zogeheten 'empty non-terminal'. Er is geen 'apex' of ‘start of authority’ en geen aparte zonefile, want de 'ns[13].dns.nl' records staan rechtstreeks in de .nl-zone. Exact zoals de Zweedse collega's al een tijdje doen. Dat heeft een groot voordeel; alles wat belangrijk is voor de .nl-zone staat nu ook in die zone. En passant zijn de nieuwe NS records ook DNSSEC gesigned, wat voor ‘nic.nl’ nog niet het geval was.

We hebben ook nog even overwogen om het model van .fi, de Finse collega's te volgen. Zij gebruiken 1-teken .fi-domeinnamen als NS-records, zoals 'a.fi', b.fi' enz. Daarmee wordt de NS RR-set nog wat compacter.

Uiteindelijk hebben we hier voor niet gekozen, omdat dit effectief zou betekenen dat er voor .nl 1-teken domeinnamen zouden ontstaan en dat zou een nogal revolutionaire, niet geheel onomstreden verandering betekenen.

1-teken domeinnamen zijn tot op de dag van vandaag niet toegestaan in .nl, dank zij een, zo je wilt, ‘voorzienige blik’ van Piet Beertema, die destijds goed op de hoogte was van RFC952, waarin letterlijk staat:

"Single character names or nicknames are not allowed."

Nu hebben we het hier niet over hostnamen, maar over domeinnamen en DNS. In de DNS RFC's, zoals RFC1034 (en haar voorloper RFC882) wordt echter wel naar bovengenoemde RFC verwezen. Er staat dat: 'labels' (de stukjes tekst tussen de punten in een domeinnaam) moeten voldoen aan de eisen voor een hostnaam, dus aan RFC952. Geen 1-teken namen dus.

Piet Beertema en zijn collega Jaap Akkerhuis hadden het dus scherp gezien: “1-teken domeinnamen 'mogen' eigenlijk niet”, constateerden ze (al werkt het  technisch prima). Jon Postel, toen nog beheerder van alle gTLD's (.com, .net.  enz.), verkreeg dit inzicht pas in 1992, maar toen waren er al enkele 1-teken  domeinnamen geregistreerd:

http://en.wikipedia.org/wiki/Single-letter_second-level_domain
 
Dus, hoewel 1-letter domeinnamen (als NS records) prima hadden kunnen werken, hebben we er vooralsnog voor gekozen het besluit van Piet Beertema van destijds in ere te houden.

DNS.nl en geen NIC.nl
De keuze voor 'dns.nl', een beschermde .nl-domeinnaam, is gemaakt om het transitieproces te vergemakkelijken. Het geeft ons een goede gelegenheid om  onder dat domein nieuwe name servers op te tuigen en dan via de  IANA-procedure de soepele omzetting te doen van 'nic.nl' naar de 'dns.nl'  variant. Uiteraard nemen we deze gelegenheid te baat om ook flink wat  verbeteringen in de infrastructuur aan te brengen, zoals nieuwe hardware en clustering. Maar daarover wellicht een volgende keer.

Caching
Caching is nodig om DNS schaalbaar te maken. Zonder caching zouden alle DNS queries bij de root name servers uitkomen en die zouden het daar heel zwaar mee krijgen. Caching zorgt er voor dat een resolver eerder gegeven DNS-antwoorden kan onthouden. Als dezelfde DNS query dan weer voorbij komt, geeft de resolver het antwoord direct uit zijn cache en hoeft hij niet eerst weer langs de root. De gecachte antwoorden kunnen uiteraard niet oneindig bewaard blijven, anders zou je bijvoorbeeld nooit domeinnamen kunnen verhuizen, opheffen of resource records kunnen aanpassen. Daarom werkt DNS met een ‘Time To Live’ (TTL) parameter, die aangeeft hoe lang een resolver het antwoord mag bewaren in zijn cache.

Sticky resolvers
De vraag is nu wat je moet doen als deze TTL nog niet verstreken is in een resolver, maar deze nieuwe informatie heeft gekregen dat het antwoord nog steeds bestaat bij de authoritative name server. Een manier is om dan de TTL te ‘stretchen’ zodat het antwoord vanaf dat moment opnieuw de TTL in de cache van de resolver kan blijven staan. Daarmee belast je de authoritative name server zo min mogelijk. Dit gedrag heet ‘sticky’ omdat je vast blijft plakken aan het antwoord dat je al kent. Er zijn ook niet-sticky resolvers die altijd de TTL laten verstrijken en dan daarna compleet opnieuw resolven.

Voor de meeste DNS records is sticky-resolver-gedrag efficiënt, want het beperkt DNS-verkeer. Maar bij delegatie (NS) records kan het problemen opleveren als DNS niet goed wordt onderhouden. Voor elk domein zijn er in twee sets van NS records, namelijk die in de zonefile zelf (child zone) en die in de parent zone. Voor ‘sidn.nl’ staat er dus een NS RRset in de .nl-zone (de parent), maar ook een in de ‘sidn.nl’ zone zelf (de child). Vrijwel alle resolvers slaan de NS RRset die ze verkrijgen van de child zone op in hun cache omdat die wordt gezien als betrouwbaarder dan van de parent. De child-zone-beheerder zal zelf wel het beste weten wat zijn name servers zijn, is de redenatie. Sticky resolvers blijven vasthangen aan die name servers als ze maar vaak genoeg worden bevraagd, of de NS records een hoge TTL hebben. Dat is fijn voor de parent die daarmee minder queries krijgt. Registries als SIDN willen daarom liever ook niet dat domeinnaamhouders te lage waarden configureren voor de TTL van de NS RRset, omdat ze dan veel meer queries te verduren krijgen van resolvers.

Bijeffect
Zoals gezegd is ‘child sticky’-gedrag feitelijk heel normaal DNS-gedrag. Het is het niet in strijd met de RFC’s. Het zou ook prima werken als iedereen braaf zijn DNS-configuratie op orde zou houden..
Er is echter een trend bij DNS-beheerders, om oude zones niet onmiddellijk te verwijderen van name servers zodra ze niet langer het administratieve recht hebben voor die domeinnaam. Ze draaien bij een verhuizing niet meer, zoals zou moeten, een tijdje secondary (gedurende de NS RRset TTL). De redenen hiervoor zijn divers. Soms is het onkunde, soms gemakzucht, heel af en toe is het zelfs kwade opzet. Als gevolg hiervan blijven de oude name servers authoritative antwoord geven voor de inmiddels opgeheven of verhuisde domeinnaam.

Ghost domains
Het gevolg is ‘ghost domains’, domeinnamen die (al dan niet opzettelijk kort) worden geregistreerd en daarna door bewust hoge TTL-waarden blijven rondzwerven in sticky resolvers, zelfs al zijn ze bij de registry al (lang) opgeheven. Het risico is, dat deze ‘ghost domains’ worden misbruikt door malafide personen om bijvoorbeeld malware te verspreiden of botnets aan te sturen zonder dat ze door ‘Notice and Takedown’-procedures kunnen worden gestopt. Dat is het risico dat de heer Duan beschreef.

Wat te doen?
De consequentie van dit alles is dat steeds meer fabrikanten, zoals nu ISC, hun resolvers niet sticky meer willen maken. Met als risico een toename in DNS-verkeer en meer bevragingen bij voornamelijk parent name servers. Op zich kunnen TLD's dat wel aan, als ze door middel van bijvoorbeeld DNS-anycast hun capaciteit verhogen, maar al dit soort kleine aanpassingen leidt op den duur wel tot meer kosten en een complexere DNS-infrastructuur. Ik ben dan ook erg benieuwd wat wij op onze name servers voor .nl zullen merken als ISC zijn klaarstaande patch ook inderdaad uitbrengt.

Misschien hebben DNS-beheerders en registries ook een verantwoordelijkheid. Een DNS-beheerder die een klant kwijtraakt moet netjes zijn zone opruimen, ook al verdient hij niets meer aan die klant. Je kunt je afvragen of dat wellicht moet worden afgedwongen door de parent, in dit geval dus een registry. Maar ook dat ligt gevoelig. De meeste registries voeren geen technische controles meer uit tijdens een verhuizing of verwijderen van een domeinnaam, want registrars ervaren dat als lastig en het maakt het proces trager. Het is een afweging tussen geld steken in meer DNS-infrastructuur of in meer controle op correcte procedures. Betaald worden voor security moet er uiteindelijk toch.

Mijn persoonlijke mening is dat ISC geen patch moet uitbrengen zonder eerst alle consequenties goed af te wegen. Immers, wanneer je het ‘child sticky’-gedrag van BIND (een zeer populaire name server op internet) zomaar zou veranderen, dan kan dat onverwachte en ongewenste gevolgen hebben voor de belasting van parent name servers.

Daarom is het goed dat ISC eerst een gedegen analyse van de mogelijke consequenties gaat maken en te rade gaat bij onder andere de Internet Engineering Task Force (IETF).