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 -
Default Server:  google-public-dns-a.google.com

> set querytype=soa
> ourco.com.au
Server:  google-public-dns-a.google.com

Non-authoritative answer:
        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 @ ourco.com.au +trace any

; <<>> DiG 9.7.0-P1 <<>> @ 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 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 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 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 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

  • 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, 2014 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. Apr 23, 2014 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, 2014 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, 2014 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... Apr 23, 2014 at 4:02

2 Answers 2


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.


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.

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.