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

Tony Finch dot at dotat.at
Tue May 3 16:51:04 UTC 2016

Paul Vixie <paul at redbarn.org> wrote:
> Tony Finch wrote:
> >
> > It's worth looking at RFC 882 and RFC 973 for the pre-standard history.
> > CNAME was originally a fallback, so the canonical/target name was only
> > used if the queried type was missing at the alias/owner name. This was
> > changed because:
> >
> >        The specification allows CNAME RRs to exist with other RRs at the
> >        same node.  This creates difficulties since the other RRs stored
> >        with the CNAME at the alias might not agree with the RRs stored at
> >        the primary name.
> >
> >        If a node has a CNAME RR, it should have no other RRs.
> >
> > The pre-standard logic would have worked nicely for CNAME-at-apex.
> what's missing from this text is that with cname in its present form as
> a fallback, it's uncacheable. a cache having some RRsets at a name, upon
> hearing a query for a type it doesn't have, would always have to forward
> to the authority. the cache would then hold synthesized rrsets. probably
> these would have to be sent from the authority with TTL=0.
> so, i disagree with your term, "nicely".

I don't understand the problem.

I thought what would happen is just like the current per-type positive /
negative cacheing for non-CNAME types. When a cache gets a query for a
type it doesn't have, query the origin, and cache positively or
negatively. If it gets a negative result from the origin or the cache,
look for an old-CNAME (query for it if necessary and cache positively or
negatively per-type as usual); if it gets an old-CNAME from the origin or
the cache, re-do the query at the target.

> > The paragraph that mentions BIND (quoted below) talks about NS records
> > pointing at CNAME aliases, which are still deliberately ignored by BIND.
> not just bind, and not just ns -- see also mx.

The mail servers I am familiar with chase CNAME chains. There's some ugly
wording in RFC 5321 resulting from several long flamewars; it tries to say
that MX-pointing-at-CNAME is non-standard but it isn't forbidden because
that's not what running code does.

The key practical difference is that NS-pointing-at-CNAME causes horrible
problems for the DNS resolution process itself; there's no such bootstrap
difficulty for MX or SRV.

f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire: Southwesterly backing southerly 3 or 4, occasionally 5 later.
Slight or moderate. Fair. Good.

More information about the dns-operations mailing list