Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

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

share|improve this question
1  
Damn I am confused! You must be too. One other ting I like to do is a dig with +trace. I am not sure that it will help much except that I trust this more than most. Have there been any changes of late? Otherwise I have to think on this for a while. Noting is coming to mind just yet. Great question BTW. Up voting now. –  closetnoc Apr 23 at 3:01
    
@closetnoc Well I am glad it's not just me! I'll try the dig +trace now and edit the Q with the results. Nothing's been changed on this in years (it was all set up before I started here) so apparently it's been working like this, but before we do make changes I want to be sure of why it is working so I can revert if needed. –  Chris O'Kelly Apr 23 at 3:33
1  
Gotcha! Sounds like it was rigged but works anyway. It is probably best to clean it up at some point. I am a semi-retired IT consultant and one way to CYA is to CYA! So it is a good idea to make sure you can revert just in case. –  closetnoc Apr 23 at 3:43
1  
Looks like your hosting company is the authority. I should have told to add any at the end of the dig command. My apologies! These are the hazards of getting old... I would repeat the dig command with any and look for SOA to be sure. It may be that your registrar is not the authority which may mean that you can edit the ns entries and point them to use your hosting companies ns servers. –  closetnoc Apr 23 at 3:49
    
@closetnoc Looks like you're right, it is the hosting company that is both the authority and the primary NS (security.bitcloud is mentioned but I am guessing that's the server the hosting company, in turn, uses). Confusingly the nameserver entries on the registrar already point at the hosting company, so I am not sure where those nslookup results were coming from (though they were marked non-authorative). I suppose I will just document it as a possible source of trouble and if we have issues after the change we'll update the entries on RegCo too... –  Chris O'Kelly Apr 23 at 4:02

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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