Setting NS for Subdomain to Another Hosted Zone with Same Apex Domain

Question

Suppose I own example.com.

I delegate the subdomain www.example.com to a particular set of NS that is say a Route53 Hosted Zone. The rest of the example.com zone is not on R53 and contains important information for other subdomain/records. You can consider this Zone 1, and you can consider the new R53 Hosted Zone as Zone 2.

I want to have www.example.com CNAMEd to a particular endpoint, say a cloudfront distribution. Since I can't CNAME the apex domain, instead hosted zone 2 is created in R53 with the original apex domain: example.com. Then, inside that hosted zone, there is a record for the subdomain www.example.com with the CNAME to xxx.cloudfront.net.

I can't directly configure www.example.com with the CNAME in hosted zone 1 for various reasons, including that the CNAME is always changing and the person controlling the CNAME only has control over zone 2.

So the full chain looks like this: User types in www.example.com, they get NS hosted 1 records. In that zone, the record for www.example.com points to Hosted zone 2 records. In this zone (which was created with apex example.com) the record for www.example.com is a CNAME to the proper endpoint.

My question: will any DNS resolvers mistakenly cache the NS from the second zone as apex domain records? Obviously, I want those NS accessed only for the www.example.com records. If example.com NS records are mistakenly thought of as in hosted zone 2, there can be a lot of issues.

If this is the case, is there any way to make sure to DNS resolvers that the apex domain nameservers are zone 1, and zone 2 records are ONLY for www.example.com, even though they were created with the example.com apex domain?

I understand that there are other ways to do this (CNAME to separate domain, etc) but for logistical purposes (for now) I am only interested in setting the NS directly for the www subdomain.

Answer 1

While unusual, you can certainly delegate www.example.com to a different set of nameservers than example.com.

There is no reason for nameservers to cache nameservers authoritative on www.example.com as authoritative for example.com, so this problem will never happen.

But by delegating www you close the option for example to have it as a CNAME, and I am just mentioning it for completion, as it seems exactly what you want to fly away.

To say differently: if your example.com zone has NS records for www.example.com to delegate it further to a second set of nameserver, you CAN NOT have at the same time a CNAME record on www in the example.com zone. This setup won't be accepted by any decent nameservers, the authoritative ones on example.com would/should refuse to load such a zone.

The authoritative nameservers for www.example.com must be authoritative for www.example.com this is their apex, not example.com. They can not be configured to be authoritative for example.com, nor can they have a CNAME record for www as www.example.com since this is their apex and hence already has SOA and NS records which makes CNAME presence impossible. That part is not very clear from your question, so not sure to follow (things are far clearer with real names and dig outputs...)

Note that of course the nameservers for www.example.com must be "real" nameservers replying correctly on the DNS level for many things, and not just A query types, like SOA and NS record types. I am writing that because, from experience, when I saw people delegating www it was often to close boxes acting as load balancer and handling both HTTP(S) and DNS traffic, unfortunately they were often very broken at the DNS level (not reply to NS queries for example or answering NS queries with A records pointing back to themselves or other nightmares...) which created all sort of difficult edge cases. So just saying so in passing, make sure to delegate your www to something that really acts as a nameserver and not just pretend to be one on the surface.

Also, you may not want to hear that, but still, since your premise is "the CNAME is always changing and the person controlling the CNAME only has control over zone 2." and then you try to work around this, the real proper solution is instead:

www.example.com CNAME www.example.com.your-provider.example

and then your provider is free to fiddle with the record www.example.com.your-provider.example as much as it wants and even make it a CNAME changing each 5 minutes. It has full control over it, and you gave him the authority over it thanks to your own CNAME that will stay once for all, without you having to really delegate, at the DNS level, part of your zone to other nameservers.

I am not claiming this is the same case, but observe the similarity:

$ dig www.microsoft.com +noall +ans
www.microsoft.com.  8m51s IN CNAME www.microsoft.com-c-3.edgekey.net.
www.microsoft.com-c-3.edgekey.net. 7m25s IN CNAME www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. 8m24s IN CNAME e13678.dspb.akamaiedge.net.
e13678.dspb.akamaiedge.net. 14s IN A 23.217.196.148