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.

1 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
  • I think you might be slightly misunderstanding. www.example.com is pointing to the Zone 2 with those nameservers, but the zone is created with example.com as an apex domain (example.com NS xx.awsns060.org). Then there is a record for www.example.com which is a CNAME to an endpoint. Essentially, there are now 2 zones (zone 1 and zone 2) both with the same apex. The difference is that the original zone has the www record pointing to the other zone. I see that this is digging fine when I implement it- I am just worried that some resolver somewhere will think that zone 2 is authority for the apex
    – Yayati
    Jan 20, 2020 at 23:10
  • "www.example.com is pointing to the Zone 2 with those nameservers, but the zone is created with example.com as an apex domain (example.com NS xx.awsns060.org" this is not how the DNS works, and you will only create problems for yourself (which you can easily avoid just if you accept to stop trying to go around the real problem). Besides, "I think you might be slightly misunderstanding", probably, but if you used real names and real examples I am sure it would be easier for everyone. Obfuscation, specially for the DNS which is public, is not needed.Let us see if others can understand it better. Jan 20, 2020 at 23:15
  • You said that this can cause problems- if you can elaborate on the nature, that would be helpful. Thanks!
    – Yayati
    Jan 20, 2020 at 23:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.