Discrepancy in NS information between dig and whois

Question

I'm having problem trying to understand how Whois protocol works, in particular, the section related to the Name server information.

For example

dig +short NS adtogroups.com

Returns nothing, which is expected since there is a ClientHold on the domain which prevent it from resolving

Whois adtogroups.com
... Showing part of the output: Domain Status: clientHold https://icann.org/epp#clientHold

However, the name server section of whois answer returns a set of servers. I know that dig is the reliable source for resolving any domain since it's built on sending DNS queries, while the name server information in whois is mirrored somehow from another source.

My question is, from where did whois get the name server information in the above example, knowing that the domain is under ClientHold (i.e. the DNS will not respond to resolving requests) and none of the NS output by whois appeared in passive DNS ?

I think I'm missing something on how Whois fetch the information related to NS.

Answer 1

Whois gets it's data from a registry that serves a particular TLD (or a particular domain within the TLD if there's no single registry).

It is the registry that holds all the information for the domain submitted by an owner, including it's NS RRs and hints, as well as contacts, status, etc.

Zone data for the TLD is generated from the registry contents, and if there's a hold the domain in question would not be exported to the zone.

Answer 2

Your proofs are not the correct ones to really say you have this discrepancy problem, even if you do have it in fact. Why? Because your dig query asks your local/default recursive nameserver and not the authoritative ones, at the registry level. This would need to be redone if you want to prove your point… except that we already know your point is valid.

whois and dig (if you query the authoritative nameservers) come from the exact same source: the registry. They serve however two different needs: like its name implies, whois shows how the domain name is registered at the registry or if it is free; where dig shows how a domain will resolve on the internet.

whois is a very simple protocol, the client just opens a socket on port 43 to the destination, sending the domain name on a line, and getting back a block of text and a closed connection. What it gets back is what the registry decides to send.

There are multiple cases where a domain name can be registered but will not resolve:

1. its owner may decide not to specify any NS record, hence the domain name does not resolve
2. or right after registration, immediately after it, the domain name may not already be loaded in the registry authoritative nameservers (some are realtime or close to it, some are slower)
3. bugs and errors do happen too
4. but in your case if you query by whois for your domain, you will see:

Status: clientHold https://icann.org/epp#clientHold

You can go have a look at this URL that should explain the situation for you. In short, having clientHold or serverHold means that, for various reasons again, while the domain name is registered and exists in the registry database, it will not be resolving.

And in your very specific case, based on the nameservers used by your domain, I think you are in a case where you will need to contact the registrar.

Also some whois clients have a fixed list of whois server to query based on the query itself (which you also be other things than a domain name in fact), others will use whois.nic.$TLD which works often but not always (you can see at IANA website a page for each TLD in which the whois server has to be displayed).

Also note that in the future, RDAP should replace whois (or at least start to coexist), and may make the bootstrapping problem easier. In gTLDs, the rare remanining thin registries (but the bigger ones) are to be converted to thick registries "soon".