Subject: [dnsext] common resources from multiple names, sustaining performance and identifying primary names

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Sep 2010 18:36:36 -0700

While aliasing a name is how common resources seen from multiple names 
are normally handled, CNAME and the seldom used DNAME are not very 
suitable for renaming large portions of the name/resource tree.  
Resolvers that don't understand DNAME, and those that don't understand a 
new aliasing paradigm will then need each node replaced with synthesized 
CNAME records having 0 TTLs. It seems this approach on a large scale is 
likely to result in a significant performance reduction.

Synchronizing (amber/shadow) zones could be something that virtualized 
name servers might accomplish, when given the necessary 
meta-information.  While zone synchronization avoids the problematic 
performance issues that might be caused by new and pervasive aliasing, 
multiple zones will leave applications unable to identify which name is 
to be considered primary. Name consolidation onto a primary name and 
message path has the added benefit of obtaining higher cache hit rates 
and perhaps needing fewer certificates.  When aliasing is used, a 
different answer-name from that of the query-name indicates the 
answer-name is the primary domain.  There does not seem to be an 
analogue that might be used to discover which domain should be 
considered primary when amber/shadow zones are being used, nor does it 
seem possible to re-purpose the various xName aliasing resources.

It should be possible for the zone cloning processes to include a 
primary domain resource that points to mirror points within the Amber 
zone.  The amber zone could capture the mirror points as hash labels or 
resources holding signatures confirmed by the primary domain public 
key.   The hash label technique, if eventually handled by the protocol, 
might be used to consolidate a large collection of resources as well.  
The definition of a primary name when using Amber/Shadow zones would 
need to be done using some type of meta language.  This meta language 
would likely replace a BNAME construct (a DNAME that aliases itself.)

While BNAMES would increase DNS agility when coping with a convoluted 
name space, it seems that this feature should not be the primary method 
used for introducing TLD and SLD domains when common resources are to be 
obtained from these domains.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Sep 2010 15:56:00 +1000

> likely to result in a significant performance reduction.

Actually the TTL matches (or will [1] and it is shipping in current
nameservers) that of the DNAME which may or may not be zero and the
majority of caching servers on the planet already understand DNAME.
Anything that does DNSSEC validation is required to understand
DNAME.

[1] http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2672bis-dname/

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]