360

How can I find the origins of conflicting DNS records?

alexyorke
  • 4,224
  • 3
  • 34
  • 55
Binarytales
  • 9,468
  • 9
  • 32
  • 38

12 Answers12

463

You'll want the SOA (Start of Authority) record for a given domain name, and this is how you accomplish it using the universally available nslookup command line tool:

command line> nslookup
> set querytype=soa
> stackoverflow.com
Server:         217.30.180.230
Address:        217.30.180.230#53

Non-authoritative answer:
stackoverflow.com
        origin = ns51.domaincontrol.com # ("primary name server" on Windows)
        mail addr = dns.jomax.net       # ("responsible mail addr" on Windows)
        serial = 2008041300
        refresh = 28800
        retry = 7200
        expire = 604800
        minimum = 86400
Authoritative answers can be found from:
stackoverflow.com       nameserver = ns52.domaincontrol.com.
stackoverflow.com       nameserver = ns51.domaincontrol.com.

The origin (or primary name server on Windows) line tells you that ns51.domaincontrol is the main name server for stackoverflow.com.

At the end of output all authoritative servers, including backup servers for the given domain, are listed.

Antti Kissaniemi
  • 18,944
  • 13
  • 54
  • 47
  • 187
    nslookup -type=soa stackoverflow.com – Ben Amada Nov 14 '12 at 03:13
  • From all the tools surveyed below, nslookup is the only tool which is also available on the MS-Windows command-line. The method above works great on Windows 7 as well. – Druvision Mar 29 '13 at 07:37
  • 8
    Under windows however, I'm unable to see the "Authoritative answers" response. I have Windows 8 and Ubuntu 12 side by side and then same command for the same domain works on Ubuntu properly but not on Windows. – Mario Awad Dec 10 '13 at 18:22
  • 3
    beware that this shows doesn't necessarily show recent changes to DNS configs, however using `dig` seemed to, for me (see answer below) – rogerdpack May 29 '14 at 06:33
  • 1
    And now their name servers are from Google: `ns-cloud-e1.googledomains.com` – Dorian Mar 05 '17 at 00:41
  • 7
    What does it mean if there is no authoritative answer but the non-authoritative answer is fine ? – Overmind Jul 05 '17 at 09:31
  • 11
    If you run `nslookup -type=soa stackoverflow.com` on linux today (2019-Feb), the authoritative section is empty. – simpleuser Feb 27 '19 at 19:45
  • 2
    Indeed, it doesn't work any more. Authoritative answers in empty. – user1768761 Jan 24 '20 at 10:14
  • 1
    `nslookup -type=soa pool.ntp.org` gives no authoritative name servers, but https://www.nslookup.io/domains/pool.ntp.org/dns-records/#authoritative does. How come? – igor Apr 11 '23 at 14:41
190

You used the singular in your question but there are typically several authoritative name servers, the RFC 1034 recommends at least two.

Unless you mean "primary name server" and not "authoritative name server". The secondary name servers are authoritative.

To find out the name servers of a domain on Unix:

  % dig +short NS stackoverflow.com
 ns52.domaincontrol.com.
 ns51.domaincontrol.com.

To find out the server listed as primary (the notion of "primary" is quite fuzzy these days and typically has no good answer):

% dig +short  SOA stackoverflow.com | cut -d' ' -f1
ns51.domaincontrol.com.

