I have to change the MX DNS records for our company domain name and I've come across this odd situation:

A whois search shows up that the nameservers for ourcompany.com are ns1.ourcompany.com and ns2.ourcompany.com.

In the DNS settings at the registrar there are no A/Cname records at all. However the nameservers are defined in the DNS settings for the domain on our dedicated server. (Registrar and host are two different companies).

Using the DNS lookup on http://www.mxtoolbox.com/ shows that ns2.ourcompany.com is reporting the correct IP for our dedicated server.

Its all very odd... the DNS on the dedicated server doesn't seem to have much effect, but its odd that the dns at the registrar's end doesn't have any records.

thanks for your help.

3 Answers 3


I wouldn't use whois explicitly to determine operations about DNS because it's not really used when DNS is concerned (although some registrars put the settings for name server delegation information there) ... Instead I would grab the BIND tools for your platform, and follow along.

As this is easier to explain using real domain names, let's resolve the host ip for for my domain huggard.info.

All DNS in the world is actually rooted in the '.' domain. Technically every DNS query starts at the 13 servers, named {a-m}.root-servers.net. (In the real world caching and prior knowledge help eliminate these steps, but for sake of our example, we're assuming we only know how to get to one of these root servers). So we try to ask there but get no answer (1), instead these servers say, your question is part of the 'info.' zone, it's name servers are over there. So we ask those servers over there, Hey what is the ip of huggard.info? And again they say I dunno,(2) but it should be part of the 'huggard.info.' zone, you want to talk to other name servers over the hill yonder. Finally we ask the 3rd set of name servers, what's the ip of huggard.info and they say "I totally know that! It's currently these IP addresses!" (3).

But wait! a0.info.afilias-nst.info is obviously part of the 'info.' zone... and ns1.huggard.info is obviously part of the 'huggard.info.' zone... How the heck did that work? The answer are magical glue records!

Somewhere in your registrar's tools, when your domain was set to these nameservers, provided A records that were given up the chain to your company's parent zone. (In my case Dreamhost put 4 A records into the info zone for me along with my normal NS delegation records. Their tooling actually hides this functionality in their whois update utility, and display it only after they detect that I'm using nameservers from within my zone when I'm updating the same).

Commands to follow along are below! norecurse tells dig to only use information from that name server and not attempt to resolve further. Pay attention to the authority and additional sections when trying for yourself with your domain or mine.

Hope this helps explain what is going on and why changing the NS records on your server doesn't do too much :)

1. dig +norecurse @a.root-servers.net A huggard.info
2. dig +norecurse @a0.info.afilias-nst.info. A huggard.info
3. dig +norecurse @ns1.huggard.info. A huggard.info
  • I used A as it's the most basic record... but to relate to your question, if you want to look at my mail exchangers change A for MX in the 3 queries and you'll see the same dance.
    – Charlie
    Commented Aug 2, 2012 at 1:31
  • Phew that was a lot of information. Thanks for all of that. I think I understand a bit more! It is all very complicated. So essentially if I want to set MX servers and A records I need to get these off my host and update at my registrar's DNS settings, rather than using my name servers. Commented Aug 2, 2012 at 9:50
  • At the minimum, your registrar must push NS records for your domain to your domain's parent. However when you have the case that your NS records point to hosts within your domain (e.g. ns1.huggard.info is part of huggard.info), your registrar also pushes A records for the associated NS entries. Other records (MX, all A records) are then updated/published in the zone file on your DNS servers. (i.e. on the servers pointed to by NS (and optionally A/AAAA) records from the parent zone (e.g. ns{1-4}.huggard.info)).
    – Charlie
    Commented Aug 2, 2012 at 14:42
  • I think I understand. My registrar is controlling the A records for NS1.domain.com (which point to the ip addresses of my server). Therefore when I set domain.com's nameservers to NS1.domain.com the route taken goes to NS1.domain.com which is reported as being my hosting's IP by my registrar. Phew, I didn't think it would be this complicated! Thanks for your help. Commented Aug 2, 2012 at 15:30
  • 1
    @Lèsemajesté - Thanks! It's true that nslookup comes with Windows while dig does not. But it should also be noted that the ISC, who maintains both tools, deprecated nslookup in favor of dig with BIND 9.5 (circa 2008) if not before that release. I'd therefore recommend installing and using the latest stable version of BIND tools when possible. (The ISC provides a Windows Binaries for BIND as a download with each version).
    – Charlie
    Commented Dec 26, 2012 at 16:00

If a whois states that your DNS are nsX.yourcompany.com and the IP is the one of your server, it’s normal that you don’t see any addresses listed at your registrar; it means that the DNS is actually your server.

You should check in other section of your interface and see if it is configured somewhere else.


Nameservers can be "registered" with your domain registrar and these are then delegated to in their DNS.

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.