Hernoemen van de DNS-root: mogelijkheden, valkuilen en een testbed

Huidige naamgeving van de DNS rootservers

Aan de top van het DNS staan de rootservers. 12 internationale organisaties zijn verantwoordelijk voor het managen van deze servers en het publiceren van de rootzone, het startpunt voor DNS-query’s. Deze organisaties beheren in totaal 13 rootservers, te herkennen aan de letters A tot en met M (één organisatie is verantwoordelijk voor 2 rootservers). Elk van deze servers is bereikbaar onder de domeinnaam letter.root-servers.net, dus bijvoorbeeld k.root-servers.net voor de rootserver die wordt beheerd door het RIPE NCC.

Figuur 1 laat de opbouw van het huidige naamgevingsschema zien. Root (de lege kring helemaal rechts), .net en root-servers zijn hun eigen zone. De rootzone delegeert naar .net, die ook weer delegeert naar root-servers.net.

Figuur 1: Opbouw van het huidige schema (genoemd 5.1 in het RSSAC028-document) en het schema 5.2.

Resolvers bevragen de rootservers bijvoorbeeld als een topleveldomein zoals .org of .nl voor hen nog volledig onbekend is (ze hebben geen informatie in hun cache), maar ook direct na het opstarten. Recursieve resolvers worden geleverd met een lijst van rootservers en hun bijbehorende IPv4- en IPv6-adressen, het zogenaamde root-hints-bestand. Na het opstarten, maar normaliter ook een keer per dag, sturen de recursieve resolvers een query naar een van de rootservers in hun root-hints-bestand om te verifiëren of de IP-adressen in het bestand nog actueel zijn - de zogenaamde priming-query.

Dat betekent in de huidige situatie dat een priming query, naar bijvoorbeeld k.root-servers.net, ook naar de servers van .net gaat. De .net-TLD is met DNSSEC beveiligd, maar root-servers.net is dat niet. Dit zou priming-query’s mogelijk kwetsbaar maken voor “Node re-delegation attacks”, waar query’s van een resolver omgeleid worden naar malafide rootservers. Ook zal een storing bij .net gevolgen hebben voor de priming-query’s.

Alternatieve naamgeving

Het Root Server System Advisory Committee (RSSAC) van ICANN heeft in zijn publicatie RSSAC028 uiteengezet hoe de namen van de rootservers aangepast kunnen worden, zodat de informatie over de rootservers ook met DNSSEC beveiligd kunnen worden en zodat de rootservers in sommigen gevallen niet meer afhankelijk zijn van .net.

Het Root Server System Advisory Committee heeft 5 schema's bedacht. In dit artikel en in ons rapport noemen we de schema's naar de secties waarin RSSAC028 ze opvoert: 5.2 tot en met 5.6. 5.1 i het huidige naamgevingsschema. 2 schema's hebben nog een variant: 5.3.1 en 5.5.1. We bespreken de schema’s hier kort.

Schema 5.2. is het huidige naamgevingsschema, met de uitbreiding dat ook de zone van root-servers.net met DNSSEC is gesigneerd (zie Figuur 1). DNSSEC beveiligd ook alle zones van de schema’s 5.3, 5.4, 5.5 en 5.6.

Figuur 2¹: In-zone NS Names (schema 5.3 en 5.3.1).

Schema’s 5.3 en 5.3.1 zijn schema’s waarin de naam root-servers onderdeel wordt van de rootzone zelf - de namen zijn “in-zone”. 5.3.1. gaat nog iets verder en verkort de naam van de rootservers.

Figuur 3: Shared Delegated TLD (schema 5.4)

Schema 5.4 scheidt de rootzone en de zone weer van de rootservers. Dit schema introduceert een nieuw topleveldomein (TLD), gedeeld door alle rootserverbeheerders.

Figuur 4: Names Delegated to Each Operator (schema 5.5 en 5.5.1).

Schema’s 5.5 en 5.5.1 gaan nog een stap verder. Hier heeft elke rootserver zijn eigen TLD.

