[Opendnssec-develop] Domain transfers under DNSSEC

[Roy Arends]

Rick van Rein wrote on 12/04/2008 10:37:29 AM:

> Hello,
> 
> 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 
single
> DS at the parent, by performing a variation on the KSK rollover 
procedure,
> 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 
signer
> 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 
zone
> 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 
signer
> 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) 
screws up.
 
> 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 
added
>    as long as the name of the newly added RRSig already has an RRSig on 
it.
> 
> 5. The loosing registrar cooperates, by incorporating the new key 
material
>    and signatures.  This has legal implications (making registrars 
cooperate),
>    technical (making registrars synchronise on the procedure) and 
security
>    (the old registrar must be convinced the transfer is proper, which 
probably
>    applies to any transfer scheme without downtime).  Although 
cooperation
>    could be enforced by registry ruling, it is probably the weak point 
of
>    this scheme.  Note however, that the information exchanged between 
the
>    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 
points
> 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 
use it.

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.

Thanks.

Regards,

Roy Arends
Sr. Researcher
Nominet UK