DNSSEC secure transfers: het kan wel
Toen SIDN in 2008 serieus werk ging maken van de operationele implementatie van DNSSEC, liepen we tegen problemen aan die niet zozeer te maken hadden met de techniek, maar met de administratie rondom domeinnamen en de hele keten van registry-registrar-reseller-registrant- DNS -operator. Hoe kon je een Domeinnaam secure verhuizen van de ene DNS-operator naar de andere zonder dat ze inzicht hadden in elkaars private keys die in DNSSEC worden gebruikt?
Nadat we dit hadden aangekaart bij diverse DNS-guru’s die in eerste instantie een beetje doof waren voor dit operationele aspect, kregen we snel bijval van andere registries die dit ook wel als probleem zagen. Dit heeft geleid tot een internet draft die de procedure rondom het secure verhuizen van een DNSSEC-domeinnaam tussen twee dns-operators beschrijft:
De praktijk
Wij wilden wel eens weten hoe dit in de praktijk uitwerkt. Onlangs hebben wij een R&D-netwerk voor SIDN Labs opgezet, en wij wilden het beheer van de domeinnaam die we daarvoor gebruiken (sidnlabs.nl) overnemen van onze interne ICT-organisatie naar de R&D-organisatie. Een ideale test-case, omdat de lijnen kort waren, maar het toch virtueel om twee verschillende operators gaat waartussen de domeinnaam verplaatst moest worden. En de domeinnaam was gesigneerd met DNSSEC in productie sinds SIDN’s Friends & Fans fase voor DNSSEC.
We hebben ons gehouden aan de draft die we zelf mee ontwikkeld hebben, en hebben de dns-operator change uitgevoerd in 14 stappen. De zone sidnlabs.nl was gedelegeerd aan ns1.sidn.nl en ns2.sidn.nl, beide beheerd door ICT, en moest gedelegeerd worden naar proteus.sidnlabs.nl, beheerd door R&D. Dit zijn de stappen die we hebben uitgevoerd:
- Primary gaan draaien voor sidnlabs.nl op de nieuwe name server proteus.sidnlabs.nl.
- Nieuwe DNSSEC keys aanmaken voor sidnlabs.nl door de nieuwe operator.
- De oude ZSK van de oude operator opnemen in de nieuwe ongesigneerde zone door de nieuwe operator.
In de ongesigneerde zone hebben we dus een DNSKEY record opgenomen met de bestaande ZSK van de oude operator (key-tag 49689):
@ IN SOA proteus hostmaster.sidn.nl ( 1339658203 ; Serial 14400 ; Refresh (4 hours) 3600 ; Retry (1 hour) 604800 ; Expire (1 week) 3600 ; Negative caching (1 hour) ) IN NS proteus IN NS ns2.sidn.nl. IN A 213.136.31.221 IN AAAA 2001:7b8:c05::80:4 IN DNSKEY 256 3 8 ( AwEAAdTI1IY5X1Caa/7P8xNWjjFU7SPUvlbA+UOGKong Y/qELtpdk1qOx/lMrpqM/b6S4UoH9tBI/QAuiXTxMZFD +QFZKNfluA/50gj59/k3XqSk3fQp8u5k1OBvUn68MiRR w3ghzKcN9kQwJ5dTMOO1YRQZNtwVReYSuOjKFR9NvsZj ) ; key id = 49689 www IN A 213.136.31.221 - De nieuwe zone signeren met de nieuwe KSK/ZSK door nieuwe operator.
Bij het signeren geeft BIND een warning:
20-Jun-2012 08:49:43.310 general: warning: dns_dnssec_keylistfromrdataset: error reading private key file sidnlabs.nl/RSASHA256/49689: file not found
BIND gaat op zoek naar de private key met key-tag 49689, de oude ZSK van de oude operator. Natuurlijk wordt die private key niet gevonden, want dieheeft de nieuwe operator niet. Uiteindelijk wordt de zone toch gesigneerd, maar enkel met de nieuwe keys. De waarschuwing zal elke keer als er wordt gesigneerd door BIND weer in de logs komen, totdat de oude key uit de zone is gehaald.
Key-tags 52720 en 20853 zijn de nieuwe KSK en ZSK van de nieuwe operator. Key-tag 49689 is de oude ZSK van de oude operator. Dit is dus de zonefile op de nieuwe name server, beheerd door de nieuwe operator:
sidnlabs.nl. 86400 IN DNSKEY 257 3 8 ( AwEAAaHexfzeKtEA3eEVxiJQUURcnqmN+kEJT0Zpr/qb 0Wzc3QnBvswopwP/Z+NIQFp0v30CK9FNT8cZTy4Qj7xV eGLMAZqKO1yWSh0YXDhXhgLsbx1bToMkFyoYPvEk2qx1 CU0AWfVxSvs7eGaxaVJIv9K4yJwiyIf7wPFptWqLHf9M lvUWDWpI2YwwjL0tULDZJ/OXnc2wmv9ZAztYZa2k7jqy oBb1G/M0Y1ATRCcvZvc+QdEv8Qls8P3nMsREg3Ko5JAi txFaibOvaz6ROQSe20SmrrddaMs4Dm5brXmWhfq25tRN UIHaczUMJPxtLNEUqmgqewdDNAIPv4Y207zCWh0= ) ; key id = 52720 sidnlabs.nl. 86400 IN DNSKEY 256 3 8 ( AwEAAdN5P6Ktkl4l3yxC/maZ2xza0Dq5oCBGYCif6ORP NX2ZnYyIfCMZW4KvaOjFYeuNvpySJFliIc1UjM+OlWvj LjK6xhX7HMXlWg/b2Rpgw3rwVDCEnK1PsCVg68S9KkT4 k93g/qlTvjqKcbH8bVZL6WOY+W6eKlCMdJFPeBpqnrmn ) ; key id = 20853 sidnlabs.nl. 86400 IN DNSKEY 256 3 8 ( AwEAAdTI1IY5X1Caa/7P8xNWjjFU7SPUvlbA+UOGKong Y/qELtpdk1qOx/lMrpqM/b6S4UoH9tBI/QAuiXTxMZFD +QFZKNfluA/50gj59/k3XqSk3fQp8u5k1OBvUn68MiRR w3ghzKcN9kQwJ5dTMOO1YRQZNtwVReYSuOjKFR9NvsZj ) ; key id = 49689 sidnlabs.nl. 86400 IN RRSIG DNSKEY 8 2 172800 20120714124942 ( 20120614114942 52720 sidnlabs.nl. eCvoYUCl9q6/z0UbHFGolUVLPAxwSdv2rJif20ML2BlC k+0clGx4ALGEZoeYj+8oHmDp6Oq//p3457L5pBbPU35A gYN/hKbT9hpIwhOU6cRZsd5iTnw7GQ9Bt4kMwxTBtURf GpcDlmlK0bHM5Lr03RhMYFZGvIraNQ41kP0Bn8bjzLIq dmkEgjMrwBdnRZdEWOPGCNr+IHu+KCbdKssyYCVx2w2g ZyFMupSrcfDAA2XPITLC2ys4gJdIVcR4ArLx28us8Kv8 AurQzdQPDmsymsJdHIEcoTc0WasMizxBuHulVV0mgFHY 3fHEsP7kmUOaZNVYW2J3gIwXgj3FJJCMEQ== ) - De nieuwe ZSK opnemen in de oude zone door de oude operator op ns1.sidn.nl.
We hebben de publieke ZSK met key-tag 20853 pgp signed gemaild naar de oude operator, die de key heeft opgenomen in hun versie van de unsigned zone sidnlabs.nl op ns1.sidn.nl, hetzelfde als wij in stap 3 hebben gedaan.
- De oude zone opnieuw signeren met oude KSK door oude operator.
Ook toen de oude zone opnieuw werd gesigneerd door de oude operator kreeg die een foutmelding, dezelfde als bij stap 4. De waarschuwing betrof nu echter dat de private key met key-tag 20853 niet gevonden kon worden, en dat klopt, want de oude operator beschikt niet over die nieuwe private key. Uiteindelijk wordt de zone toch gesigneerd met enkel de oude keys, en dit is de oude zone op ns1.sidn.nl:
sidnlabs.nl. 86400 IN DNSKEY 257 3 8 ( AwEAAbERFtxN3BuVMP6OKYe/Ca1S9jrzivoyKdN3XfTQ OwSv4MbSOhXoJLdN5UuvXC7OzmJaUORLWvfJ7rc25yIp MppjWJ6B7bT0dh89Hy2N7ntSZWxZzON3wK4us2Xeusyb NmFMCeTtORsyMrSX6/jD/kApAG3RXcJh9upAoJMWWcFc Rn51js/GUbwxrccGZWYtMi6knqWNXL7pC+uG5Kb8EKt6 C0Am8STCC6UKcWptd8PKgCBPkiDh5CJCbU68vWiPYLkh 2l+WSqTCQz+6CgdHQyxpF4mmgALmeSsNQIJevXVL8A2E klD8x3aUaoEoplGS9Ox6IV91nV6u7+kbVijitMU= ) ; key id = 61462 sidnlabs.nl. 86400 IN DNSKEY 256 3 8 ( AwEAAdN5P6Ktkl4l3yxC/maZ2xza0Dq5oCBGYCif6ORP NX2ZnYyIfCMZW4KvaOjFYeuNvpySJFliIc1UjM+OlWvj LjK6xhX7HMXlWg/b2Rpgw3rwVDCEnK1PsCVg68S9KkT4 k93g/qlTvjqKcbH8bVZL6WOY+W6eKlCMdJFPeBpqnrmn ) ; key id = 20853 sidnlabs.nl. 86400 IN DNSKEY 256 3 8 ( AwEAAdTI1IY5X1Caa/7P8xNWjjFU7SPUvlbA+UOGKong Y/qELtpdk1qOx/lMrpqM/b6S4UoH9tBI/QAuiXTxMZFD +QFZKNfluA/50gj59/k3XqSk3fQp8u5k1OBvUn68MiRR w3ghzKcN9kQwJ5dTMOO1YRQZNtwVReYSuOjKFR9NvsZj ) ; key id = 49689 sidnlabs.nl. 86400 IN RRSIG DNSKEY 8 2 86400 20120721061503 ( 20120621061503 61462 sidnlabs.nl. rX6kn2AAIPzbbG89sf//+lV+dwr13qslZwqFF0pAoGa6 OGGKW5GtGbBFsosN8ZNlf7JisNkYfOKmif0apS0ecNQp oCdkbWcVwXjO6zMdKRKoBVtCU/sGZFIXUOhE0hxphKB8 v8sIjQCHgnj+JOSpcdpFJfq55nAlGNxOBqjDmNeJmwAl Vcs0g9IpfGpc8iJ8ALp0ve9HDsPYoHaJv6+FV+8mKEvs uGFECBBjhaTxTNFowL0I+Ufor3rRTL4Dm8ybk8p8qBbE j8/Zryy4iOUbF9ayuz490OlzaMQVF9q/A7rYldsPlrEP wSEmLdyDBe3WVK+Fu6WSpR6QfYKiPR8nSg== ) - DS voor nieuwe KSK toevoegen aan delegatie bij registry.
Vervolgens moet de nieuwe KSK worden toegevoegd als DS record bij de parent, zodat beide versies van de zone gevalideerd kunnen worden. Er zijn dus tijdelijk minimaal twee DS records in de .nl-zone voor sidnlabs.nl, die van de oude en nieuwe DNS operator:
sidnlabs.nl. 7200 IN DS 61462 8 2 ( D8A9F1AC8431429292E437DE7737AFCA8BA7A07529F0 87FB329503248289CAEA ) sidnlabs.nl. 7200 IN DS 52720 8 2 ( ADA4B036E9BC9F5854A201329DFB04D376153A616C22 DD9E3B12CB4566CCC5DF ) - Minimaal 1 DNSKEY RRset TTL (oude zone) en 1 DS TTL (van .nl zone) wachten voor propagatie.
Wij hebben 2 dagen gewacht op propagatie. Er moest minimaal 84600 seconden na stap 6 en 7200 seconden na stap 7 gewacht worden, dus dat was ruim voldoende.
- ns2.sidn.nl moet secondary gaan draaien voor sidnlabs.nl met proteus.sidnlabs.nl als primary ipv ns1.sidn.nl.
Wij hielden dezelfde secondary, dus nu beide zones gevalideerd konden worden konden we ns2.sidn.nl configureren om de zone voortaan van proteus.sidnlabs.nl te betrekken in plaats van ns1.sidn.nl.
- De delegatie bij de registry wijzigen naar de nieuwe name servers.
Nu beide name servers geconfigureerd waren, en zowel de oude als nieuwe zone gevalideerd kon worden, konden we de uiteindelijke name server wijziging in de .nl-zone doorvoeren:
sidnlabs.nl. 7200 IN NS proteus.sidnlabs.nl. sidnlabs.nl. 7200 IN NS ns2.sidn.nl.
- 1 NS RRset TTL (oude zone) wachten voor propagatie.
Vervolgens moesten we 84600 seconden wachten, het maximum van de NS TTL van de oude zone en de NS TTL van de .nl-zone, om te zorgen dat alle resolvers, zowel parent en child sticky en non-sticky resolvers de nieuwe name server set in hun cache hadden.
- De oude DS van oude KSK verwijderen bij registry.
Nu konden we de oude DS van de oude operator verwijderen uit de .nl-zone, want de oude zone zou nu niet meer worden bevraagd:
sidnlabs.nl. 7200 IN DS 52720 8 2 ( ADA4B036E9BC9F5854A201329DFB04D376153A616C22 DD9E3B12CB4566CCC5DF ) - De oude zone verwijderen van ns1.sidn.nl.
Nu konden de oude zone en de oude keys ook worden verwijderd van ns1.sidn.nl.
- De oude ZSK verwijderen uit de nieuwe zone.
En als laatste konden we de oude ZSK verwijderen uit de nieuwe zone op proteus.sidnlabs.nl.
DNSVIZ
Tijdens het hele proces hebben we gecontroleerd of de validatie van de zone gehandhaafd bleef op verschillende resolvers. Van sommige resolvers werd de cache geflushed na elke stap, en van anderen niet. Ook is de zone zorgvuldig in de gaten gehouden met DNSVIZ (http://dnsviz.net/), om te zien of de validatie intact bleef. We hebben geen onderbrekingen gezien. Wel levert het interessante plaatjes op, die bewijzen dat deze methode de chain-of-trust intact laat:
DNSVIZ 1: Stap 1 t/m 5
DNSVIZ 2: Na stap 6
DNSVIZ 3: Na stap 10
DNSVIZ 4: Na stap 11
DNSVIZ 5: Na stap 12
DNSVIZ 6: Na stap 14
Overdracht ZSK
Het kan dus wel, een secure transfer. De enige stap die in dit proces moeilijk te automatiseren is, is stap 5 waar de nieuwe operator zijn nieuwe ZSK naar de oude DNS operator moet sturen op een veilige manier. Het enige veilige kanaal dat momenteel bestaat is het administratieve registry-registrar-reseller-registrant-dns-operator kanaal om de key van de ene kant naar de andere te krijgen. Het is hetzelfde kanaal dat gebruikt wordt voor het bootstrappen van een delegatie. Het is vrijwel onmogelijk om hier een many-to-many communicatiekanaal voor te bedenken. Vandaar dat we in de draft RFC voorstellen om de registry hier als een soort dropbox te laten fungeren om de key van de nieuwe naar de oude operator te krijgen.
Auteur: Antoin Verschuren