Figuur 5: Single Shared Label for All Operators (schema 5.6 en 5.6.1).

Schema’s 5.6 en 5.6.1. Bij deze schema’s verdwijnen de domeinnamen voor enkele rootservers. In plaats daarvan gebruiken 5.6 en 5.6.1 een gezamenlijke domeinnaam om alle rootservers te identificeren. De domeinnaam heeft dan 13 IPv4- en 13 IPv6-adressen.

Doel van ons onderzoek

Het doel van ons onderzoek was om te begrijpen wat er gebeurt als de rootservers naar een van de schema’s zouden overstappen. We wilden vooral weten of priming-query’s van huidige resolvers nog steeds succesvol zouden zijn. Dat betekent dat resolvers gebruik zullen maken van de nieuwe namen en deze ook onthouden.

Daarnaast wilden we weten hoe gevoelig resolvers voor fouten zouden zijn. Denk bijvoorbeeld aan resolvers die de DNSSEC-handtekeningen van de nieuwe records niet zouden kunnen valideren.

Configuraties van de rootnameservers

We wilden de naamgevingsschema’s in een omgeving testen die zo realistisch mogelijk was. Hiervoor wilden we het gedrag van de huidige rootnameservers kunnen simuleren en testen tegen verschillende resolverversies.

Hiervoor hadden we de configuraties van de rootservers nodig, maar die zijn over het algemeen niet publiek bekend. We hebben daarom een vragenlijst met rootoperators gedeeld om, bijvoorbeeld, de soorten nameserversoftware die ze gebruiken in kaart te brengen.

Tabel 1 vat de configuraties van de rootservers samen. Een deel van deze informatie is vertrouwelijk (maar bij ons bekend), bijvoorbeeld omdat operators “proprietary“-software draaien. Deze operators hebben ons echter wel geholpen om het gedrag van hun software af te leiden, waardoor we alsnog de naamgevingsschema's in een realistische omgeving konden testen. Hiervoor hebben we gebruikgemaakt van NLnet Labs eigen ldns-testns (met enkele aanpassingen), een tool waarmee we het gedrag van de proprietary software konden simuleren.

Tabel 1: Configuraties van de rootservers.

Ons rootservertestbed

De configuratie van de rootservers uit tabel 1 vormt de basis van ons testbed. Met behulp van Vagrant en ideeën uit een eerder testbed van ICANN, hebben we ons eigen opensourcetestbed gebouwd om alle rootservers geautomatiseerd te kunnen testen met de 5 verschillende naamgevingsschema’s. Inmiddels zijn onze aanpassingen geïntegreerd in het testbed van ICANN.

Met ons testbed is het mogelijk om eenvoudig verschillende versies van resolvers toe te voegen. Voor dit onderzoek hebben we een aantal populaire open source resolversoftwarepakketten getest, namelijk BIND, Knot Resolver, PowerDNS Recursor en Unbound. Van elke software testten we zowel oudere versies als ook de nieuwste versies.

Per schema hebben we gemeten of resolvers (i) succesvol een testdomeinnaam kunnen resolven en (ii) of resolvers ook daadwerkelijk het nieuwe naamschema overnemen, dus of ze ook voor opvolgende query’s gebruik zouden maken van het nieuwe naamschema.

Daarnaast onderzochten we een aantal parameters, zoals het aantal query’s dat werd verstuurd tijdens het primen, en of de query via UDP of TCP werd verstuurd.

Je vindt ons testbed hier en het rapport bevat een uitgebreidere omschrijving van het testbed. Het hele testbed is open source, zodat je het ook zelf kunt gebruiken.

Resultaat #1: priming-query’s lukken vaak, maar niet altijd

Figuur 6 geeft een eerste overzicht van de resultaten. De 13 rootservers hebben we volgens de antwoorden op onze vragenlijst geconfigureerd.

Figuur 6: Priming query’s per schema en resolver.

