Open kchr opened 11 years ago
FYI current non-usable TLDs are .dk and .fi, probably more...
One option is to use "dig" for TLD lookup:
Example 1
$ dig +short CNAME dk.whois-servers.net
whois.dk-hostmaster.dk.
Example 2
$ dig +short _nicname._tcp.dk SRV
0 0 43 whois.dk-hostmaster.dk.
Using "host":
$ host -t SRV _nicname._tcp.dk
_nicname._tcp.dk has SRV record 0 0 43 whois.dk-hostmaster.dk.
Using "nslookup" (should work fine on Windows, will test this):
Example 1
$ nslookup -q=srv _nicname._tcp.dk ~
Server: 192.121.104.129
Address: 192.121.104.129#53
Non-authoritative answer:
_nicname._tcp.dk service = 0 0 43 whois.dk-hostmaster.dk.
Authoritative answers can be found from:
dk nameserver = a.nic.dk.
dk nameserver = l.nic.dk.
dk nameserver = b.nic.dk.
dk nameserver = s.nic.dk.
dk nameserver = p.nic.dk.
dk nameserver = c.nic.dk.
Example 2
$ nslookup -q=cname dk.whois-servers.net ~
Server: 192.121.104.129
Address: 192.121.104.129#53
Non-authoritative answer:
dk.whois-servers.net canonical name = whois.dk-hostmaster.dk.
Authoritative answers can be found from:
whois-servers.net nameserver = udns1.ultradns.net.
whois-servers.net nameserver = udns2.ultradns.net.
udns1.ultradns.net internet address = 204.69.234.1
udns2.ultradns.net internet address = 204.74.101.1
The $DOMAIN_ASSOC and $WHOIS_PARSER are structures that get deprecated/unusable as soon as the WHOIS network changes.
Since it uses the "whois" command for queries, there's no real need for these definitions. Whois will determine what server to use automatically, if none is provided.
However, for this to work we need to programmatically determine what organization is responsible for a particular top domain. The reason for this is that the response templates differ between organizations - which probably is the only definitions needed in beforehand (to parse properly).
It should all be doable through the whois command; I will read the docs and suggest a patch for this.