Invoering van Secure DNS bij grote top-level domains Ted Lindgreen

1. Het Domain Name System
1.1 Het basisprincipe
1.2 Parent-Child relatie
1.3 Registry, registrar, domeinhouder en zone-administrateur
1.4 Waar zitten de gaten
2. Secure DNS
2.1 Hoe werkt het
2.1.2 Het NXT record
2.1.3 Nadelen van het NXT record
2.2 Implementatie problemen
2.3 Systeembelasting
2.3.1 De .nl en .de zones
2.3.2 Welke records moet een toplevel domein signen
2.3.3 De .com zone
2.3.4 Conclusie systeembelasting
3. Organisatorische problemen
3.1 Het .nl.nl testbed
3.2 De relaties
3.2.1 Parent-Child relatie
3.2.2 Registry, registrar, domeinhouder en zone-administrateur
3.3 Conclusie

NLnet Labs

1. Het Domain Name System

Het DNS is beschreven in RFC 1034 en 1035. Voor deze lezing ga ik er van uit dat men hier redelijk mee bekend is.

1.1 Het basisprincipe

Het basisprincipe is dat iedere beheerder op het Internet zoveel mogelijk alleen dat stukje van de gedistribueerde database onderhoudt waar hij/zij verantwoordelijk is. Alleen zo is de schaalbaarheid in de hand te houden. Je krijgt dan een boomstructuur, waarbij iedere tak zorgt voor wat op die tak zelf groeit en zodra er een zijtak ontstaat wordt de autoriteit over die tak aan de nieuwe tak zelf overgedragen. Ieder stukje database heet een zone, en iedere zone bevat een aantal verplichte en een aantal optionele records. Verplichte records zijn bijvoorbeeld de SOA, de Start of Authority waarin dingen als het e-mail adres van de beheerder en timers staan, en de NS records, die aangeven waar de info te vinden is.

1.2 Parent-Child relatie

Op een delegatiepunt, dus waar een nieuwe tak ontspringt, vinden we in de parent zone een kopie van de NS records van de child zone. Op dit punt wordt het principe om geen info die elders thuis hoort te onderhouden dus bewust doorbroken. Naast kopieš n van NS records kan een parent ook nog glue records bevatten, dit zijn kopieš n van de A records die bij de NS records horen. Van belang voor DNSSEC is alvast op te merken dat hoewel zowel parent als child authoritief zijn over wat er in hun zonefile staat, het child meer authoritief is over deze records dan de parent.

We zien een relatie tussen parent en child:

· Voor de child zone is het van levensbelang dat zijn parent juist delegeert, anders is de child zone
onzichtbaar en dus onbereikbaar voor de hele wereld.

· De parent heeft een verantwoordelijkheid tegenover (al) zijn childs om de zones juist te delegeren.

Gezien het belang van de child is hier dus duidelijk behoefte aan een formele relatie. En waar in de begintijd van het Internet het delegeren veelal een vriendendienst was, zie we tegenwoordig vooral bij de top-level domains, dat er een formele relatie is, waarbij het child betaalt voor de dienst van de parent. Bij grotere parentzones zien we de zaak wel weer gecompliceerd worden, doordat er meer partijen bijkomen.

1.3 Registry, registrar, domeinhouder en zone-administrateur

Bij toplevel domeinen praten we veelal over registries. Een eigenschap van zo'n registry, bv die van .com of van .nl, is dat er maar eentje van is, dat deze dus een monopoly heeft en dat hij verschrikkelijk veel delegaties moet verzorgen. Onder andere vanwege maatschappelijke druk, zien we dat vele grote toplevel domeinen zich beperken tot het registreren en delegeren van namen, en de verdere relatie met de domeinhouder hebben uitbesteed aan registrars. In feite was Nederland hierbij een voorloper met haar Stichting en haar Deelnemers.

In de praktijk is er soms nog een vierde partij bij betrokken: sommige domeinhouders hebben feitelijke onderhoud van de zonefile ook weer uitbesteed. We zien in de praktijk meest twee gevallen:

· Zone-administrateur werkt voor domeinhouder.
Dit is het klassieke geval en zien we vooral bij de meer technische bedrijven, universiteiten, etc. De
domeinhouder staat hier tussen de de zone-administrateur en de registrar en stuurt beide aan.

· Zone-administrateur werkt voor registrar.
Veel nieuwere bedrijven die zich op het Internet profileren hebben zowel de domein-aanvraag als
het verzorgen van de zonefile uitbesteed aan een ISP, die ook als registrar optreedt.

1.4 Waar zitten de gaten

Om het DNS zo efficieš nt mogelijk te maken wordt informatie gecached. Met deze gecachede informatie kan geknoeid worden. Een tweede optimalisatie is om bij een vraag naar informatie gelijk ook andere relevante informatie mee te geven. Bij voorbeeld, wil iemand een mailtje sturen, dan is de MX informatie nodig. Deze levert de hostnamen van de mailexchangers op. Maar je kunt nu op twee vingers natellen, dat de vrager dan ook de bijbehorende IP-nummers ofwel de A-records wil weten. De server zal deze records dan ook meteen als additional informatie meegeven. Erg efficieš nt, maar ook kwetsbaar.

Een voorbeeld om valse informatie, bv het IP-nummer van een namaak server voor www.wehkamp.nl, ie in de cache van een veelgebruikte DNS forwarding server te krijgen gaat als volgt:

· Zorg dat je een eigen domein hebt, bv crack.nl, en zet de timeouts flink laag.

· Vraag nu bij de forwarding nameserver naar de MX of NS records van je eigen crack.nl. Vanwege
de lage timeout zit het antwoord niet in de cache, en komt de vraag bij jezelf terug.

· Antwoord nu met www.wehkamp.nl en geef een vals A record met het IP-nummer van je fakehost
mee met de additional info.

Vervolgens kun je op je namaak www.wehkamp.nl creditcard nummers verzamelen, orders verzieken en andere ongein gaan uithalen.

2. Secure DNS

Al vroegtijdig heeft men ingezien dat DNS kwetsbaar was, en al in 1995 was een oplossing in RFC 2535 beschreven.

2.1 Hoe werkt het

Allereerst is van belang te begrijpen wie wat wil kunnen vaststellen. Het is de gebruiker die zeker wil weten dat hij/zij bij een vraag over een bepaalde domeinnaam de juiste informatie terug krijgt. De gebruiker gebruikt een resolver, dat is het enige ding onder zijn controle, dus dit moet dan ook uiteindelijk uitsluitsel geven over de correctheid van de lookup. Daarvoor moet de resolver dus iets weten, wat dat is, daar kom ik zo op terug.

Over iedere set records in de zonefile wordt een signature gemaakt en deze wordt als SIG record toegevoegd. Het public deel van de gebruikte key wordt als KEY record aan de zonefile toegevoegd. Hiermee kan de resolver eenduidig vaststellen of het record bij de key hoort. En dit werkt dus onafhankelijk van waar record en key ook vandaan komen, gecached, gefaked, of wat dan ook.

Volgende stap is na te gaan of de key wel bij de echte zone hoort. Er zijn nu drie mogelijkheden:

· De resolver kent de key van de zone. In het ideale geval, wanneer het hele Internet secure is, zal

dit in ieder geval voor de root gelden. Maar er kunnen ook secure entry points bestaan halverwege
de tree.

· De KEY record is gesigned door de key van de parent zone. Dat kan de resolver weer checken en

vervolgens de parent key gaan controleren. Dit gaat dan door tot een bekende key wordt gevonden. · Het KEY record is extern, ofwel off-tree gesigned. RFC 2535 staat dit toe, maar dit is alles behalve

triviaal.

2.1.1 On-tree en off-tree
Net zo belangrijk als dat er signatures zijn is het dat de resolver weet dat een zone secure is. Weet de resolver dat niet dan kan een keurige secure zone nog altijd compleet ge-hi-jacked en door een zogenaamd unsecure zone vervangen worden. Hoe weet een resolver nu af een zone secure is? Dat begint op een secure entry point, waarvan de resolver met een key is gepreconfigureerd. Deze zone, en alle zones eronder, zijn dan secure tot er bij een delegatie een (gesignde!) null-KEY wordt aangetroffen. Een null-KEY is een leeg KEY record en wordt gebruikt om aan te geven dat de bijbehorende zone (en als wat daaronder hangt) niet secure zijn.

We begrijpen nu ook gelijk waarom het derde geval hierboven, off-tree signing, zo ingewikkeld is: iedere aparte zone moet als secure in de resolvers gepreconfigureerd worden, anders heeft het nog geen zin.

2.1.2 Het NXT record

Een ander probleem dat bij secure DNS om de hoek komt kijken is wat te doen met een query naar een niet bestaande domeinnaam. Voor standaard DNS was dit al een probleem, want wat gebeurde er als je

