Mobile app version of vmapp.org
Login or Join
Hamaas447

: What does it mean when the nameservers reported by whois do not match those reported by nslookup? I am currently investigating moving some records to a new set of nameservers, and in doing

@Hamaas447

Posted in: #Dns #Nameserver #Whois

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.com.au.


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

Whois response for ourco.com.au:


Domain Name ourco.com.au
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 joe.bloggs@ourco.com.au
Tech Contact ID CO2415740
Tech Contact Name Chris O'Kelly
Tech Contact Email chris.okelly@ourco.com.au
Name Server ns1.hostco.com.au
Name Server IP ###.###.###.###
Name Server ns2.hostco.com.au
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.com.au
Server: google-public-dns-a.google.com
Address: 8.8.8.8

Non-authoritative answer:
ourco.com.au
primary name server = ns1.regco.com.au
responsible mail addr = hostmaster.ourco.com.au
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.com.au ns1.hostco.com.au

(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.com.au
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.com.au and ns2.hostco.com.au 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, heres the results of a dig +trace suggested by closetnoc :

dig @8 .8.8.8 ourco.com.au +trace any

; <<>> DiG 9.7.0-P1 <<>> @8 .8.8.8 ourco.com.au +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.com.au. 14400 IN NS ns2.hostco.com.au.
ourco.com.au. 14400 IN NS ns1.hostco.com.au.
;; Received 111 bytes from 37.209.194.5#53(x.au) in 998 ms

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


which undermines my theory that the registrar holds the nameservers

10.01% popularity Vote Up Vote Down


Login to follow query

More posts by @Hamaas447

1 Comments

Sorted by latest first Latest Oldest Best

 

@Sherry384

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.

10% popularity Vote Up Vote Down


Back to top | Use Dark Theme