[Opendnssec-develop] Signing two-faced domains
roy at nominet.org.uk
Tue Dec 2 20:47:51 UTC 2008
Rick van Rein wrote on 12/02/2008 09:26:16 PM:
> There is one more anomaly in DNS usage patterns that I think is valuable
> to discuss early in the design of OpenDNSSEC.
> High-profile domains will run on multiple locations, and employ DNS to
> make a quick switch from the primary location to a backup if the primary
> fails. This usually means that more than one view on a zone is valid
> at the same time. There are a few ways of supporting this under DNSSEC:
> 1. Publish a DS record per view. Not likely that a zone's parent is
> going to want this though. Parents are usually the kind of people
> that enviously try to give all children an equal treat.
> 2. Use the same KSK for each view on a domain. Synchronise key
> (which is fairly trivial as the same parent is being watched for the
> same domain) and simply don't publish the backup views until they are
> needed. This seems to be the most likely scenario.
> 3. Quickly update DNS and re-sign when there is a need to switch to a
> backup location. This alternative has a few disadvantages that
> conflict with the desires at the time of primary site failure,
> namely (1) that it takes time and (2) that it uses more resources
> and is thus more likely to break during a time of crisis.
I see no problem here, as long as these views are reachable from the
public internet, and as long as the KSK that was used to create the DS
record at the parent does not change. There is a slight issue when view
specific NSEC or NSEC3 chains are mutual exclusive, but that is unlikely.
> This is another reason to allow signing of multiple zones with a shared
I disagree. These are not multiple zones. These are multiple views of a
single zone. I'm not splitting hairs, these are different concepts.
> But there's another exceptional issue happening here: there may
> be two or more concurrent versions of the same zone, and each will have
> to be signed. In terms of programming, the name of a SOA record cannot
> be treated as an identity for a zone to sign!
Yes. Good point.
> A similar problem applies to multiple-view domains, such as those with
> a different internal/external view. Those are more trivial however,
> as internal settings in the vicinity of the secure resolver can easily
> be overridden without doing DNSSEC (at least until each desktop resolves
> securely on its own).
> I don't know if this has been discussed before, since we've just landed
> on the list and since there's no public archive available.
Actually, there is a public archive:
but the url is not public.
More information about the Opendnssec-develop