← Back to context

Comment by throwaway150

2 years ago

There's something about WHOIS I've never understood. If you run `whois ycombinator.com` you'll see name servers in the output.

  Name Server: NS-1411.AWSDNS-48.ORG
  Name Server: NS-1914.AWSDNS-47.CO.UK
  Name Server: NS-225.AWSDNS-28.COM
  Name Server: NS-556.AWSDNS-05.NET

But if you run `dig ycombinator.com ANY +noall +answer` you'll see name servers here too.

  ycombinator.com.        21600   IN      NS      ns-556.awsdns-05.net.
  ycombinator.com.        21600   IN      NS      ns-1914.awsdns-47.co.uk.
  ycombinator.com.        21600   IN      NS      ns-225.awsdns-28.com.
  ycombinator.com.        21600   IN      NS      ns-1411.awsdns-48.org.
  ycombinator.com.        900     IN      SOA     ns-225.awsdns-28.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

If you see all the output together, you'll find the same name servers are present in WHOIS output and the DNS NS records. But wait, there's more.

The name server `ns-225.awsdns-28.com` is present three times- in WHOIS, in DNS NS records, in DNS SOA record.

Which of these name servers get used to resolve `ycombinator.com` to its IP address like when I do `ping ycombinator.com`?

What if the information between the WHOIS and DNS NS records and the DNS SOA records are inconsistent? Which record wins?

If you `ping`, your recursive resolve (like Google DNS, or your ISP DNS servers) will do the recursive lookup for you.

WHOIS data are irrelavant to resolving the host IP address. The SOA will be used to find the primary name server (for an AXFR lookup perhaps), but generally, each NS entry will work in a round-robin fashion and SOA isn't queried.

Most resolves just ignore duplicate records, but I imagine some resolvers may change the "odds" to likely pick the duplicated NS entry.

Finally, most authorative resolvers do not want to spend resources on ANY queries and almost always don't return all records, or like you saw, do not de-duplicate answers.

  • Thanks! Do you know why the name servers are part of the WHOIS data?

    Same question for SOA record. If the NS entries are used in a round-robin fashion, why is the name server present in SOA record too?

    • > Do you know why the name servers are part of the WHOIS data?

      The NS returned from the registrar's WHOIS server reflects the registrar's view; the NS returned from the TLD nameservers reflects the registry's view; the NS returned from the zone's authoritative nameservers reflects the registrant's view. These should typically be the same, but can differ.

      > why is the name server present in SOA record too?

      The NS in the SOA record is used for RFC2136 dynamic updates and RFC1996 zone replication.

      1 reply →

    • If you're trying to debug why a website's setup isn't working, the first step is to see if what the registry thinks the nameservers should be matches what the nameservers in DNS actually are. These can fall out of sync if e.g. the registry's connection to its DNS provider is experiencing issues. This does actually happen from time to time.

The NS record wins. The data in WHOIS is just non-operational metadata, WHOIS is not used for lookups.

Which server gets used is usually randomized from the set of possible ones. Same for which of multiple A or AAAA records are used to connect to.

Us sysadmins would love to be able to specify weights or round robin or retries (like with SRV records) to move load balancing and failover to the clientside but for whatever reason browser vendors have rejected this for years.

In practice it will round-robin because all of those guys have the same performance characteristics but through whoever else is upstream of you in the DNS chain. The SOA isn't used for resolution so it doesn't matter there.

  • > In practice it will round-robin

    Which data though? Is it the WHOIS name server data that is used for round-robin? Or the DNS NS record data?

    Do you know why the name server is present in SOA if it isn't used?

    • The NS records and the WHOIS should be the same usually. One comes from the registrar's configs and the other from your next level upstream resolver (which should, unless it's cached and a recent change happened, be the same). But the thing that is used is whatever your next level upstream resolver is, which is the `dig` output unless you did `dig @someoneelse`.

      The SOA nameserver is pretty much only significant for DNSSEC these days. In the AWS case there, I don't think it does anything unique. Pretty much there just to meet the standard.

      2 replies →