[dns-operations] Adding CNAME for the root domain issue

Mark Andrews marka at isc.org
Wed Apr 27 19:06:36 UTC 2016

The real issues here is that brower vendors are too SCARED to support
SRV.  We can make SRV always return address records with proper
signaling to tell the recursive server to explicitly fetch server
address records if they are missing from the cache before responding
to the SRV request.  That's all CNAME chaining does except it is
implicit instead of explicit.

A with AAAA would solve the additional lookup issue.  Sending both
SRV and AAAA in parallel would solve the entire delay issue.

Use the same bit for A with AAAA and addresses with SRV.


In message <572105E5.5040608 at easydns.com>, Mark Jeftovic writes:
> I refer to apex aliasing in the book (almost done) as "the big kahuna of
> protocol violations" in that if there was one rule people wish they
> could break the most often, it's this one.
> Given the desire for being able to:
> $ORIGIN example.com.
> example.com. IN CNAME example.com.cdn-networks-r-us.dom.
> I explain the CNAME and other data rule like this (I suppose this is
> impromptu crowd feedback time):
> 'The easiest way I explain the restriction to people is to imagine a
> CNAME as a simple "macro expansion".
> In our apex aliasing case above, a query for the SOA or the NS recs of
> example.com would never return the defined SOA for "example.com" but
> rather they would be interpolated into queries for the SOA or NS records
> of *example.com.cdn-networks-r-us.dom* (the value the CNAME for
> example.com points at).
> The authoritative nameserver answering for *example.com* would never
> return the SOA or NS recs for *example.com.cnd-networks-r-us.dom*
> because they are outside its zone.'
> - mark
> On 2016-04-27 1:59 PM, Andrew Sullivan wrote:
> > On Wed, Apr 27, 2016 at 09:29:49AM -0700, Matthew Pounsett wrote:
> >> specification says it can't.   And the reason it says it can't is because
> >> having a CNAME and any other data is ambiguous.  This paragraph presents it
> >> as if the rule is just arbitrary, and has no real justification.
> > 
> > I don't think it's ambiguous at all.  I think it's by definition impossible.
> > 
> > The semantics of "CNAME" are, "the owner name is actually this other
> > name".  Therefore, to have any other data at the CNAME would be
> > absurd.  We sort of wave our hands at this with RRSIGs, because of the
> > way that the DNS control plane and data plane are intermingled.  But
> > the basic problem is the very meaning of CNAME and the definition of
> > an apex (which, of course, requires an SOA).
> > 
> > This is a subtle point about CNAME, though, and very few people seem
> > to understand it.  I think it's because people don't look at the DNS
> > in itself, and really think it's just the way to connect to A/AAAA
> > records.  If you look at things that way, naturally, the subtleties of
> > CNAME are annoying.  Another use for the DWIM RRTYPE!
> > 
> > Getting the use cases right in general for this sort of alias record
> > is tricky.  It's taken Dyn several years finally to agree on exactly
> > the right way to do it -- we had a couple earlier designs that didn't
> > make the cut because we were unhappy with some of the side effects.
> > (The final version is now available, although I believe it's been a
> > soft launch.)
> > 
> > By the way, the "root of the zone" thing is all over the DNS industry.
> > Rooting that out (ha!) at one employer may have been my most useful
> > contribution.  
> > 
> > A
> > 
> -- 
> Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc.
> Company Website: http://easydns.com
> Read my blog: http://markable.com
> +1-416-535-8672 ext 225
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the dns-operations mailing list