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

[Mark Andrews]

In message <alpine.DEB.2.11.1605031737250.3942 at grey.csi.cam.ac.uk>, Tony Finch 
writes:
> 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.

MX's pointing at CNAME chains did actually cause real operational
problems resulting in email not being delivered.  Blocking open
SMTP relaying eventually deal with this at the cost of additional
administative overhead.  One no longer queued email on a high
preference MX for later deliver.

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

MX processing also changed from 'test name for equality' to 'test
addresses for equality'.  Your SMTP servers need to do more lookups
to determine whether they are a MX on the list of MX's.

SRV doesn't tend to be used for store-and-forward though that is
theoretically possible.  If it is used for store-and-forward it has
the same issues as MX with CNAME targets.

For NS -> CNAME to work reliably you need to have CNAME glue in
addition to A and AAAA glue and also change the rules for adding
additional data to add CNAME record chains as well as A and AAAA
records.  Rather than have hard to diagnose failure modes where NS
-> CNAME works some of the time but not always, named doesn't chase
CNAMEs when looking for addresses to send queries to.  This breaks
so resolutions that would have worked but has easily detectable
signature.

Mark

> 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.
> _______________________________________________
> 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