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

[Matthew Pounsett]

On 27 April 2016 at 10:59, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:

> On Wed, Apr 27, 2016 at 09:29:49AM -0700, Matthew Pounsett wrote:
> > specification says it can't.   And the reason it says it can't is because
> > having a CNAME and any other data is ambiguous.  This paragraph presents
> it
> > as if the rule is just arbitrary, and has no real justification.
>
> I don't think it's ambiguous at all.  I think it's by definition
> impossible.
>

I should have said "at best ambiguous"... I think that's probably what I
actually meant when I was writing that.   Earlier in the thread (on
bind-users) I made exactly the same point about the semantics of CNAME and
how it makes no sense to have other data present.


> Getting the use cases right in general for this sort of alias record
> is tricky.  It's taken Dyn several years finally to agree on exactly
> the right way to do it -- we had a couple earlier designs that didn't
> make the cut because we were unhappy with some of the side effects.
> (The final version is now available, although I believe it's been a
> soft launch.)
>

We've had similar problems at eNom trying to get it right.  We're still
allowing users to put CNAMEs at the same owner name as other data in the
UI, but we replace those before they get to a DNS server.

The records we synthesize are extremely case-specific, as we've found that
what users expect from CNAME and other data (not just at the apex) varies
based on the records that are present at the target domain name.  Thanks to
the efforts of one very bright developer, we think we've nailed down
something that works and gets users fairly close to their anticipated
behaviour in most cases (80/20 rule in action).   We're slowly working our
way back up the stack clean things up so that we can present the user with
something in the UI that engenders less confusion.


> By the way, the "root of the zone" thing is all over the DNS industry.
> Rooting that out (ha!) at one employer may have been my most useful
> contribution.
>

I will be happy if that particular misuse of terms disappears completely,
and I point out the error everywhere I see it.  I'm not holding my breath,
though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160427/e6a6c392/attachment.html>