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

Edward Lewis edward.lewis at icann.org
Fri Apr 29 20:30:19 UTC 2016


On 4/29/16, 15:55, "dns-operations on behalf of Andrew Sullivan"
<dns-operations-bounces at dns-oarc.net on behalf of ajs at anvilwalrusden.com>
wrote:

>There have been proposals (one of which is BNAME) to create a new
>RRTYPE that aliases the name and everything beneath it (e.g. they
>function like CNAME+DNAME).  This didn't get very far, and I think the
>reason is because once you start thinking about the sharp corners
>nobody wants to implement such a thing.

I'll claim to have not followed the thread closely while at one time
running across the desire to have a CNAME at the top of a zone.

Proposals to do something like CNAME at apex fall apart when the actions
of a caching server are considered.  If a cache looked up a name and type
and saw a CNAME for the name, then from that point on, all queries for any
type would be fended off to the CNAME target.  If the name was supposed to
have a NS set, the cache would return what was a the target and so on.

The problem is that the DNS is a two-phase search engine.  First search on
the name and once you get the name to get an answer from, find the type.
If it were all in one phase, I suppose it would work better but you'd need
a CNAME with a type-covered like RRSIG does.

The motivation, as far as I knew it, for CNAME at the apex is the use of
Content Distribution Networks that hand out domain names instead of
network addresses to their customers.  If addresses were given out, then
address resource records would be at the apex.  But what is needed is a
name re-write rule (CNAME).

Pressed, my approach would be to short-circuit the need to hand a CNAME by
synthesizing the address records as needed.  I don't know if that would
work though, even if it were fast enough or fresh enough.

The root of all this evil is the use of DNS for traffic management.  DNS
isn't really well suited for that role but it does it well enough that the
use case never seems to go away.  (Round robin as an early case of this.)
So long as you can squeeze out acceptable performance, someone will keep
trying to do it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160429/06eb61fe/attachment.bin>


More information about the dns-operations mailing list