-6

I want to retain dynamic control of the apex, but not break standard handling of other RRs (NS, MX).

Context

A domain name (exampleA.net) is controlled by the domain owner (via the domain registrar). The website shall be placed in exampleB.net cloud.

I want to use dynamic addressing (not calling it CNAME at this point), so the system doesn't stall waiting for the manual update of "A"s in the registrar records.

A complete "NS" zone delegation is not applicable.

The logical, simple configuration, which is invalid:

@   CNAME exampleB.net.
www CNAME exampleB.net.
@   MX    mx
@   NS    ns0
; ...setting the SOA, A's

"Can't do, breaches RFC"

CNAME per the RFC 2181 simply forbids you multiple RRs, barring you to use apex-CNAMEs, because of SOA and NS.

The "dns error" rfc 1912 calls this practice "often attempted by inexperienced administrators".

Well, I doubt that was true even in 1996, it was just the need for a "dynamic" RR (which CNAME is believed to be, but it's not, for these very reasons).

In fact, it's a fundamental flaw of the domain-naming-system. Besides the inception of the holy apex, it really messes up the www.appendectomy. I'm not taking the "canonical no" for an answer here.

it can be accomplished using a preprocessor such as m4 on your host files.

Yeah, right...

Real World Issues

BIND with file-based zones will complain and fail a zonecheck if you try this. But using the DLZ will pass and work, as described. Other DNS software might or might not accept this, or they use some special types (ANAME, ALIAS) for this.

Still, if you manage to pull this off, you have been warned.

The headache starts when queries of any types for exampleA.net will sometimes get resolved as CNAME exampleB.net. instead of the configured record.

That might work, will usually fail, or worse, for example in some MTAs lead to the change/redelivery of mail@exampleA.net to mail@exampleB.net

Incomplete Solutions

Instead of a compliant failure, the recommended workaround is, by setting (delegating) the RR into the CNAME'd record itself.

If you also manage the particular sub-system, you can "pipe" it:

exampleB.net. MX mx.exampleB.net.

or you can "bounce it back":

; pointing the apex CNAME to a more specific exampleA.exampleB.net.

exampleA.exampleB.net. MX mx.exampleA.net.

That's a hotfix at best, doesn't solve the dynamics and leaves the zone exposed to stale configurations and migration booby traps.

Related questions
https://stackoverflow.com/questions/656009/how-to-overcome-root-domain-cname-restrictions
CNAME in @ (BIND)
Set root domain record to be a CNAME

Community
  • 1
rogerovo
  • 254
  • 2
  • 7
  • 7
    What's the question here? So far you've identified that it is not RFC-compliant, and not supported in most DNS systems. Why would you want to deliberately implement something you know to be unsupported? – jimbobmcgee Mar 18 '16 at 01:41
  • 3
    Possible duplicate of [Why can't a CNAME record be used at the apex (aka root) of a domain?](http://serverfault.com/questions/613829/why-cant-a-cname-record-be-used-at-the-apex-aka-root-of-a-domain) – pete Mar 18 '16 at 05:30
  • @jimbobmcgee the question is, how to do this simple task of having a dynamic apex record. CNAME is "done is better than perfect". I described it's limitation, how it works, even when it "shouldn't" and I want to know if there is an another way to do this. going back to that rfc again and again is not helping. – rogerovo Mar 18 '16 at 09:11
  • @pete every question about it ends with that. I'm not looking for explanation "why not" - besides, there is none expect "because I (dns) say so". I'm looking for a (better) solution. – rogerovo Mar 18 '16 at 09:20
  • 4
    It's been 30 years. If there was a "better" solution, it's likely someone would have already found it. You're welcome to give it a go yourself... – Michael Hampton Mar 18 '16 at 09:25
  • that cname hack is working, for part of the problem, if configured down the road too. So the solution so far is using DLZ in BIND to circumvent the startup zone check. – rogerovo Mar 18 '16 at 09:38

1 Answers1

7

I'm the guy who wrote the Q&A that was linked to in the comments, so suffice it to say I've spent some time studying the brain damage surrounding attempts to "make this work".

This is basically a non-starter. You're taking this into the realm of "undefined behavior" because there is no well-defined specification for how nameserver software will interact with this. Yes, you can totally ignore the fact that RFC 2181 specifies that the right hand side of a NS record must not be an alias, or that CNAME records can't coexist with NS records, and the rest of the internet is also free to completely ignore you when you choose to do so.

  • A case example of this is what happens when nameserver software encounters a NS record pointing at a CNAME alias. Some software may choose to gracefully put up with the brain damage, but BIND operating as a recursor plays hardball. That NS record gets dropped on the floor when it's encountered, even though it might have the appearance of initially working due to the glue records provided by the registrar. Once the glue expires and the truly authoritative records are loaded, kiss that zone byebye and say hello to SERVFAIL, Population: You.

  • Once you take this into consideration, all you're left with is custom sythesis of record types that will not break other nameserver software. That's not a CNAME record. That's a custom feature akin to other "fake" record types like ALIAS. By all means, authors of server software are free to write convenience features that accomplish the user's end goal without breaking the standard.

Breaking the standard is, bluntly, ignorant and irresponsible no matter how good the intentions are. DNS is one of the most ubiquitous protocols for the internet and well-understood inter-operation is crucial. Electing to dabble with undefined behavior for this sort of thing does nothing but cause pain for everyone.

Call it a "fundamental flaw" if you like, but reality is cold and uncaring. Fixing this requires that an RFC updating 2181 be authored, and that other nameserver software implement the new requirements. That is the beginning and end of this problem.

Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • I was not talking about CNAMing NS or MX. That might have some sanity to it. – rogerovo Mar 18 '16 at 23:50
  • 2
    You can't `CNAME` the apex without a `CNAME` of the `NS` records at the apex. (at least, not without a standard describing why that is the exception to the rule and explicitly how to handle the exception) The implication RE: `MX` wasn't that you were talking about `MX`, just that it's in the same category of forbidden behavior. I'll edit. – Andrew B Mar 18 '16 at 23:52
  • So the bottom line is, write your apex A into stone. I'm just looking for a solution to make a zone that is split up between two governing entities managable. DNS was designed to do this as I see it. I can fix my server, but try telling to godaddy that they should introduce ALIAS or something. CloudFlare tried a similar trick, still got bashed just because they called it "cname" :) – rogerovo Mar 19 '16 at 00:01
  • 2
    Write it into stone how? RFC 2181 also forbids the coexistence of `A` with `CNAME`. We're back to updating RFC 2181. – Andrew B Mar 19 '16 at 00:02
  • no, make the apex an A. if you need to change it, just wait a week or two for the admins to read the mails. – rogerovo Mar 19 '16 at 00:04
  • Ah. Yeah, pretty much. The classic workaround is to HTTP redirect apex into `www`. It's really easy to farm that piece out to anyone on the internet. – Andrew B Mar 19 '16 at 00:06
  • now we start going in circles. Thanks for the input anyway. I wont be breaking the internet anymore, today. – rogerovo Mar 19 '16 at 00:09