aan een of andere caching server om een niet bestaande naam vraagt? De cacher kende de naam niet en ging naar een andere server waarna uiteindelijk een van de authoritive servers het definitieve NXDOMAIN oordeel kon geven. De oudere DNS implementaties cacheden dit niet, waardoor ieder nieuw request weer tot een nieuwe lookup leidde. Bedenk daarbij dat uit gemakzucht (ihb van de leveranciers!) nogal wat systemen een broadcastje doen voor een namelookup en het is duidelijk dat dit een prachtig mechanisme is om al dan niet bedoeld een DoS (denial of service) attack uit te voeren.

De oplossing voor dit probleem was negative caching, waarmee ook een NXDOMAIN wordt gecached. Maar... hoe sign je iets wat je van tevoren niet kent? Er zijn twee mogelijkheden:

· On the fly signing.

· Een nieuw record introduceren dat eenduidig de bestaande namen en records definieert.

Men heeft snel afgezien van het on the fly signen. Dit geeft te veel mogelijkheden tot DoS attacks.

Er is daarom het NXT record in DNSSEC geišntroduceerd. Eerst wordt de zone gesorteerd, en dan krijgt iedere naam in de zone een NXT record. Als data bevat het NXT record de types van records bij deze naam gedefinieerd zijn plus de volgende naam. Komt er nu een query voor een type record, dat bij een bestaande naam niet bestaat, of om een naam die niet bestaat, dan kan op grond van het NXT record eenduidig en verifieš erbaar worden vastgesteld, dat de query niet kan worden geresolved.

De NXT records worden door hetzelfde process gegenereerd dat de SIGs maakt, de signer dus.

2.1.3 Nadelen van het NXT record

Het NXT record sluit als het ware de zone volledig en is daarmee dan ook een essentieel onderdeel van DNSSEC. Maar er zitten drie grote nadelen aan:

· De zonefile moet gesorteerd worden.

· De zonefile wordt bijna verdubbeld.

· Het verbieden van zonetransfers wordt zinloos.

Het laatste probleem verdient wat uitleg. Sommige administrators willen, meestal om security through obscurity overwegingen, niet dat iedereen zomaar al zijn domeinnamen kan opvragen. Dat kun je doen door zonetransfers te verbieden. Maar dankzij het NXT-record kan je nu toch alle info opvragen door domweg de zone af te wandelen. Er onlangs een RFC voorgesteld, waarin dit probleem wordt aangepakt: in plaats dat het NXT record de volgende naam in de zone bevat, bevat het een hash-waarde. Het afwandelen van een zone wordt daarmee voorkomen, maar voor de andere, veel ernstiger problemen helpt het niets.

Het is duidelijk dat er nog veel discussie over het NXT mechanisme is, maar niemand is totnogtoe met een beter idee gekomen.

2.2 Implementatie problemen

Het eerste probleem is natuurlijk dat systeembeheerders op vrijwel alle niveaus het al moeilijk genoeg hebben met de groei van het aantal domeinnamen en geen tijd en zin hebben een nieuw kunstje te leren. Bij een aantal Amerikaanse overheidsinstellingen vindt men het dan wel heel belangrijk en is er dus geen tijd en wel geld. Je kunt dan verwachten dat hier grote interesse bestaat om de hele zaak uit te besteden en dus alles off-tree te laten signen. Gelukkig is deze fout nog niet gemaakt, maar het zet wel druk op de ketel.

2.3 Systeembelasting

Een echte showstopper leek de systeembelasting te zijn voor de echt grote toplevel domeins. Zoals .com met nu 16 miljoen namen eronder en .de met 3.5 miljoen.

Tot voor kort had niemand dit echt goed onderzocht. Er waren wel wat probeersels gedaan hier en daar en die bleken allemaal niet te lukken. Er werd over wekenlange sign sessies en crashende of hangende systemen gesproken. Er was daardoor wereldwijd het gevoel, dat het domweg technisch niet realiseerbaar was. Een aantal mensen, voornamelijk van de Zweedse, Nederlandse en Duitse registries, wilden die onderzoeken wel eens echt goed bekijken. Ze bleken echter niet boven water te krijgen. NLnet Labs heeft toen, begin 2000, de handschoen opgepakt en is domweg grote zones proberen te gaan signen.

2.3.1 De .nl en .de zones

Groot was onze verbazing, dat met een PC van f.2000,- onder FreeBSD de toch niet kleine .nl zone in een half uur klaar was. Dat viel dus reuze mee.