To check discrepencies between name servers, my preference goes to the old check_soa tool, described in Liu & Albitz "DNS & BIND" book (O'Reilly editor). The source code is available in http://examples.oreilly.com/dns5/

% check_soa stackoverflow.com
ns51.domaincontrol.com has serial number 2008041300
ns52.domaincontrol.com has serial number 2008041300

Here, the two authoritative name servers have the same serial number. Good.

bortzmeyer
  • 34,164
  • 12
  • 67
  • 91
  • 6
    dig +short does not always give the answer I expect. For instance, a site defined as `www.pressero.com`, which is a CNAME for another site -- dig +short SOA just returns the CNAME target. – Ross Presser Jan 14 '15 at 17:10
  • How do you make a NS authoritative ? – Overmind Jul 05 '17 at 09:32
  • 2
    @Overmind you do not make a NS "authoritative". If a nameserver is configured as authoritative for some domains, it means it has locally zonefiles (typically flat textual files, but could be done differently too) for these domains and it responds to query for them. To be useful, they need to be listed as NS records in the parent zone for each of the domain they are authoritative for, otherwise noone would query them by default. – Patrick Mevzek Mar 05 '18 at 23:27
  • @RossPresser the answer was speaking about NS/SOA records and I doubt that you do that for `www.pressero.com`, you were probably thinking about A records (which is the default record type in `dig` if you do not specify it). But if needed, just add a `tail -1` to retrieve the final result. – Patrick Mevzek Mar 05 '18 at 23:29
  • @PatrickMevzek As I stated in my comment, I used `dig +short SOA www.pressero.com`. This returns only the CNAME target -- not the SOA record for the `pressero.com` domain, which is what I expected. `tail -1` does not help matters; `dig +short SOA` is only emitting one line. – Ross Presser Mar 06 '18 at 23:44
  • 1
    @RossPresser if you search the `SOA` of `pressero.com` you do `dig SOA pressero.com` (with or without +short, it gives you the correct result) not `dig SOA www.pressero.com` (which has a different result because there is a CNAME, dig is a DNS troubleshooting tool, not a full recursive nameserver for you) – Patrick Mevzek Mar 07 '18 at 00:14
  • @PatrickMevzek Thanks for clarification. I have an authoritative server with its own local zone files that works fine. I added a secondary one to prevent downtime in case of failure, however for it I get a warning saying 'Local NS list does not match Parent NS list Server-IP was reported locally, but not by the parent'. What does this exactly mean ? – Overmind Mar 12 '18 at 18:09
  • First, the "secondary" is not used when the primary fails, they are both always used, so 50% of requests each (statistically) but of course the resolvers will fallback to the one working if one is not (just delaying the answer). As for your question (but you should post a new question not using comments :-)), it just means that you also need to give your registrar the new NS list so that it gets added to the registry (parent) zone. You can use online troubleshooting tools like https://dnsviz.net/ or https://zonemaster.net/ (last one may be simpler to start). – Patrick Mevzek Mar 12 '18 at 18:32
44

On *nix:

$ dig -t ns <domain name>
Daniel Böhmer
  • 14,463
  • 5
  • 36
  • 46
aryeh
  • 2,195
  • 1
  • 16
  • 23
22

You could find out the nameservers for a domain with the "host" command:

[davidp@supernova:~]$ host -t ns stackoverflow.com
stackoverflow.com name server ns51.domaincontrol.com.
stackoverflow.com name server ns52.domaincontrol.com.
Vani Gupta
  • 505
  • 6
  • 13
David Precious
  • 6,544
  • 1
  • 24
  • 31
14

I found that the best way it to add always the +trace option:

dig SOA +trace stackoverflow.com

It works also with recursive CNAME hosted in different provider. +trace trace imply +norecurse so the result is just for the domain you specify.

Dorian
  • 22,759
  • 8
  • 120
  • 116
Zioalex
  • 3,441
  • 2
  • 33
  • 30
  • 1
    Note if you are running a local NS server like dnsmasq +trace will not return anything... – Daniel Sokolowski Jan 02 '19 at 01:47
  • 1
    This command provides 53 lines, 3652 bytes of output, much of which is random values. How should someone interpret the output to determine what the authoritative name server is? – theferrit32 Apr 15 '19 at 21:01
  • 1
    I read it from bottom to top. The SOA record is what you search for. You can grep for SOA to have less data. – Zioalex Apr 16 '19 at 12:22
7

We've built a dns lookup tool that gives you the domain's authoritative nameservers and its common dns records in one request.

Example: https://www.misk.com/tools/#dns/stackoverflow.com

Our tool finds the authoritative nameservers by performing a realtime (uncached) dns lookup at the root nameservers and then following the nameserver referrals until we reach the authoritative nameservers. This is the same logic that dns resolvers use to obtain authoritative answers. A random authoritative nameserver is selected (and identified) on each query allowing you to find conflicting dns records by performing multiple requests.

You can also view the nameserver delegation path by clicking on "Authoritative Nameservers" at the bottom of the dns lookup results from the example above.

Example: https://www.misk.com/tools/#dns/stackoverflow.com@f.root-servers.net

Nitin Agarwal
  • 3,830
  • 1
  • 21
  • 12
7

The term you should be googling is "authoritative," not "definitive".

On Linux or Mac you can use the commands whois, dig, host, nslookup or several others. nslookup might also work on Windows.

An example:

$ whois stackoverflow.com
[...]
   Domain servers in listed order:
      NS51.DOMAINCONTROL.COM
      NS52.DOMAINCONTROL.COM

As for the extra credit: Yes, it is possible.

aryeh is definitely wrong, as his suggestion usually will only give you the IP address for the hostname. If you use dig, you have to look for NS records, like so:

dig ns stackoverflow.com

Keep in mind that this may ask your local DNS server and thus may give wrong or out-of-date answers that it has in its cache.

  • 6
    These commands are **not** equivalent. Nothing says that the information given by whois is up to date. Frequently, it is not because people update the NS records in the zone file without notifying the registry or the registrar. – bortzmeyer Dec 24 '08 at 07:51
  • I never said they were ;) You can change the NS records in your zone all you want, as long as the parent zone is not updated, nothing will change. And an update of the parent zone usually goes hand in hand with an update of the whois data (at least with my providers). –  Dec 25 '08 at 13:09
