5

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. Some DNS servers are passing the request on merrily to the NS servers set in the zone file; however, some others (such as Google, Level 3 and OpenDNS' public DNS servers) aren't resolving the records properly. They return the proper NS records but requests for A records at the sub-delegated DNS server are not being returned. I have provided plenty of output below; but the gist of it is, the requests aren't being referred to the NS records I set at QUICKROUTEDNS.COM for the domain which are NS records pointing to Amazon's cloud DNS. Instead the requests are stopping at QUICKROUTEDNS.COM. So 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?

Here's an example:

The domain's DNS records at the registrar:

Name Server: NS1.QUICKROUTEDNS.COM
Name Server: NS2.QUICKROUTEDNS.COM
Name Server: NS3.QUICKROUTEDNS.COM

Pulling the NS records for the domain (the authoritative DNS, QUICKROUTEDNS.COM, has these servers set as the NS record):

$ host -t NS domain.com 
domain.com name server ns-1622.awsdns-10.co.uk.
domain.com name server ns-1387.awsdns-45.org.
domain.com name server ns-774.awsdns-32.net.
domain.com name server ns-48.awsdns-06.com.

An A record from the Amazon DNS servers hosting the domain:

$ host www.domain.com ns-1387.awsdns-45.org
Using domain server:
Name: ns-1387.awsdns-45.org.
Address: 205.251.197.107#53
Aliases:

www.domain.com has address 201.201.201.201

Yet, when I request it from any given nameserver:

$ host www.domain.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

Host www.domain.com not found: 3(NXDOMAIN)

This is consistent amongst almost every DNS server, although there are a FEW that will report the A record as expected.

Here is a dig +trace output when trying to pull the A record:

$ dig @8.8.8.8 www.domain.com A +trace                                                                         

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.domain.com A +trace
; (1 server found)
;; global options: +cmd
.           1341    IN  NS  m.root-servers.net.
.           1341    IN  NS  j.root-servers.net.
.           1341    IN  NS  a.root-servers.net.
.           1341    IN  NS  d.root-servers.net.
.           1341    IN  NS  f.root-servers.net.
.           1341    IN  NS  c.root-servers.net.
.           1341    IN  NS  b.root-servers.net.
.           1341    IN  NS  e.root-servers.net.
.           1341    IN  NS  i.root-servers.net.
.           1341    IN  NS  h.root-servers.net.
.           1341    IN  NS  g.root-servers.net.
.           1341    IN  NS  l.root-servers.net.
.           1341    IN  NS  k.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 58 ms

net.            172800  IN  NS  a.gtld-servers.net.
net.            172800  IN  NS  e.gtld-servers.net.
net.            172800  IN  NS  c.gtld-servers.net.
net.            172800  IN  NS  b.gtld-servers.net.
net.            172800  IN  NS  g.gtld-servers.net.
net.            172800  IN  NS  i.gtld-servers.net.
net.            172800  IN  NS  j.gtld-servers.net.
net.            172800  IN  NS  k.gtld-servers.net.
net.            172800  IN  NS  h.gtld-servers.net.
net.            172800  IN  NS  f.gtld-servers.net.
net.            172800  IN  NS  d.gtld-servers.net.
net.            172800  IN  NS  m.gtld-servers.net.
net.            172800  IN  NS  l.gtld-servers.net.
;; Received 503 bytes from 192.36.148.17#53(192.36.148.17) in 586 ms

domain.com.     172800  IN  NS  ns1.quickroutedns.com.
domain.com.     172800  IN  NS  ns2.quickroutedns.com.
domain.com.     172800  IN  NS  ns3.quickroutedns.com.
;; Received 153 bytes from 192.55.83.30#53(192.55.83.30) in 790 ms

domain.com.     3600    IN  SOA cns1.atlantic.net. noc.atlantic.net. 2016033004 28800 7200 604800 3600
;; Received 88 bytes from 69.16.156.227#53(69.16.156.227) in 712 ms

As we can see, it's only getting to the QUICKROUTEDNS.COM nameservers and not going to request from the Amazon nameservers. So, how do I tell DNS servers to fetch its queries from the Amazon servers and NOT to stop at QuickRouteDNS.COM?

Improve this question
1
  • 1
    If you want anyone to be able to help troubleshoot, you need to post the actual domain name. Since this is all your public domain name and addresses, there's no security implication to doing so.
    – Ward - Trying Codidact ♦
    Apr 1, 2016 at 4:39

2 Answers 2

Reset to default
6

There are really two questions being asked here, and they directly contradict each other:

  1. 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?
  2. 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.

Improve this answer
3
  • 1
    "What you have right now is a common misconfiguration known as a NS record mismatch" Also often known as "lame delegation".
    – Patrick Mevzek
    Mar 29, 2021 at 15:49
  • @PatrickMevzek Yeah, it would be better to refer to it by the correct term outright. I've made the edit. Thanks for keeping us DNS nerds honest as always. :)
    – Andrew B
    Mar 30, 2021 at 22:16
  • But I guess nowadays some people may feel "lame" to be too strong/derogatory so maybe that will get removed from "official" terminology. At least a lot of past documentation uses that term, so useful to search online for.
    – Patrick Mevzek
    Mar 30, 2021 at 22:45
1

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:

  1. do not use host for troubleshooting, only dig (but @something and +trace are contradictory)
  2. as said by @Ward, provide the true domain name you are asking about if you want to have good help back to you
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .