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

Tony Finch dot at dotat.at
Tue May 3 10:11:30 UTC 2016

John Levine <johnl at taugh.com> wrote:
> It would be nice to hear from people who were there at the time, but
> until then, RFC 1033 says:

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.

> RFC 1912 says: [...]
> It then describes workarounds for CNAME related bugs in BIND which I hope
> have been fixed in the intervening 20 years.

The paragraph that mentions BIND (quoted below) talks about NS records
pointing at CNAME aliases, which are still deliberately ignored by BIND.

   Having NS records pointing to a CNAME is bad and may conflict badly
   with current BIND servers.  In fact, current BIND implementations
   will ignore such records, possibly leading to a lame delegation.
   There is a certain amount of security checking done in BIND to
   prevent spoofing DNS NS records.  Also, older BIND servers reportedly
   will get caught in an infinite query loop trying to figure out the
   address for the aliased nameserver, causing a continuous stream of
   DNS requests to be sent.

f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Biscay: Variable 4, becoming easterly 5 or 6, occasionally 7 in
southwest. Moderate or rough. Mainly fair. Mainly good.

More information about the dns-operations mailing list