What does it mean when the nameservers reported by whois do not match those reported by nslookup?

Question

I am currently investigating moving some records to a new set of nameservers, and in doing the research to be prepared for it have come up against a confusing mismatch. A bit of background on the situation -

• it's a .com.au domain, if that is of note (don't think it is).
• There are several parties involved here - the webhosting company, who I originally had the impression was providing the nameservers; the registrar, who I am starting to think might actually be the ones providing them; and the company I work for, which has an internal DNS server which overrides one of the records (again, I don't think this should matter, I am making my whois/nslookup queries using online tools outside our network to try to ensure this doesn't complicate things).
• To keep the question general, lets call these parties and their nameservers HostCo, RegCo and OurCo, and call the domain in question *.ourco.example.

Here are the two conflicting results I am seeing (some obfuscation):

Whois response for ourco.example:


Domain Name ourco.example
Last Modified   12-Apr-2014 11:39:38 UTC
Registrar ID    RegCo
Registrar Name  RegCo
Status  ok
Registrant  OURCO PTY LTD
Registrant ID   ACN ### ### ###
Eligibility Type    Company
Registrant Contact ID   JB#######
Registrant Contact Name Joe Bloggs
Registrant Contact Email    [email protected]
Tech Contact ID CO2415740
Tech Contact Name   Chris O\'Kelly
Tech Contact Email  [email protected]
Name Server ns1.hostco.example
Name Server IP  ###.###.###.###
Name Server ns2.hostco.example
Name Server IP  ###.###.###.###

which suggests HostCo hosts the nameservers, and

>nslookup - 8.8.8.8
Default Server:  google-public-dns-a.google.com
Address:  8.8.8.8

