[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.
Tony.
--
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