Transfer of DNSSEC-enabled domains: IETF method is preferred

October 2012

Internet hosting provider Oxilion recently hosted a Lunch & Learn meeting at its offices. At the meeting, a number of internal and external DNS specialists talked about the transfer of DNSSEC-enabled domains.

The underlying issue was quickly apparent: the transfer of a signed domain from one DNS operator to another without interrupting its security depends on cooperation between the releasing operator and the receiving operator. Both parties have to cooperate fully, even though the releasing operator is certainly losing the domain in question and may be losing the customer altogether. Although the two operators should in principle be able to exchange information without difficulty, the practical reality is often less straightforward.

Two methods

The transfer of a secure domain needs to fulfil three criteria: the domain has to remain secure throughout the transfer, the domain has to remain fully functional throughout the transfer, and the two DNS operators shouldn't exchange private keys.

To date, two transfer methods have emerged that fulfil those criteria:

  1. The

    IETF method

    :

    In the IETF method, invented by SIDN, the old ZSK is added to the new DNS operator's zone ahead of the transfer and signed with a new KSK. Then the new ZSK is added to the old DNS operator's zone and signed with the old KSK. After that, the administrative transfer (registrar change) can go ahead and the new KSK (DS) can be uploaded to SIDN, so that the new zone can be validated. Once the old key set's TTL has expired (a potential show-stopper), a DNS operator change (NS change) can be performed. The TTL of the old NS set (a fixed value) then has to be allowed to expire before the old KSK (DS) can be deleted from SIDN's database. Finally, once the TTL of the old DS records (a fixed value) has also expired, the new ZSK can be deleted from the old zone.

    MethodeIETF0

    Advantages:

    • The process is clearly defined and can be fully automated.

    • The message containing the new ZSK can be authorised by means of a token.

    • Full support is possible even if the releasing registrar isn't the DNS operator.

    • The system is suitable for implementation by multiple registries/TLDs.

    Disadvantages:

    • The system involves a significant number of steps.

    • It's necessary to wait until the TTL of the old KEY set has expired. If the TTL is very long, transfer will be practically impossible without a security interruption.

  1. The

    ICANN method

    :

    With this method, the new KSK (DS) is uploaded to SIDN and linked to the domain name in anticipation of the DNS operator change. That is done while the domain is still registered through the old registrar and the old name servers are still in use. Once the DS records' TTL (a fixed value of two hours) has expired, the receiving DNS operator has to import the old zone in its entirety. That could be done via AXFR, with the registry acting as proxy. The advantage of that arrangement is that the DNS operators could easily make arrangements amongst themselves. The drawback is that a lengthy list of ACLs would have to be maintained. Thereafter, the new ZSK is added to the zone and the RRSet is signed with the new KSK. The zone can then be signed with the new ZSK, but the old RRSIGs are retained. After that, the DNS operator change (name server change) can go ahead. Once TTL of the parent NS (a fixed value) has expired, validating name servers will refer to the new zone for validation. Validation of the old records nevertheless remains possible because the old RRSIGs have been retained.

    MethodeICANN0

    Advantages:

    • The process is relatively straightforward and involves relatively few steps.

    • It isn't necessary to wait to a TTL over which the receiving registry has no control. The length of the waiting time is therefore known in advance and the process can be completed within an acceptable time frame.

    Disadvantages:

    • The entire zone has to be transferred from the old DNS operator to the new one. That could be done by opening AXFR, thus enabling automation. However, DNS operators won't necessarily welcome the idea of opening AXFR to the registry or the receiving DNS operator.

    • Timing will be critical, since the old RRSIG records will have fixed validity periods. Once an RRSIG record's validity has expired, the associated domain is liable to be treated as bogus.

    • Throughout the transfer (from the time of the zone transfer), no changes may be made to the old zone without sharing the relevant information with the new DNS operator.

Consensus

After considering the pros and cons of the two methods, the group agreed that the ICANN method was the only workable solution for automation on the basis of AXFR. However, the group didn't believe that that would happen in practice. Furthermore, the IETF method was seen as offering real scope for implementation within SIDN and other registries. The TTL-related issue with the IETF method did not lend itself to a technical solution, but could be addressed by procedural or other means. For example, SIDN could require DNS operators to use acceptable (i.e. reasonably short) TTLs for DNSKEY information in the zone. The group concluded that the IETF method was preferable and advised SIDN to make that method the basis for future developments in this field. However, the group wanted registrars to retain the option of using the ICANN method if both parties to a transfer wanted that.

Comments

  • Wednesday 16 January 2019

    Internet security

    Registrants and operators need to test for EDNS compliance

    Thumb-error-people-inside-computer

    Domain names on non-compliant servers may be unreachable after 1 February

    Read more
  • Tuesday 26 March 2019

    .nl-domainname

    Our terms and conditions are changing

    Thumb-man-examining-a-document-with-a-magnifying-glass

    New T&Cs effective from 1 May 2019

    Read more
  • Thursday 11 January 2018

    SIDN Labs

    Best wishes for 2018!

    Thumb-Marco-Davids-SIDN-Connect

    Looking back at SIDN Connect 2017 and ahead at the year to come

    Read more

Sorry

Your browser is too old to optimally experience this website. Upgrade your browser to improve your experience.