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

Matthew Pounsett matt at conundrum.com
Wed Apr 27 19:16:52 UTC 2016


On 27 April 2016 at 11:33, Mark Jeftovic <markjr at easydns.com> wrote:

> I refer to apex aliasing in the book (almost done) as "the big kahuna of
> protocol violations" in that if there was one rule people wish they
> could break the most often, it's this one.
>
> Given the desire for being able to:
>
> $ORIGIN example.com.
> example.com. IN CNAME example.com.cdn-networks-r-us.dom.
>
> I explain the CNAME and other data rule like this (I suppose this is
> impromptu crowd feedback time):
>
> 'The easiest way I explain the restriction to people is to imagine a
> CNAME as a simple "macro expansion".
>

It isn't really macro expansion though.. it's a redirect.  Saying that "X
CNAME Y" is like macro expansion implies to me that X might do some
processing but also pull in code from Y.  Which is exactly what you're
trying to say CNAME is not.

If you're assuming your reader already has some significant technical
knowledge, then you might be better off using an analogy from another
protocol with redirection capabilities.   Perhaps likening CNAME and other
data to requesting an object from a web server, getting a 301 redirect, and
then simultaneously expecting it to return data from the originally
requested URL.

For the non-technical audience, explaining it in terms of natural language
semantics always seems easiest to me.  "For all information about X see Y
instead" is perfectly understandable to the average person, and when it's
explained that way they tend to see why having other data at X makes no
sense.  If you absolutely need a real-world analogy .. I dunno.. postal
mail forwarding maybe?

It may also be confusing to have your example for CNAME and other data be
CNAME at apex, because that's just a special case of CNAME and other data.
It doesn't really make the point that it's *any* other data that's the
problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160427/8e4054d4/attachment.html>


More information about the dns-operations mailing list