DNS (Domain Name System) vertaalt de namen van domeinen naar de IP-adressen van servers. Het is ontworpen in een tijd dat beveiliging nog niet echt een zorg was, en het is dan ook kwetsbaar voor misbruik door kwaadwilligen. DNSSEC (Domain Name System Security Extensions) doet hier iets aan door digitale handtekeningen toe te voegen aan DNS.

DNS-verzoeken kunnen met die handtekeningen door resolvers geverifieerd worden in de vorm van een 'keten van vertrouwen'. Maar om echt veilig te zijn moet dus wel elke zone in de hiërarchie, van subdomein, via domein en TLD (top-level domain) tot uiteindelijk de root-zone, DNSSEC geïmplementeerd hebben. Sinds vorig jaar is de root-zone overgeschakeld op DNSSEC en SIDN heeft de .nl-zone ondertussen ook met DNSSEC ondertekend.

Toch is DNSSEC nog niet breed ingevoerd, zegt Miek Gieben, technisch adviseur bij SIDN. Gieben is afgestudeerd op het onderwerp DNSSEC en heeft enkele jaren gewerkt bij NLnet Labs aan de verdere ontwikkeling van DNSSEC. "Op TLD-niveau zijn alle zones nu wel naar DNSSEC aan het overstappen, maar een niveau lager wordt men nu pas wakker.

Op dit moment zijn er bijvoorbeeld nog maar 47 door DNSSEC beveiligde zones in het .nl domein, en SIDN zit nu in de friends & fans fase, waarbij we alleen handmatig DNS trust anchors opnemen in de .nl zone voor wie al bekend is met DNSSEC. Toch zou ik systeembeheerders aanraden om zich nu al met DNSSEC bezig te houden, al is het maar om er al ervaring mee op te doen en er klaar voor te zijn voor wanneer je niet meer buiten DNSSEC kunt. Dat zal overigens niet zo lang meer duren, want de .com-zone wordt eerstdaags ondertekend."

Ondersteuning

Bij gebruik van DNSSEC genereert DNS grotere antwoorden, en de resulterende UDP-pakketten zijn groter dan 512 bytes. Op zich is dat geen probleem, maar volgens Gieben slaan sommige monitoringtools dan op tilt, omdat ze denken dat zo'n groot UDP-pakket onderdeel is van een aanval. "Ook sommige netwerkhardware kan niet met de grote UDP-pakketten overweg: bedrijfsapparatuur is er wel klaar voor, maar bij thuisrouters is dat minder evident. AVM heeft enkele van zijn Fritz!Box ADSL-routers wel al een tijdje uitgerust met een DNS-forwarder die DNSSEC snapt, en Cisco komt binnenkort ook met een thuisrouter die DNSSEC ondersteunt. Dit soort problemen wordt dus allemaal wel aangepakt en op vlak van hardware- en softwareondersteuning zorgt DNSSEC niet echt meer voor grote uitdagingen."

Tools

Een belangrijk onderdeel van het beheer van DNSSEC bestaat uit re-signing en key handling. Elke handtekening in DNSSEC heeft een beperkte levensduur, normaal gesproken één maand. "Als je na die maand de zone vergeet te re-signen of geen nieuwe handtekening aanmaakt, dan klopt de DNSSEC-informatie niet meer: je handtekeningen zijn dan verlopen, en je zone valt dan van het internet voor iedereen die DNSSEC-validatie aan heeft staan." Het is dus zaak om op tijd je zone ge-resigned te hebben, zodat er weer verse handtekeningen met een maand looptijd klaarstaan.

Re-signing moet je sowieso doen, maar je kunt er uit veiligheidsoverwegingen ook nog voor kiezen om regelmatig nieuwe sleutels uit te rollen. De oude sleutels moeten dan uitgefaseerd worden, een zogenaamde 'key rollover'. Uiteraard moet je elke keer dat je nieuwe sleutels gebruikt de zone opnieuw signen. Gieben wijst er wel op dat het ook anders kan: "Er is een stroming die zegt: maak gewoon eenmaal die sleutels aan en gebruik die voor jaren. Dan heb je geen key rollovers nodig en wordt key handling dus heel wat eenvoudiger. Op zich is daar wel iets voor te zeggen: zolang er niets verkeerd gaat, loopt dat wel los."

