I've come across something interesting that I've never seen before and was hoping someone could help to explain what I'm seeing.

Here's the scenario: I have a domains testdomain.com zone file hosted with a DNS provider called SummitNetworks. On my side, I have a domain hosted with GoDaddy called mycustomdomain.com. Within mycustomdomain.com I have a glue record for ns2.mycustomdomain.com that points back to the name server at summitnetwork.

Now I told summitnetworks that I want the zone they host for me, testdomain.com to point to the NS server ns2.mycustomdomain.com. The reason for this is so that in the future if I choos to migrate this zone to a new DNS provider and a whole bunch of other domains, I would only have to update the NS glue record on mycustomdomain to the new DNS provider name server IP.

Now the question is, when I do a dig and zone lookup against testdomain.com the NS servers point to summitnetworks NS servers, but the referall path points back to ns2.mycustomdomain.com. How's this possible and how can I see the full path for resolution using dig? What's a referral path? When I do a dig against the domain there's no reference to it. The only way I was able to validate this is because I used dnsstuff toolbox

Referall Path


Your question is hard to answer without real information, but your reasoning behind using vanity servers makes no sense to me, when changing NameServers you want to actually change your nameservers, and not your glue records, you also want your SOA to be a real nameserver and not a glue record.

Here's what I think is happening: The Registrar NS record for example.com is different than the zone's NS records.

dig example.com

The Root Servers send you to the com servers, the com servers send you to the nameservers listed in your registrar(godaddy), but those servers do not have your vanity nameservers, they have the real name servers, which (although the same IPs) referres you to the real nameservers' A Record.

So again, ns1.example.com, ns2.example.com is your nameserver with register.com.

but the zone says something like

@ IN NS ns3.example.com
@ IN NS ns4.example.com

Even if ns1.example.com and ns3.example.com are the same IP record, dns doesn't know that, it sees ns3 is not ns1 so it's referred to ns3 for the authoritative answer.

We could confirm this with real info.

If you want to use vanity nameservers, I would suggest keeping your DNS with Godady.

  • Thanks for the response Jacob. Unfortunately it's something I walked into where there are a couple of thousand domains that are going to be migrated to another DNS provider. The reasoning for the vanity servers with glue records was to make this situation of migration easier of all the domains, where the only DNS change would be the vanity server glue records to point to the new DNS provider. It doesn't make sense to me either :(. Hopefully I can dig up some info on referral paths – RomeNYRR Oct 20 '15 at 14:35
  • 1
    Can you post real data or create a chat room? I'd be happy to help – Jacob Evans Oct 20 '15 at 14:51
  • 1
    See updated answer, I hope this sheds some light on your issue. – Jacob Evans Oct 20 '15 at 15:00

Thank you Jacob for being willing to take the time and help me out with this; if I could I would give you +100 pts for that :).

I was able to track down my answer with some tools and DNS logic. So the first issue that I had was whenever I ran a dig www.example.com +trace on my mac, absolutely nothing would come up. At first I thought it was a domain issue but I tried other domains and received the same blank results. So then I said let me try another computer and voila, I was able to go through the full trace for DNS resolution which reveals the answer.

So essentially what happened is this... When testdomain.com was registered with the DNS Registrar, the people who registered the domain pointed the name servers to go to ns1 & ns2.mycustomdomain.com as they were instructed to. This process took place for a couple of hundred domains. The folks that own mycustomdomain.com created vanity servers with glue records pointing back to the DNS Hosting Provider.

What the dig trace revealed was this

  1. First step - query DNS root servers to find which Top Level Domain to talk to
  2. Second step - query Top Level Domain DNS server to find out who's authoritative for testdomain.com
  3. 1st Result - Found nameservers that can respond to queries ns1 & ns2.mycustomdomain.com
  4. 2nd Result - Because those glue records actually point to the NS servers @ summitnetworks.com we get an additional response with the name servers ns1 & ns2.summitnetworks.com - sidenote if we didn't have those glue records the dig would've ended at bullet 3.

Now the migration of these domains and all future domains is going to AWS Route 53. The zone files that I will receive from summitnetworks.com will of course include their SOA and NS servers. When you import your domain into Route53, they will strip out the SOA and Nameservers since they now own this piece. Since I'm doing a large migration into AWS I'm going to create a Delegation Set so that I have the same name servers for every domain that I create in AWS. This will make it so that all we have to do is update the glue records for our vanity servers to point to AWS servers and add 2 more glue records for more added reliability.

Hopefully this helps anyone else who bumps into this.

Sample dig www.google.com +trace so you can follow the path of resolution:

;; global options: +cmd
.           518400  IN  NS  D.ROOT-SERVERS.NET.
.           518400  IN  NS  E.ROOT-SERVERS.NET.
.           518400  IN  NS  F.ROOT-SERVERS.NET.
.           518400  IN  NS  G.ROOT-SERVERS.NET.
.           518400  IN  NS  H.ROOT-SERVERS.NET.
.           518400  IN  NS  I.ROOT-SERVERS.NET.
.           518400  IN  NS  J.ROOT-SERVERS.NET.
.           518400  IN  NS  K.ROOT-SERVERS.NET.
.           518400  IN  NS  L.ROOT-SERVERS.NET.
.           518400  IN  NS  M.ROOT-SERVERS.NET.
.           518400  IN  NS  A.ROOT-SERVERS.NET.
.           518400  IN  NS  B.ROOT-SERVERS.NET.
.           518400  IN  NS  C.ROOT-SERVERS.NET.
;; Received 496 bytes from in 8 ms

com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
;; Received 492 bytes from in 100 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
;; Received 168 bytes from in 99 ms

www.google.com.     300 IN  A
;; Received 48 bytes from in 13 ms

Here are some good DNS resources for any of you that need a refresh. Certainly got my DNS refresh for the year :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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