Setting different NS records as authoritative on authoritative DNS
There are really two questions being asked here, and they directly contradict each other:
- how do I instruct DNS servers to continue their query on to Amazon as its authoritative for the domain, without changing the DNS records at the registrar?
- how do I tell DNS servers to fetch its queries from the Amazon servers and NOT to stop at QuickRouteDNS.COM?
Every delegation in the DNS hiearchy must be more specific than the last. In other words, you can delegate subdomains but you cannot re-delegate the exact same name that has been delegated to your server. The correct solution is to change the configuration at the registrar level, which you are trying to avoid.
What you have right now is a common misconfiguration known as a lame delegation (a mismatch of NS records), which gives an incorrect impression that this design is achievable. Below is an explanation of what is happening, but it will be challenging to follow without a good grasp of DNS concepts. If I lose you, please take it for granted that correcting the registrar data is the proper way to address your issue.
To illustrate, here are two example zone snippets:
$ORIGIN example.com
@ 2941 IN SOA ns1.example.com. someone.example.com. (
2015071001 ; serial
7200 ; refresh (2 hours)
900 ; retry (15 minutes)
7200000 ; expire (11 weeks 6 days 8 hours)
3600 ; minimum (1 hour)
)
@ IN NS ns1
@ IN NS ns2
sub IN NS ns1.contoso.com.
sub IN NS ns2.contoso.com.
On the contoso.com nameservers:
$ORIGIN sub.example.com.
@ 2941 IN SOA ns1.sub.example.com. someone.contoso.com. (
2015071001 ; serial
7200 ; refresh (2 hours)
900 ; retry (15 minutes)
7200000 ; expire (11 weeks 6 days 8 hours)
3600 ; minimum (1 hour)
)
@ IN NS bagel.contoso.com.
@ IN NS bacon.contoso.com.
Which NS records in the above two zones are authoritative for sub.example.com
? If you thought it was ns1
and ns2.contoso.com
, you would be mistaken. Contrary to popular belief, a nameserver which performs a delegation is not considered authoritative for the NS
records used to define that delegation. The authoritative definition is instead owned by the zone on the receiving end of the delegation.
We've established that bacon
and bagel
are authoritative. What isn't so obvious here is that namesevers aren't necessarily going to realize that immediately. Delegations are followed in good faith, and it will initially be assumed that the servers receiving the delegation are authoritative. It's only when those NS
records are refreshed that the brain damage occurs. Refreshes can be triggered by any number of things, from TTL of the delegating NS
records expiring to an explicit request for the value of those NS
records. Once the NS
records are overwritten, the new servers get used.
Putting it all together, there is an initial period where your registrar defined nameservers are being used, followed by a period where the second set of nameservers are being used. During the first period, any records that only exist on the second set of servers will fail. During the second period, any records that only exist on the first set of servers will fail.
It may sound like the problem will eventually fix itself (just wait for everything to refresh), but that will never happen. People will restart their nameservers, flush their cache, or stand up new nameservers. Your domain will exist in an inconsistent state of flux until the NS
records become consistent. DNS gurus can do some interesting things with this, but the valid use cases for this type of configuration are few and far between. The average user should avoid conflicting nameserver definitions at all costs.
Saying "I have DNS servers for a domain set to one set of authoritative DNS servers on the registrar. However, those DNS servers zone file for the domain have a different set of NS records for it." means that you created a lame delegation. You can stop there, as nothing will work correctly with this kind of setup, so do not do this!
Helpful tools to troubleshoot : http://dnsviz.net/ and https://www.zonemaster.net/
2 more things:
- do not use
host
for troubleshooting, onlydig
(but @something and +trace are contradictory) - as said by @Ward, provide the true domain name you are asking about if you want to have good help back to you