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:

  1. Primary gaan draaien voor sidnlabs.nl op de nieuwe name server proteus.sidnlabs.nl.
  2. Nieuwe DNSSEC keys aanmaken voor sidnlabs.nl door de nieuwe operator.
  3. 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
    
  4. 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== )
    
  5. 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.

  6. 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== )
    
  7. 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 )
    
  8. 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.

  9. 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.

  10. 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.
    
  11. 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.

  12. 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 )
    
  13. De oude zone verwijderen van ns1.sidn.nl.

    Nu konden de oude zone en de oude keys ook worden verwijderd van ns1.sidn.nl.

  14. 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 1: Stap 1 t/m 5

DNSVIZ 2: Na stap 6

DNSVIZ 2: Na stap 6

DNSVIZ 3: Na stap 10

DNSVIZ 3: Na stap 10

DNSVIZ 4: Na stap 11

DNSVIZ 4: Na stap 11

DNSVIZ 5: Na stap 12

DNSVIZ 5: Na stap 12

DNSVIZ 6: Na stap 14

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

Antoin Verschuren

Functie: Technisch adviseur
Bij SIDN sinds: 2005

Relevante opleidingen:
Electrotechniek aan de TUE

Vorige werkgevers:
Ik bekleedde diverse functies bij internet service providers van het eerste uur, waaronder IAE, bArt, en VIA Net.works, tegenwoordig Claranet.

Wat ik doe bij SIDN:
Sinds 2005 werk ik bij SIDN als 'Technical Policy Advisor'. Eerst op de afdeling Policy & Business Development, tegenwoordig bij ICT.
Als technisch adviseur is het mijn verantwoordelijkheid om onderzoek te doen naar en advies te geven over technologische ontwikkelingen en concepten, zodat technische verbeteringen en vernieuwingen tot stand komen. Ik richt me daarbij vooral op de impact van technisch beleid en vertaling van technische ontwikkelingen naar visie.
Samen met de andere technisch adviseurs behartig ik de belangen van SIDN en de lokale internetgemeenschap in, onder andere, de IETF- en RIPE community, DNS -OARC, ICANN en CENTR.