Figuur 6 laat zien dat priming in de meeste gevallen lukt, maar enkele resolvers vertonen onverwacht gedrag. En zelfs als het een resolver lukt om te primen, betekent dat niet dat priming met alle rootservers lukt. Maar omdat niet elke rootserver dezelfde software en configuratie gebruikt, lukt het de resolvers uiteindelijk alsnog om een antwoord op hun priming-query te ontvangen.

Zo laten we in ons rapport zien dat rootservers die gebruikmaken van BIND geen IP-adressen in het additional-field van het DNS-pakket meesturen voor schema’s 5.3, 5.3.1, 5.6 en 5.6.1. De schema’s hebben gemeen dat hier de rootzone direct authoritative is voor de rootserverdomeinnaam. Dit heeft als gevolg dat de meeste resolvers voor deze schema’s een groot aantal query’s naar de rootservers sturen die BIND-software draaien om de IP-adressen te achterhalen. Alleen PowerDNS Recursor doet dit niet en het lukt daarmee dan ook niet om succesvol te primen.

Resultaat #2: meer TCP-verkeer op de rootservers

Zoals te verwachten, zien we in figuur 6 ook meer resolvers die hun priming-query’s via TCP versturen. Veel versies van de resolver van BIND sturen sowieso altijd priming-query’s met een buffer size van 512 byte, wat bijna altijd leidt tot fragmentatie en dus tot een vervolg query via TCP. Alleen schema 5.3.1 is een uitzondering: hier zijn de antwoorden kleiner dan 512 byte en hoeven dus ook niet via TCP worden verstuurd.

Sommige rootservers antwoorden altijd met een TC-vlag als niet alle aanvullende informatie in het pakket past. Dit heeft als gevolg dat in heel veel gevallen resolvers gebruik gaan maken van TCP - iets wat mogelijk niet wenselijk is voor de rootserverbeheerders.

Resultaat #3: DNSSEC-fouten kunnen priming beïnvloeden

Zoals eerder genoemd, zijn alle antwoorden van de nieuwe schema’s met DNSSEC beveiligd. We vroegen ons daarom af wat er zou gebeuren als resolvers de handtekeningen niet zouden kunnen valideren en of dat invloed op de priming-query’s zou hebben. Hiervoor hebben we opzettelijk de tijd op de machines van de resolvers aangepast, zodat het voor hen leek alsof alle handtekeningen verlopen waren.

We zagen dat dit voor de meeste gevallen geen invloed had op priming-query’s. Alleen sommige versies van Knot Resolver en PowerDNS Recursor konden niet meer succesvol primen, wat erop duidt dat de resolvers ook priming-query’s proberen te valideren.

Tabel 2 vat wat algemenere inzichten over resolvergedrag samen.

Tabel 2: Samenvatting van de eigenschappen van resolvers.

Conclusies

Uit de experimenten met ons rootservertestbed blijkt dat het invoeren van de 5 nieuwe naamgevingsschema’s niet zonder problemen zal verlopen. De schema’s 5.3 en 5.3.1 leiden in veel gevallen bijvoorbeeld tot veel meer query’s dan in de huidige situatie. PowerDNS Recursor is zelfs niet in staat om de nieuwe namen te leren als hij specifieke rootservers bevraagt. Schema 5.6 en 5.6.1 hebben vergelijkbare problemen.

Schema 5.4 kan op dit moment niet worden uitgerold omdat Knot niet in staat is om te primen. Zelfs het huidige schema (5.1 en 5.2) zal al tot problemen leiden als het de rootzone verandert, zoals bijvoorbeeld het aanpassen van de IP-adressen van rootservers. Alleen voor 5.5 en 5.5.1 zien we geen grote “deal-breakers”.

Veel meer metingen en inzichten vinden jullie in ons rapport.

Hoe verder?

De ICANN-gemeenschap gaat zich nu over ons rapport buigen en mogelijke vervolgstappen bespreken. In de tussentijd nodigen we iedereen, die interesse in de rootservers heeft, uit om ons testbed te verkennen. Tot slot bedanken we alle operators van de root en bij ICANN voor de goede samenwerking.