The article says to not check if the domain you are interesting in resolves, because ISPs sell the data on resolution failures. I have two questions about that.
1. That seems to assume that one is using their ISPs DNS service. What if I'm querying the top level .com servers directly? Is that safe?
2. Even if you are using your ISPs DNS servers, if they are getting that data from their logs and selling it I'd expect there would be a fair delay before the data got to some third party that would act on it. That should make it safe if your intent is to buy the domain soon, shouldn't it?
What do you mean by "querying the top level .com servers directly"? How are you doing that?
Yes, any ISP would likely have a substantial delay in collecting, filtering and selling this type of data, which is why I think DNFR is most likely happening at registrars. I'm just presenting the facts that there are "middlemen" in the process that people should know about. Thanks for helping me clarify.
> What do you mean by "querying the top level .com servers directly"? How are you doing that?
First, ask the root servers for the authoritative servers for the TLD you are interested in:
$ dig @f.root-servers.net www.google.com
[...]
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.google.com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
[...]
com. 172800 IN NS m.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
[...]
m.gtld-servers.net. 172800 IN A 192.55.83.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
[...]
The root servers don't know about google.com, but suggest you ask
[a-m].gtld-servers.net, which are authoritative for .com. (Other TLDs have
other authoritative servers.) So let's ask l.gtld-servers.net:
$ dig @l.gtld-servers.net www.google.com
[...]
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.google.com. IN A
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 172800 IN A 216.239.34.10
[...]
ns4.google.com. 172800 IN A 216.239.38.10
[...]
The above is an example of a registered domain ("I don't know about
www.google.com, ask ns[1-4].google.com"); if the domain is not registered, it
looks like this:
$ dig @l.gtld-servers.net no-such-domain.com
[...]
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;no-such-domain.com. IN A
;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1301905185 1800 900 604800 86400
[...]
Of course, [a-m].gtld-servers.net are run by Verisign, who could use this information for front-running. I'd be very surprised if they did, though. (DNSSEC may make it possible to query for the existence of a name without revealing it to the answering server, but I'm not sure - I'd have to read up on the protocol.)
Are you referring to my DNSSEC remark? You'll want to look at their NXDOMAIN alternative, which says "there are no domains with hashes between 0xCAFEBABE and 0xDEADBEEF", where the 0x... stuff are hashes.
Note that running through a dictionary and looking for hashes "near" the domain you're interested in works if the DNS server is nice enough to hand out responses of the above form; unfortunately, this can also be used to find which host names are valid for a domain (host names aren't exactly crypto-strength passwords). At least djb advocates giving out answers of the form "there are no domains with hashes between 0xCAFEBABE and 0xCAFEBAC0" (that is, exactly bracketing the query), in which case you'd need to do something more clever.
Unfortunately, I'm not intimately familiar with DNSSEC. I'd be happy to learn the answer, though; if you find it, could you post it as a response, or, if takes a while, e-mail me? (E-mail in profile.)
[EDIT: improved wording, make it clear that actually sending the whole dictionary to the DNS server is not necessary.]
1. That seems to assume that one is using their ISPs DNS service. What if I'm querying the top level .com servers directly? Is that safe?
2. Even if you are using your ISPs DNS servers, if they are getting that data from their logs and selling it I'd expect there would be a fair delay before the data got to some third party that would act on it. That should make it safe if your intent is to buy the domain soon, shouldn't it?