Binnenkort is het zover. Keyrelay, een door SIDN ontwikkelde internetstandaard, wordt door de Internet Engineering Task Force (IETF) gepubliceerd als RFC. Als een van de auteurs van deze standaard is dit een mijlpaal om trots op te zijn. Met het publiceren van de nieuwe standaard zijn we er echter nog lang niet. De volgende stap is de adoptie van de standaard door de markt.
Welke internetstandaard komt eraan?
Een van de uitdagingen van DNSSEC komt naar voren wanneer de houder van een domeinnaam besluit van DNS-operator te veranderen. Idealiter gebeurt dit mét behoud van DNSSEC-validatie tijdens de overdracht. Dit noemen wij ook wel “secure verhuizen”. Om een secure verhuizing uit te kunnen voeren moet er een mogelijkheid zijn om DNSSEC-sleutels veilig te transporteren tussen DNS-operators (zie [1]). SIDN heeft hiervoor een internetstandaard ontwikkeld. Deze standaard maakt het mogelijk om dit DNSSEC-sleutels via het EPP-protocol te transporteren. [2].
In deze blogpost leg ik uit hoe je een domeinnaam secure verhuist met behulp van EPP. Hierbij maken we gebruik van de nieuwe internetstandaard. De nadruk ligt op hoe dit in EPP geïmplementeerd moet worden.Voor de .nl-zone geldt dat de meeste DNS-operators ook registrar zijn waardoor keyrelay ideaal is voor het transporteren van DNSSEC-sleutels. Alle registrars hebben immers een relatie met de registry en er is een vertrouwd en veilig EPP-kanaal waarover de DNSSEC-sleutels verstuurd kunnen worden.Op dit moment zit de standaard in de laatste fase van de standaardisatie en we verwachten is dat deze binnen 2 á 3 maanden als RFC gepubliceerd wordt.
Verhuizingen binnen de .nl-zone
Het doel van de keyrelaystandaard is dat een houder van registrar kan wisselen, zonder dat de beveiliging van zijn domeinnaam onderbroken wordt. Als we in ons registratiesysteem kijken dan zien we verschillende scenario’s waarin de DNSSEC-beveiliging verbroken wordt als gevolg van een insecure verhuizing. Enkele voorbeelden hiervan zijn:
Een registrar krijgt door een verhuizing een domeinnaam onder beheer en gooit direct het sleutelmateriaal weg en plaatst zijn eigen DNSSEC-sleutels bij de domeinnaam;
Een registrar krijgt door een verhuizing een domeinnaam onder beheer en laat de oude sleutels bij de domeinnaam staan;
Een registrar gooit bij het opvragen van het verhuistoken voor een domeinnaam direct alle sleutels weg.
Naast deze 3 scenario's zijn er in de praktijk nog veel meer scenario’s mogelijk. Er zijn registrars die na een verhuizing in aparte EPP-transacties meerdere wijzigingen doorvoeren om de domeinnaamregistratie bij te werken met de juiste gegevens.Al deze scenario's zorgen ervoor dat er geen geldige DNSSEC-keten beschikbaar is of dat validerende resolvers de domeinnaam niet meer resolven omdat de DNSSEC-keten ongeldig is.
Secure verhuizing: wat gebeurt er op EPP-niveau?
Hoe een secure verhuizing op DNS-niveau werkt is in diverse publicaties [3] en [4] beschreven. Hierbij spelen allerlei time-outs (de TTLs) een belangrijke rol. Dit behandel ik hier verder niet.Een secure verhuizing bestaat uit meerdere EPP-transacties die achtereenvolgend uitgevoerd moeten worden.
Stap 1: De verkrijgende registrar start het verhuisproces
Het verhuisproces start als een houder met verhuistoken bij een registrar aanklopt om zijn domeinnaam te verhuizen. Allereerst wordt er nieuw DNSSEC-materiaal gegenereerd dat in de nieuwe zone opgenomen wordt. Vervolgens verstuurt de registrar een keyrelaybericht met de domeinnaam, het token en de nieuwe DNSSEC-sleutels naar de registry.Hieronder een voorbeeld van een EPP-keyrelaybericht:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0" C: xmlns:s="urn:ietf:params:xml:ns:secDNS-1.1" C: xmlns:d="urn:ietf:params:xml:ns:domain-1.0"> C: <command> C: <create> C: <keyrelay:create> C: <keyrelay:name>example.nl</keyrelay:name> C: <keyrelay:authInfo> C: <d:pw>JnVdBAZxSxZj</d:pw> C: </keyrelay:authInfo> C: <keyrelay:keyRelayData> C: <keyrelay:keyData> C: <s:flags>256</s:flags> C: <s:protocol>3</s:protocol> C: <s:alg>8</s:alg> C: <s:pubKey>cmlraXN0aGViZXN0</s:pubKey> C: </keyrelay:keyData> C: <keyrelay:expiry> C: <keyrelay:relative>P1M13D</keyrelay:relative> C: </keyrelay:expiry> C: </keyrelay:keyRelayData> C: </keyrelay:create> C: </create> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
Stap 2: Transport van het nieuwe DNSSEC materiaal door de registry
De registry controleert bij het verwerken van een keyrelay-aanvraag het token en zet vervolgens het bericht in de poll queue van de beherende registrar. Hierbij verandert er nog niets aan de huidige registratie. De registry wordt alleen gebruikt voor het transporteren van de nieuwe DNSSEC-sleutels.De keyrelay standaard is zo ontworpen dat alleen de domeinnaam en het token nodig zijn om het bericht naar de registry te sturen. Hiermee voorkomen we dat de verkrijgende registrar moet uitzoeken wie de beherende registrar is, dat is immers bekend bij de registry. Het resultaat is een bericht in de EPP poll queue van de huidige beherende registrar van de domeinnaam dat er als volgt uitziet:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:keyrelay="urn:ietf:params:xml:ns:keyrelay-1.0" S: xmlns:s="urn:ietf:params:xml:ns:secDNS-1.1" S: xmlns:d="urn:ietf:params:xml:ns:domain-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="5" id="12345"> S: <qDate>1999-04-04T22:01:00.0Z</qDate> S: <msg>Keyrelay action completed successfully.</msg> S: </msgQ> S: <resData> S: <keyrelay:infData> S: <keyrelay:name>example.nl</keyrelay:name> S: <keyrelay:authInfo> S: <d:pw>JnVdBAZxSxZj </d:pw> S: </keyrelay:authInfo> S: <keyrelay:keyRelayData> S: <keyrelay:keyData> S: <s:flags>256</s:flags> S: <s:protocol>3</s:protocol> S: <s:alg>8</s:alg> S: <s:pubKey>cmlraXN0aGViZXN0</s:pubKey> S: </keyrelay:keyData> S: <keyrelay:expiry> S: <keyrelay:relative>P1M13D</keyrelay:relative> S: </keyrelay:expiry> S: </keyrelay:keyRelayData> S: <keyrelay:crDate> S: 1999-04-04T22:01:00.0Z S: </keyrelay:crDate> S: <keyrelay:reID> S: ClientX S: </keyrelay:reID> S: <keyrelay:acID> S: ClientY S: </keyrelay:acID> S: </keyrelay:infData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-ZYX</svTRID> S: </trID> S: </response> S:</epp>
Stap 3: Verwerking van het poll bericht door de huidige beherende registrar
Als een registrar een keyrelaybericht ontvangt van de registry kan hij de nieuwe DNSSEC-sleutels bij de bestaande sleutels in zijn nameserver publiceren. Vervolgens signeert hij de nieuwe sleutels met zijn eigen sleutels, zodat de nieuwe sleutels in de DNSSEC-keten opgenomen kunnen worden.
Stap 4: De daadwerkelijke verhuizing
Een "normale" verhuizing bestaat in de meeste gevallen uit twee transacties, namelijk de verhuizing van de domeinnaam naar de aanvragende registrar en het bijwerken van de domeinnaamregistratie nadat de domeinnaam is overgedragen.De aanvraag voor een verhuizing van een domeinnaam ziet er als volgt uit:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="request"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.nl</domain:name> C: <domain:period unit="y">1</domain:period> C: <domain:authInfo> C: <domain:pw roid="JD1234-REP">JnVdBAZxSxZj </domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
Vanwege de eerder genoemde timing issues is het belangrijk dat er geen wijzigingen in de DNSSEC-keten gedaan worden voor het wijzigen van de domeinnaam. Alleen administratieve en nameserverwijzigingen zijn toegestaan. De aanvraag voor het wijzigen van een domeinnaam ziet er als volgt uit:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.nl</domain:name> C: <domain:add> C: <domain:ns> C: <domain:hostObj>ns1.registrar2.nl</domain:hostObj> C: <domain:hostObj>ns2.registrar2.nl</domain:hostObj> C: </domain:ns> C: </domain:add> C: <domain:rem> C: <domain:ns> C: <domain:hostObj>ns1.registrar1.nl</domain:hostObj> C: <domain:hostObj>ns2.registrar1.nl</domain:hostObj> C: </domain:ns> C: </domain:rem> C: </domain:update> C: </update> C: <clTRID>500100-002</clTRID> C: </command> C:</epp>
Stap 5: Verwijderen van de oude sleutels
Als na een tijdje alle TTLs in het DNS verlopen zijn kan de nieuwe registrar de DNSSEC-keten bijwerken door de sleutels van de vorige registrar te verwijderen. Voor de nieuwe registrar betekent dit dat er een EPP-transactie moet plaatsvinden waarbij eenvoudig de oude sleutels verwijderd worden. Met EPP doe je dit met het ‘remove all vlaggetje’. In hetzelfde bericht moet je dan wel de nieuwe sleutels opnieuw aanbieden. Hiermee is de secure verhuizing afgerond.
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.com</domain:name> C: </domain:update> C: </update> C: <extension> C: <secDNS:update urgent="true" C: xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> C: <secDNS:rem> C: <secDNS:all>true</secDNS:all> C: </secDNS:rem> C: <secDNS:add> C: <secDNS:keyData> C: <secDNS:flags>256</secDNS:flags> C: <secDNS:protocol>3</secDNS:protocol> C: <secDNS:alg>8</secDNS:alg> C: <secDNS:pubKey>cmlraXN0aGViZXN0</secDNS:pubKey> C: </secDNS:keyData> C: </secDNS:add> C: </secDNS:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
Hoe gaat het verder na publicatie?
SIDN heeft de eerste versie van keyrelay al in productie sinds juli 2013. Hiermee wilden we vooral aantonen dat het werkt [3]. Inmiddels is er binnen de IETF veel discussie geweest over de XML-structuur en is deze aangepast aan de wensen van de werkgroep. SIDN wacht tot de definitieve internetstandaard gepubliceerd is, voordat we onze eigen implementatie aanpassen. Dit betekent een wijziging aan de EPP-interface van DRS. Daarna is het de beurt aan de registrars om secure te gaan verhuizen. Met de opkomst van steeds meer DNSSEC validerende resolvers neemt de noodzaak van een veilige verhuizing snel toe. Samen met de Vereniging van Registrars gaan we bekijken hoe we de adoptie kunnen stimuleren.
Referenties
[1] https://www.sidnlabs.nl/wp_2013_EPP-keyrelay_v1.pdf
[2] https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/
[3] http://www.dnssec.nl/cases/dnssec-secure-transfers-het-kan-wel.html
[4] https://datatracker.ietf.org/doc/draft-koch-dnsop-dnssec-operator-change/