3

I have found that for some domains, the above answers do not work. The quickest way I have found is to first check for an NS record. If that doesn't exist, check for an SOA record. If that doesn't exist, recursively resolve the name using dig and take the last NS record returned. An example that fits this is analyticsdcs.ccs.mcafee.com.

  1. Check for an NS record

host -t NS analyticsdcs.ccs.mcafee.com.

  1. If no NS found, check for an SOA record

host -t SOA analyticsdcs.ccs.mcafee.com.

  1. If neither NS or SOA, do full recursive and take the last NS returned

dig +trace analyticsdcs.ccs.mcafee.com. | grep -w 'IN[[:space:]]*NS' | tail -1

  1. Test that the name server returned works

host analyticsdcs.ccs.mcafee.com. gtm2.mcafee.com.

dannyw
  • 285
  • 3
  • 5
2

You can use the whois service. On a UNIX like operating system you would execute the following command. Alternatively you can do it on the web at http://www.internic.net/whois.html.

whois stackoverflow.com

You would get the following response.

...text removed here...

Domain servers in listed order: NS51.DOMAINCONTROL.COM NS52.DOMAINCONTROL.COM

You can use nslookup or dig to find out more information about records for a given domain. This might help you resolve the conflicts you have described.

Chris de Vries
  • 56,777
  • 5
  • 32
  • 27
  • 2
    Nothing says that the information given by whois is up to date. Frequently, it is not because people update the NS records in the zone file without notifying the registry or the registrar. – bortzmeyer Dec 24 '08 at 07:48
  • While not a direct answer to the question, "whois" is useful because it tells you who are supposed to be the name servers for somewhere (even if for whatever reason they currently aren't). – SomeoneElse Apr 20 '20 at 12:47
1

An easy way is to use an online domain tool. My favorite is Domain Tools (formerly whois.sc). I'm not sure if they can resolve conflicting DNS records though. As an example, the DNS servers for stackoverflow.com are

  NS51.DOMAINCONTROL.COM
  NS52.DOMAINCONTROL.COM
Kyle Cronin
  • 77,653
  • 43
  • 148
  • 164
1

SOA records are present on all servers further up the hierarchy, over which the domain owner has NO control, and they all in effect point to the one authoritative name server under control of the domain owner.

The SOA record on the authoritative server itself is, on the other hand, not strictly needed for resolving that domain, and can contain bogus info (or hidden primary, or otherwise restricted servers) and should not be relied on to determine the authoritative name server for a given domain.

You need to query the server that is authoritative for the top level domain to obtain reliable SOA information for a given child domain.

(The information about which server is authoritative for which TLD can be queried from the root name servers).

When you have reliable information about the SOA from the TLD authoritative server, you can then query the primary name server itself authoritative (the one thats in the SOA record on the gTLD nameserver!) for any other NS records, and then proceed with checking all those name servers you've got from querying the NS records, to see if there is any inconsistency for any other particular record, on any of those servers.

This all works much better/reliable with linux and dig than with nslookup/windows.

Dennis
  • 51
  • 1
0

Unfortunately, most of these tools only return the NS record as provided by the actual name server itself. To be more accurate in determining which name servers are actually responsible for a domain, you'd have to either use "whois" and check the domains listed there OR use "dig [domain] NS @[root name server]" and run that recursively until you get the name server listings...

I wish there were a simple command line that you could run to get THAT result dependably and in a consistent format, not just the result that is given from the name server itself. The purpose of this for me is to be able to query about 330 domain names that I manage so I can determine exactly which name server each domain is pointing to (as per their registrar settings).

Anyone know of a command using "dig" or "host" or something else on *nix?

  • 3
    Simple. Let's assume the domain is example.org. First, you need to find the name servers of ".org" with 'dig +short NS org.'. Then you query one of them (anyone, they are all authoritative). Let's choose d0.org.afilias-nst.org. You query with 'dig @d0.org.afilias-nst.org NS example.org.'. – bortzmeyer Feb 12 '09 at 07:56
  • The fact that the resolver returns, by default, the name servers listed by the domain itself is a good thing. That's the authoritative information. The delegation in the parent zone is NOT authoritative. – bortzmeyer Feb 12 '09 at 07:56
  • And the pointer to whois is a red herring. The whois name server information is often stale. The authoritative resource is the DNS. – tripleee May 03 '16 at 03:40
  • 1
    Whois is completely arbitrary. The value you see in whois listing has no technical ties to DNS. It's often outdated or out right wrong. I'd go so far as to say whois data should almost never be trusted. There are 'thin' and 'thick' registries. The two well known thick registries are the .com and .net registries. These registries contain all the DNS data and serve whois responses can likely be trusted. Almost other other registries are 'thing' and run their own whois registries. This data is frequently wrong. – Mark Sep 03 '16 at 22:56