-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
  • 264

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
  • 33,868