De volgende stap was het signen van de .de zone, zo'n 8 keer groter dan de .nl zone. Hier kwam een implementatie probleem naar voren: omdat de signer alle records in memory sorteert, liep FreeBSD uit zijn swapspace. Na een beetje herconfigureren bleek het signen van de .de zone wel mogelijk. Duur: 13 uur, onverwacht lang. We leerden hierdoor wat nieuws.

2.3.2 Welke records moet een toplevel domein signen

Een domein bevat naast de al eerder genoemde SOA, de eigen NS records en die van de delegaties en eventuele glue, ook A, MX, CNAME, etc. records voor alle mogelijk hosts en services in dat domein en eventuele niet gedelegeerde sub-domeinen. Over iedere record-set, dat zijn alle records van eenzelfde type over een naam, komt een signature.

Maar er zijn records die ook in een andere zonefile voorkomen en waarvoor die andere zonefile meer authoritive is. Typische voorbeelden daarvan zijn juist de NS-records van de gedelegeerde zones en de daarbij behorende glue-records. Deze records worden in de child zonefile gesigned en dus niet in de parent zonefile. In een toplevel domein worden dus gesigned:

1. De eigen, verplichte records, zoals de SOA en NS.

2. De NXT records.

3. Eventuele KEY records van de childs.

4. Eventuele hostinformatie, dus A, CNAME, MX in zowel het eigen als in niet gedelegeerde sub-
domeinen.

Voor een "goede" toplevel zone, waarin het type 4 records minimaal is, is het aantal te signen records dus een handvol plus 2 maal het aantal delegaties.

Terug naar de .de zone.
Deze bleek blijkt erg vervuild te zijn met A, MX en CNAME records van niet gedelegeerde subzones. Dit is histories zo gegroeid. In Nederland hadden we het fenomeen van niet gedelegeerde subzones zo'n 5 jaar geleden al opgeruimd, maar in Duitsland dus nog niet. Nu is het technisch niet zo moeilijk om al deze subzones in gedelegeerde subzones te veranderen. Dat hebben we dan ook maar als oefening met de .de zone gedaan en daar dus een delegation only zone van gemaakt.

Het resultaat is, dat de aangepaste .de zone in zo'n 4 uur gesigned kan worden op ons PCtje. En dat komt wel overeen met wat we verwachtten.

De les is hier dus, dat ccTLDs en gTLDs hun zone maar beter zo snel mogelijk delegation only maken. Dat scheelt meteen ook in de administratieve ellende.

2.3.3 De .com zone

Nu is de .com zone pas echt groot, weer zo'n 8x groter dan de .de zone. De paar pogingen die waren gedaan om deze zone door signer te jassen waren allemaal op een crashend of hangend systeem gestuit. Het idee dat dit domweg onmogelijk zou zijn was dan ook algemeen. Maar dankzij onze ervaring met de .de zone was het meteen duidelijk waardoor dit kwam: het adresseerbare geheugen van 32-bit hardware is gewoon te weinig om in-core te sorteren en zo werkt de huidige signer wel.

SIDN heeft ons toen een 64-bit machine ter beschikking gesteld. De kleinste Alpha, een 5000 dollar systeem, maar door ons bakbeest genoemd. Op dit systeem werd RedHat 6.2 Linux vrijwel standaard geinstalleerd, alleen de hoeveelheid swap-ruimte werd (fors) verhoogd. De huidige .com zone blijkt netjes "schoon" (dwz delegation only) te zijn en bleek op de Alpha in zo'n 40 uur gesigned te kunnen worden.

2.3.4 Conclusie systeembelasting

Onze conclusie is dat het heel erg mee valt met de gevreesde systeembelasting. Behalve dat de grote registries (veel) krachtiger systemen zullen gebruiken, wordt ook niet steeds een complete zone gesigned. De signers van zowel Bind-8 als Bind-9 kunnen prima incrementeel signen. Dwz, je past de gesignde zone aan met nieuwe en veranderde delegaties en jaagt deze file opnieuw door de signer. De signer zal dan de bestaande NXTs en SIGs checken en alleen waar nodig nieuwe genereren. Dit gaat vele factoren sneller dan een zonefile van scratch te signen.

3. Organisatorische problemen

Veel dreigender dan de techniek is het organisatorische probleem. Zolang het gaat om een paar delegaties is er natuurlijk weinig aan de hand, maar hoe schaalt dat op als we over miljoenen delegaties praten? En wie is verantwoordelijk voor de schade wanneer een TLD een gefakede zone signed.

