SIDN Labs een kijkje achter de schermen

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).