[Opendnssec-develop] Domain transfers under DNSSEC
roy at nominet.org.uk
Fri Dec 5 12:13:31 CET 2008
Rick van Rein wrote on 12/04/2008 10:37:29 AM:
> I am pondering how domain transfers would take place under DNSSEC.
> As expected, SIDN worries about it, and it also touches on OpenDNSSEC
> (evntually) when the platform is used by a hosting provider.
> We would not want to share private key material between an old and new
> signer, since these will usually be different parties and because the
> same key may (according to some on this list at least) be shared among
> multiple zones.
> A transfer is effectively a NS change in a TLD server. Since NS and DS
> records are presented at the same time, it is possible AFAIK to do a
> simultaneous DS changeover, in such a way that no cache will ever hold
> NS from one generation, and DS from another.
> Given this, it should be possible to do a key rollover, even with a
> DS at the parent, by performing a variation on the KSK rollover
> using temporary double KSK signatures:
> 1. Setup DNSSEC on the new signer
> 2. Move the old KSK to the new signer and move the new KSK to the old
> 3. Sign the zone on the old and new signer and hold off auto-resigning
> 4. Append old RRSig(KSK) in the new zone and new RRSig(KSK) in the old
> 5. Allow time for caches to pick up on the new zone data
> 6. Ask the parent to switch to the new DS+NS records simultaneously
> 7. Wait for the parent to publish the new DS+NS records
> 8. Wait for caches to pick up on the new DS+NS records and shutdown old
> 9. Remove the old DNSKEY from the new zone and resign at your leasure
This assumes that the transferring parties are highly cooperative, which
is not the general case. When 'hostile' parties transfer a domain, it will
probably fall back to unsigned (ie. no DS record at parent). When
'friendly' parties transfer a domain, the new owner can present the DS+NS
record. The scheduling for this scenario is the same as a standard domain
transfer, though the impact is bigger when either party (or the parent)
> I think this should work based on the following principles/assumptions:
> 1. DS and NS changes can be made at the same time
> 2. DNSKEY records should simply be added to the pre-signing zone
> 3. RRSig records can simply be appended to a signed zone (wow, hack!)
> 4. NSEC3 calculations do not have to be redone when RRSig records are
> as long as the name of the newly added RRSig already has an RRSig on
> 5. The loosing registrar cooperates, by incorporating the new key
> and signatures. This has legal implications (making registrars
> technical (making registrars synchronise on the procedure) and
> (the old registrar must be convinced the transfer is proper, which
> applies to any transfer scheme without downtime). Although
> could be enforced by registry ruling, it is probably the weak point
> this scheme. Note however, that the information exchanged between
> old and new registrar is all public.
> Could this be a useful aspect to take into account for v2 of OpenDNSSEC?
> I think it could dramatically ease the worries of a TLD. Also, it
> out a form of cooperation that TLDs may want to use as an obligation to
> registrars who support DNSSEC.
It might be useful, but the possible scenarios of registrant/hosting
farm/registrar/registry are so diverse, it is likely that whatever code we
produce to ease that problem will only cause confusion to those who can't
I do not want to declare it 'out of scope' though. Coming year, a few
large registries will deploy DNSSEC, and we can gauge the community a bit
and see where things converge.
More information about the Opendnssec-develop