3.1 Het .nl.nl testbed

Om gevoel te krijgen hoe een registry in de praktijk met DNSSEC moet omgaan heeft SIDN een speciaal sub-domein, .nl.nl, ter beschikking gesteld. Ook in Zweden en Duitsland is dit gebeurd (.se.se en .de.de), maar deze laatste testdomeinen zijn (nog) niet actief. De bedoeling is om iedereen die met DNSSEC ervaring wil opdoen hieronder een secure duplicaat van de huidige zone te laten opzetten. Op dit moment testen alleen NLnet Labs zelf en UUNET nog actief mee, maar er beginnen zich al meer organisaties te melden.

3.2 De relaties

In de inleiding ben ik al uitgebreid ingegaan op de relaties tussen de registry, de registrars, de domeinhouder en de zone-administrator. In een DNSSEC situatie worden deze relaties ineens heel belangrijk, en gaat het mis dan kun je ook schadeclaims verwachten. We gaan eerst even de technische kant bekijken.

3.2.1 Parent-Child relatie

Technisch gezien hebben we bij een delegatie twee zonefiles en dus ook twee partijen, die samen iets moeten afspreken. We gaan even uit van de situatie waar de parent al secure is en het child dat wil worden. Wat is er nu nodig en waar zitten de heikele punten?

· De administrator van de child-zone genereert een key, en maakt hiermee een secure zone. Maar
daarmee is de zone nog niet secure, want dat is die pas als de resolver weet dat de zone secure is.
En dat ze het niet weten is maar goed ook, want de KEY is nog niet te checken, waarmee de zone
bad is en van de Internet-kaart verdwijnt.

· Op een of andere wijze moet het public-part van de key, ofwel het KEY record, nu naar de
administrator van de parent zone om daar een SIG te krijgen. Net als bijvoorbeeld bij het wijzigen
van een NS-record zal dit out-of-band ofwel buiten DNS gecommuniceerd moeten worden.

· Heeft de parent het child KEY record, dan kan hij hiermee de oude NULL-KEY in de parent zone
van dit child vervangen en de KEY signen. Hiermee is het child secure.

Het heikele punt is stap 2: de parent moet er 100% zeker van zijn dat degene die de KEY aanbiedt de domeinhouder vertegenwoordigt. Dit geldt zowel voor het initieš le secure worden als voor het verversen van een key. Nu bestaat 100% zekerheid niet en in het licht van miljoenen domeinnamen is duidelijk waar de schoen wringt.

3.2.2 Registry, registrar, domeinhouder en zone-administrateur

In de praktijk van de grote TLDs hebben we weer deze vier partijen. Hopelijk valt nu het kwartje waarom ik hier bij de inleiding zo lang bij stilstond: zijn de onderlinge relaties goed geregeld, dwz met contracten en vrijwaringverklaringen, dan kent de registrar de domeinhouder, dan kent de registry de registrar en is de zone-administrateur netjes in dienst van ofwel de domeinhouder ofwel de registrar. Juridisch is de zaak nu af te dichten.

Maar met malafide registrars of administrateurs kan er nog steeds wat misgaan, en al kan de een schuldige partij worden aangewezen, de schade kan groot en moeilijk verhaalbaar zijn. Om die reden adviseren wij om naast de formele communicatiekanalen dan ook nog een informatieslag van registry direct naar domeinhouder toe te voegen. Op die wijze komen missers dan in ieder geval snel boven water.

3.3 Conclusie

Voor die TLD registries, die via een netwerk van registrars werken, een fatsoenlijke administratie hebben opgebouwd en geautomatiseerd en veilig met de registrars kunnen communiceren, is het implementeren van DNSSEC redelijk eenvoudig. Hetzelfde geldt voor de registrars: zij die een duidelijke (leveranciers-klant) relatie met domeinhouders hebben, kunnen voor deze DNSSEC eenvoudig ondersteunen.

Het gaat mis, waar administraties niet op orde zijn, of uš berhaupt niet bestaan. Waar domeinregistraties via een e-mailtje en na een betaling geregeld zijn, is het erg lastig voor de registry om vast te stellen dat de KEY aanbieder wel de echte domeinhouder is. En ook al vindt men een manier, dan zal het slecht schaalbaar zijn. Het is dus te verwachten dat deze TLDs niet snel DNSSEC zullen kunnen gaan ondersteunen.