SIDN fungeert als doorgeefluik bij verhuizing DNSSEC -beveiligde domeinen
Op dit moment worden beveiligde .nl-domeinen weer op onveilig gezet om ze naar een andere registrar te kunnen verhuizen. Straks is dat geen optie meer en zullen alle domeinen ook tijdens de verhuizing beveiligd moeten blijven. Technisch is dat ook heel goed mogelijk, maar het vraagt wel administratieve afstemming tussen latende en verkrijgende registrar. SIDN zal daarbij als doorgeefluik fungeren.
Het verhuizen van DNSSEC-beveiligde domeinen is technisch goed mogelijk, maar vraagt wel administratieve afstemming tussen latende en verkrijgende registrar. Er zijn op dit moment twee methoden bekend waarmee een domein van de ene naar de andere DNS -operator kan worden overgezet: de IETF-methode en het ICANN-alternatief. Naar verwachting zal de IETF-methode, bedacht bij SIDN, de enige werkbare oplossing blijken om verhuizingen geautomatiseerd af te wikkelen.
Standaard-methode
Antoin Verschuren, Technisch Adviseur bij SIDN en de bedenker van de IETF-methode, somt zo een hele rits argumenten op waarom deze oplossing de standaard zal worden:
- De benodigde medewerking van de latende DNS-operator is minimaal, en ook nog eens te automatiseren.
- De verkrijgende registrar is "in control".
- Bij het ICANN-alternatief moet alle zone informatie worden gekopieerd, bijvoorbeeld via AXFR. Er kunnen ook andere manieren worden gebruikt om deze data over te zetten, eventueel via de registrant, maar er moet sowieso meer informatie worden uitgewisseld tussen de registrars dan bij de IETF-methode.
- Bij het ICANN-alternatief mogen de handtekeningen tijdens het verhuisproces niet verlopen, iets dat in de praktijk moeilijk vooraf is in te stellen. Je kunt er op wachten dat dit fout gaat.
- Bij het ICANN-alternatief moet voorafgaand aan de verhuizing de TTL van de NS-set door de latende operator heel laag worden gezet, zodat die minimaal wordt gecached. Dat levert meer bevragingen en veel DNS-verkeer op. Bovendien maken de korte TTL-tijden DNS erg kwetsbaar voor minimale fouten.
- Hoe klein deze TTL ook is, tijdens het omzetten van de NS-set zal de Domeinnaam even "bogus" (ongeldig) zijn, in ieder geval enkele seconden. De vraag is of dat een ramp is, maar daarmee voldoet deze methode dus officieel niet aan de eis om tijdens de verhuizing continu beveiligd te blijven.
Uitgangspunten
Bij het oplossen van het probleem van beveiligde verhuizingen hebben wij vooral gekeken naar wat werkbaar zou zijn voor de registrars en de hele registry — registrar — reseller — registrant — DNS-operator keten,
aldus Verschuren. Vanuit mijn ervaring als registrar voor verschillende registries had ik voldoende inzicht in wat wel of niet zou kunnen werken.
Belangrijke aannamen zijn:
- Er is geen direct, veilig communicatiekanaal tussen alle operators, dus kan SIDN als tussenpersoon optreden.
- Er mogen geen private sleutels worden uitgewisseld.
- Er moet zo min mogelijk informatie uitgewisseld worden.
- Alles moet te automatiseren zijn wil je de medewerking krijgen van latende operators.
- Het belangrijke principe dat een registrant vrij moet zijn in de keuze van een registrar moet intact blijven om marktwerking zijn rol te laten spelen. Vandaar dat de verkrijgende registrar van de verkrijgende operator in het proces "in control" moet kunnen blijven. Een domeinnaam mag niet gegijzeld kunnen worden, en dat was wel het risico als een latende operator actief moest meewerken.
- SIDN wil geen proces opdringen, maar alleen faciliteren. Registrars kunnen dan zelf beslissen of ze daarvan gebruik maken.
Postvak voor ZSK
Binnen DRS (het DomeinRegistratieSysteem) zou er ondersteuning kunnen komen voor het aanbieden van een nieuwe ZSK aan de oude registrar,
zegt Sebastiaan Assink, operationeel manager bij hosting provider Oxilion. De oude registrar kan die dan als DNS-operator zelf opnemen of doorzetten naar de operator.
Inmiddels wordt bij SIDN inderdaad gewerkt aan een dergelijk postvak voor de ZSK. Wij faciliteren veilige verhuizingen door het bestaande beveiligde administratieve kanaal geschikt te maken om sleutels tussen verschillende DNS-operators en registrars door te geven,
aldus Verschuren. Wij doen zelf niets met die ZSK, maar wij zorgen dat die bij de huidige registrar terechtkomt via onze beveiligde registratie-omgeving.
De verkrijgende registrar moet voor een verhuizing eerst zijn nieuwe ZSK overzetten naar de latende DNS-operator. Daarvoor zullen we een nieuw EPP-commando (Extensible Provisioning Protocol) bedenken. Daarna kunnen alle opeenvolgende stappen worden uitgevoerd: transfer, add DNSKEY, NS change, en delete old DNSKEY, waarbij er tussen de stappen steeds even moet worden gewacht. Hoe lang precies gewacht moet worden kan de registrar zelf beslissen of uitvinden via DNS. SIDN gaat daarvoor zelf geen timers opdringen.
De latende registrar ontvangt van SIDN de doorgezette ZSK en bijbehorende domeinnaam in zijn EPP queue, en weet dat die is geautoriseerd door een verhuis-token. Hij geeft die door aan de latende operator (als hij dat zelf niet is). Het enige wat die moet doen is de ZSK toevoegen aan de zone en deze opnieuw ondertekenen.
Gijzeling
De enige kink in de kabel zou een te lange TTL van de DNSKEY bij de latende DNS-operator kunnen zijn. De latende operator bepaalt zelf de geldigheidsduur van zijn DNSKEY records,
legt Assink uit. Op een gegeven moment moet de oude operator de nieuwe ZSK opnemen in de zone en deze signeren met zijn KSK. Maar je wilt de name servers voor een domein niet wijzingen voordat je zeker weet dat de oude DNSKEY set is verlopen en die nieuwe ZSK ook overal wordt meegenomen in de validatie. Als de oude operator een hele hoge TTL (bijvoorbeeld van een week) hanteert, dan moet men dus een week wachten tussen het toevoegen van het nieuwe DS record en het wijzigen van de name servers.
Tijdens een van de stappen in het verhuisproces is men afhankelijk van de TTL van een record in de zone van de latende operator,
bevestigt Verschuren. Die moet verstrijken voordat je de volgende stap in het proces kunt uitvoeren. De kans bestaat dat een niet-welwillende operator die TTL heel hoog zal zetten, zodat er heel lang moet worden gewacht, en op die manier het proces frustreert. Dat is in feite een soort gijzeling, en dat willen we voorkomen.
SIDN hanteert nu al technische eisen, en daarin staan ook acceptabele waarden voor de belangrijkste TTL-tijden. Ook tijden voor DNSKEY records zullen daarin worden opgenomen. Nu worden die eisen niet heel erg streng bewaakt, dus er zijn af en toe DNS-operators die echt hele vreemde TTL's hanteren. Als ze dat blijven doen, komen ze vanzelf een keer in de problemen. De marktwerking zou er dan voor moeten zorgen dat ze een slechte naam krijgen en klanten verliezen. Vandaar dat wij het belangrijk vinden dat de verkrijgende registrar "in control" is bij het verhuisproces. Hij kan, in samenspraak met de registrant, altijd tijdens het proces nog besluiten om in plaats van beveiligd naar onbeveiligd te gaan, of een ander alternatief te gebruiken, en de schuld daarvoor bij de latende operator leggen.
Internet Draft
Eerder al verhuisde Verschuren het domein sidnlabs.nl, gewoon om te laten zien dat dat op een veilige manier mogelijk is en te demonstreren hoe dat dan in zijn werk zou moeten gaan. Ik heb daarbij alleen het beveiligde administratieve kanaal gesimuleerd. Huidige registrars kunnen dat ook. Maar op dit moment worden er weinig belangrijke domeinen verhuisd, dus alle verhuizingen gebeuren onveilig, of er komen validatiefouten bij voor.
Er gaan op dit moment .nl-domeinen op onveilig voor de verhuizing,
zegt ook Assink. Nu is dat nog acceptabel, en beter dan "bogus" (DNSSEC defect). Dat wordt binnenkort wel anders: dan is onveilig geen optie meer en zullen alle verhuizende domeinen beveiligd moeten blijven. Maar er zijn ook TLD-beheerders (zoals Zweden .se) waar een verhuizing volgens de IETF-methode niet eens mogelijk is. Daar is het advies zelfs om op onveilig te gaan.
Wat betreft de IETF-methode zelf meldt Verschuren dat de huidige Internet Draft inmiddels verlopen is en binnenkort opnieuw zal worden uitgebracht. Het gaat nu nog een 'individual submission'. Dat wil zeggen dat er nog geen formele toestemming is gevraagd aan de IETF DNSOP Working Group of dit document door die groep inderdaad wordt ondersteund. Dat gaat binnenkort wel gebeuren. De beoogde status van het document is 'Informational', dat wil zeggen dat het niet om een zogenaamde protocol-standaard gaat. Het is niet meer dan een omschrijving van 'dit is wat je moet doen als je beveiligd wilt verhuizen'. Daar is geen nieuw internet-protocol voor nodig. Alles bestaat al; het gaat alleen om de volgorde van het proces.
Actieve rol
Na de Lunch & Learn bijeenkomst waar de verhuisproblematiek uitgebreid is besproken, zijn er geen nieuwe acties geweest binnen de gemeenschap van registrars of bij de Commissie Techniek,
vertelt Assink. Na interne evaluatie bij Oxilion zelf hebben we wel onze processen aangepast, zodat we volgens de IETF-methode compatible zijn voor zowel het .nl-domein als voor andere TLD's. Het verhuizen van beveiligde domeinen zal ook nog op de agenda van de Commissie Techniek komen.
Daarnaast verwacht Assink een actieve rol van de SIDN. SIDN is een partij waar internationaal veel naar gekeken wordt als het gaat om DNSSEC. Daar moet SIDN gebruik van maken, door veel interactie te zoeken met de registrars en DNS-operators in het veld, en door deze feedback te communiceren met andere registries. Daarnaast zou het organiseren en faciliteren van trainingen en workshops voor registrars en operators van grote toegevoegde waarde kunnen zijn.
Hier wordt Assink op zijn wenken bediend: tijdens de jaarlijkse relatiedag op donderdag 29 november in Utrecht zal Verschuren een presentatie geven over het verhuizen van DNSSEC-beveiligde domeinen.