Key handling en re-signing schrikt velen af, maar gelukkig bestaan er tools die dat voor je regelen. Gieben noemt onder andere OpenDNSSEC, waar onder andere NLnet Labs zijn schouders onder zet: "Wij gebruiken OpenDNSSEC bij SIDN om key handling en re-signing te regelen, en het programma doet dat volledig transparant voor je. In nieuwere releases van Bind kan dat ook met auto-dnssec, en ook PowerDNSSEC verzorgt tegenwoordig de complete key handling. Ik gebruik zelf thuis een 'old-school' methode: een Makefile en een cronjob."

Valideren

Als je alleen antwoorden van DNSSEC wilt valideren, dan kan dat eenvoudig met Bind of de validating resolver Unbound, ook al een project van NLnet Labs. Verder bestaan er nog extensies voor Firefox die met een icoontje in de adresbalk tonen of een domein gevalideerd kan worden met DNSSEC, zoals DNSSEC Validator. En wie wil testen of zijn DNS-resolver DNSSEC ondersteunt, kan hiervoor de website SIDN DNSSEC test bezoeken, ontwikkeld door Giebens collega Marco Davids. Als je resolver geen DNSSEC ondersteunt, krijg je een groot rood kruis te zien.

Troubleshooten

De belangrijkste uitdaging voor netwerkbeheerders is dat DNSSEC heel wat meer kennis van de DNS-infrastructuur vereist, vindt Gieben: "Als je DNSSEC-validatie inschakelt in je DNS, moet je echt wel weten hoe je dit kunt troubleshooten. Want als er een aanval bezig is of als je iets fout hebt gedaan, dan kun je de zone gewoon niet bereiken. In plaats van een mooie foutmelding in je browser bijvoorbeeld, kom je dan gewoon niet op de webpagina." Gelukkig bestaan er wel heel wat tools die helpen bij het troubleshooten, zoals de website DNSViz die de DNSSEC-authenticatieketen voor een domeinnaam visualiseert of de DNSSEC Analyzer van Verisign Labs.

"DNS werkt vaak gewoon zonder dat je er bij moet nadenken. Als er iets stuk gaat, is het vaak niet volledig stuk, dus als niemand ernaar gaat kijken blijft het wel werken. Maar bij DNSSEC kun je het je niet meer permitteren om niet vanaf het begin over mogelijke problemen na te denken, en bij problemen moet je ook sneller optreden", merkt Gieben op. Verder geeft hij aan dat configuratiebeheer essentieel is voor een goede implementatie van DNSSEC, "maar eigenlijk zijn configuratiebeheer en op voorhand nadenken over mogelijke problemen zaken die je sowieso al had moeten doen, dat is niet eigen aan DNSSEC."

Best practices

DNS is op zich is al moeilijk, maar om DNSSEC te implementeren moet je volgens Gieben dus echt wel iemand hebben die er wat van afweet: "Voor een junior systeembeheerder is het waarschijnlijk wat te hoog gegrepen om dit te doen. Beheerders kunnen wel een RFC met best practices raadplegen: RFC4641: DNSSEC Operational Practices. Die is wel meer gericht op de mensen die de TLD's beheren, maar het kan toch geen kwaad om deze eens te lezen. Verder heeft NLnet Labs een DNSSEC HOWTO gepubliceerd en heeft het Internet Systems Consortium een presentatie DNSSEC in 6 minutes. Meer informatie vind je op dnssec.net, en wij houden ook een website met technische informatie en nieuws bij op www.dnssec.nl. Uiteindelijk valt overstappen naar DNSSEC dus wel mee; het is niet zo'n grote investering."