> set querytype=soa
> ourco.example
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
ourco.example
        primary name server = ns1.regco.example
        responsible mail addr = hostmaster.ourco.example
        serial  = 20030501
        refresh = 10800 (3 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 10800 (3 hours)

which suggests RegCo hosts them.

I've done some further investigation; reading this question led me to a DNS propogation tool designed by David Precious. This tool returns the RegCo nameservers and advises "All responding servers agreed on the same answer".

Furthermore, I tried to nslookup the domain on HostCo's nameservers, like so:

>nslookup ourco.example ns1.hostco.example

(root)  nameserver = L.ROOT-SERVERS.NET
(root)  nameserver = M.ROOT-SERVERS.NET
(root)  nameserver = A.ROOT-SERVERS.NET
(root)  nameserver = B.ROOT-SERVERS.NET
(root)  nameserver = C.ROOT-SERVERS.NET
(root)  nameserver = D.ROOT-SERVERS.NET
(root)  nameserver = E.ROOT-SERVERS.NET
(root)  nameserver = F.ROOT-SERVERS.NET
(root)  nameserver = G.ROOT-SERVERS.NET
(root)  nameserver = H.ROOT-SERVERS.NET
(root)  nameserver = I.ROOT-SERVERS.NET
(root)  nameserver = J.ROOT-SERVERS.NET
(root)  nameserver = K.ROOT-SERVERS.NET
Server:  UnKnown
Address:  ###.###.###.###

Name:    ourco.example 
Address:  ###.###.###.###

Which suggests that HostCo just points back to the root internet nameservers for that address... I think.

Finally, when I log onto RegCo's domain management tools, it lists ns1.hostco.example and ns2.hostco.example as the nameservers for the domain in both the "Domain Info" section and the section wherein I set nameservers. In the "Update DNS Details" section I have the details for all the hosts, with appropriate MX, CNAME and A records to what I expect.

My theory is that the information on RegCo's nameserver section was entered incorrectly and that causes the domain info and whois to be wrong too; if so then the settings in the "Update DNS Details" are what is being used and I can safely say the current nameserver is with RegCo. The only flaw I see with this theory is that if it were true, wouldn't it be incorrectly pointing DNS requests to HostCo, and wouldn't that mean things shouldn't be working (they are)?

Can anyone confirm or deny my theory?

Edit the first

In case this was not yet confusing enough, here's the results of a dig +trace suggested by closetnoc:

dig @8.8.8.8 ourco.example +trace any

; <<>> DiG 9.7.0-P1 <<>> @8.8.8.8 ourco.example +trace any
; (1 server found)
;; global options: +cmd
.                       6055    IN      NS      f.root-servers.net.
.                       6055    IN      NS      j.root-servers.net.
.                       6055    IN      NS      a.root-servers.net.
.                       6055    IN      NS      c.root-servers.net.
.                       6055    IN      NS      m.root-servers.net.
.                       6055    IN      NS      k.root-servers.net.
.                       6055    IN      NS      g.root-servers.net.
.                       6055    IN      NS      b.root-servers.net.
.                       6055    IN      NS      h.root-servers.net.
.                       6055    IN      NS      d.root-servers.net.
.                       6055    IN      NS      i.root-servers.net.
.                       6055    IN      NS      l.root-servers.net.
.                       6055    IN      NS      e.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 172 ms

au.                     172800  IN      NS      a.au.
au.                     172800  IN      NS      b.au.
au.                     172800  IN      NS      r.au.
au.                     172800  IN      NS      s.au.
au.                     172800  IN      NS      u.au.
au.                     172800  IN      NS      v.au.
au.                     172800  IN      NS      w.au.
au.                     172800  IN      NS      x.au.
au.                     172800  IN      NS      y.au.
au.                     172800  IN      NS      z.au.
;; Received 493 bytes from 199.7.83.42#53(l.root-servers.net) in 993 ms

com.au.                 86400   IN      NS      z.au.
com.au.                 86400   IN      NS      w.au.
com.au.                 86400   IN      NS      y.au.
com.au.                 86400   IN      NS      x.au.
;; Received 273 bytes from 202.12.31.141#53(v.au) in 1038 ms

ourco.example.        14400   IN      NS      ns2.hostco.example.
ourco.example.        14400   IN      NS      ns1.hostco.example.
;; Received 111 bytes from 37.209.194.5#53(x.au) in 998 ms

ourco.example.        14400   IN      TXT     "v=spf1 +a +mx +ip4:###.###.###.### ?all"
ourco.example.        14400   IN      MX      0 mail.ourco.example.
ourco.example.        86400   IN      SOA     ns1.hostco.example. security.bitcloud.com.au. 2013051700 86400 7200 3600000 86400
ourco.example.        86400   IN      NS      ns2.hostco.example.
ourco.example.        86400   IN      NS      ns1.hostco.example.
ourco.example.        14400   IN      A       ###.###.###.###
;; Received 236 bytes from ###.###.###.####53(ns1.hostco.example) in 158 ms

which undermines my theory that the registrar holds the nameservers

Answer 1

Your situation is an odd one and your question more than intriguing. I imagine that this question can be helpful because this would be a really confusing situation to anyone. I do this everyday and it eluded me even though there were hints right in the question that were easy to overlook.

When you use nslookup or whois, it is possible that the data returned is a non-authoritative answer which means that it it is not the gold-standard. Normally you want an authoritative answer but whether any answer is authoritative or non-authoritative is not always clear. The whois result was correct and the nslookup was non-authoritative. But how are you to really know what is going on without guessing? What if you want to be dead sure?

I use dig +trace mydomainname.com any to know for sure. This command does a trace from the root name servers through to the domain name authority for your site. In this way, you can know what entries are correct. You can look for a SOA (statement of authority) records, A records, NS records, MX records, and so forth to know which set of DNS entries are the ones that are authoritative.

In this case, your host company is the authority and the records at the registrar are incorrect. You will have to log onto you registrar's control panel and check to make sure that the entries are corrected. In this case, any A record is likely incorrect and should be deleted to be safe. As well, you can change the name servers to be the domain name servers for your host. If there is an MX record, you can remove it, but I would make sure it exists within your host DNS control panel first or very shortly after.

It appeared that the registrars DNS entries was confusing the issue. It is possible that this data could interrupt service for a user. Correcting and/or removing these DNS entries should clear up any issues and may solve problems that you are unaware of.

Answer 2

On the basis of the data shown here:

The start-of-authority record, in a name server at the registrar (RegCo), points to a name server at the registrar.

The name server at the registrar has NS records for the domain.

The NS records point to HostCo.

At HostCo there are name servers, which you can use to supply A records etc.

That is not an error. That's how the system is supposed to work.

Note that the SOA does not point to your name servers. How could it? The SOA would send you to find your domain, which would send it to the SOA for your domain, which would send it to the SOA for your domain, which would send it to the SOA for your domain, which would ....

In theory the SOA could list a name server on some other domain, which was properly registered with some other registrar. My registry doesn't allow me to do that, because (1) That would be pretty unusual. (2) Why would I do that? And (3) Most small users (like you and me) would just mess it up.

What about moving the SOA record off the name server at the registry? Yes, you can do that. You can move it to a different registry.

Technically you don't need a registry (the organization that /registers/ your domain name) to host your SOA record: you just have to find some other way to /register/ your SOA record. But let's not get ahead of ourselves.

If you want to manage subdomains, you can put SOA records on your own name servers. It requires some more A records at the domain level, because the mechanism for subdomains uses DNS glue records instead of zone transfers.

Answer 3

It is very difficult to do any kind of useful troubleshooting, specially after the fact, without the real names involved (and so much bad obfuscation that honestly renders the question very hard to read to me). So I am answering it here and now with generic information that can help similar other cases.

No matter the case, the following hold true:

• first, the very big problem is that you are not showing exactly how you get this whois data; which whois server do you consult? Are you sure to contact the registry whois server and not any third party one? You can find the relevant registry whois server by consulting the IANA database: https://www.iana.org/domains/root/db/au.html ; all other whois output is irrelevant, including registrar one; there are lots of website pretending to do whois display, but the main problem is not knowing how they get the data themselves, and sometimes there are caches (that is still the best outcome, worst outcome can be your search being monitored which have various bad consequences)

• not really changing anything per se, but there is a need to advocate it, so let me say it: nowadays, in general, prefer RDAP over whois, where it exists, just because the format is better.

• for DNS data, the whois content is irrelevant; whois plays no operational role in any DNS operations, registries could switch off all whois servers, and nothing will happen for DNS. So what is in the DNS is what is relevant/authoritative for all DNS operations, you can just ignore what whois says

• whois updates are not necessarily real time: if you change nameservers they can change at the DNS side quicker than on whois side, even if both cases are handled by the registry, out of some database they manage, so their two subsystems could be synchronized, but in practice there is no guarantee (and no need) to have that feature; I would use a ballpark of 24 hours because that is what was in some previous ICANN contracts, in the sense that if a change you did does not appear in registry whois server output more than 24 hours after the fact, then it may be time to investigate more deeply, but before that delay I wouldn't even bother

• "the webhosting company, who I originally had the impression was providing the nameservers; the registrar, who I am starting to think might actually be the ones providing them;": this is troublesome, because there shouldn't be any uncertainty here, things are clear and easy to determine. But I think first it is important to understand/remember:

  • domain name registrar, DNS provider, webhosting, (and email hosting if you want to throw that into the mix), are 3 (or 4) completely different jobs, with different constraints and consequences
  • yes, a single company can do everything, which has both good and bad consequences, so it is a choice to make or not depending on each one specific constraints; the following points consider each job to be run by a separate company
  • the domain name registrar plays NO ROLE in day to day DNS resolution of a domain; you go to the domain name registrar to specify which nameservers are going to server your domain, you can go there to update them as needed, the registrar is just sending that data to the registry, and the registry authoritative nameservers publish NS records in their zonefile pointing to the designated nameservers; the domain name registrar is just relaying information, not playing into part of it
  • the DNS provider says which nameservers to use for a given domain name, and makes sure that DNS queries get replied correctly; the content of the zone (list of records) can be changed at the DNS provider side, through its designated API or UI, and this does not involve the registrar in any way
  • the webhosting company has basically its IP addresses in the zonefile for the domain, to make sure web traffic does hit its servers; if it has to change its IP addresses for some reasons, it may need to ask for a change in the zone (or not, depending how things are setup, for example CNAME allow some kind of indirection, at least for the www name); but other than that, like changes in the content of the website does not involve either the DNS provider or the registrar

• I would suggest, in any case like that, to first make really crystal clear on who is providing each of the services above: who is the registrar? who is the DNS provider? who is the webhosting company? Not who you think it is, or was in the past, but who it is now, based on actual queries:

  • a whois search on the registry whois server (port 43 or web) should show in reply (except in rare cases) who is the registrar for the given domain name
  • querying the registry authoritative nameservers for the domain will show who is DNS provider by looking at the NS record (not necessarily always easy to find out the company name just by looking at the nameservers hostnames, but at least that is the correct path)
  • querying the authoritative nameservers for like A/AAAA records on www name should show you the IP address of the web hosting company webservers, out of which you should be able to find the hosting company (by searching or doing another whois query, this time not at the domain registry, but at what is called a RIR, the organization that distributes the IP addresses, it can show who "owns" a given IP address)

• when you troubleshoot DNS related problems, dig is the appropriate tool (far superior than nslookup) BUT you need to make sure to first query the authoritative nameservers, using @ option, to assess what is happening, before even looking at recursive nameservers. dig +trace can indeed help to show the full resolution path, and then you can extract from its output the specific authoritative nameservers and redo the queries yourself.