4 ms·

DNS Terminology

60 points by _jomo 11y ago

Animats 11y ago
Ah, yes. There's an additional mess not documented there, which is in the standard C library for DNS resolution.[1] The semantics there are not quite what you might expect. A fully qualified domain name has a dot at the end, as in "example.com.". Such a domain name must be looked up relative to the root. For non fully qualified domains, "resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found." The idea was that if you're on "foo.com", and you want to reach "bar.com", you can just type "bar". This has some unexpected side effects if "ndots" is > 1, which it is on some systems. If you're on "foo.com", and you look up "nosuchdomain.com", the resolver tries "nosuchdomain.com." and gets a no-find. Then it tries "nosuchdomain.com.com." There, it gets a find, because "com.com" has a resolver which reports a find for anything of the form "*.com.com.", leading, of course, to a page of ads. Then there's the problem of single label top-level domains. If you type one word into a browser, should it be looked up as a domain or fed to a search engine? Browsers usually choose to search first. But try putting a "." after the query; browsers are inconsistent. There are an insane number of TLDs now.[2] Some of the one-word ccTLDs do resolve to an real IP address. "ac.", for example. Some of the new one-word TLDs, such as "gmail." and "fairwinds." resolve to "127.0.53.53", which is meaningless. ICANN took the position that single-word TLDs should not resolve to IP addresses, and mostly, they don't. Then there's the question of whether IPv6 addresses should be looked up first, second, or simultaneously. And, if simultaneously, do you take the first response, or wait for both responses, one of which may time out and stall your DNS query? [1] http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html [2] https://publicsuffix.org/list/public_suffix_list.dat https://publicsuffix.org/list/public_suffix_list.dat
- n0us 11y ago
  > "*.com.com.", leading, of course, to a page full of ads. had to laugh at this part. I tried a whois lookup but they have protection on. I'd be curious to know how much this person makes off this domain and whether or not they filled it up with ads as a kind of pun on the internet. I learned something new though, I did not know that some browsers would search the relative path for a non qualified name. Thanks for that info.
- darkr 11y ago
  > There, it gets a find, because "com.com" has a resolver which reports a find for anything of the form "*.com.com.", leading, of course, to a page of ads. There's a few insane SLDs, such as 'uk.com', (operated by centralnic - though owned by demys) which responds with an A record for any unknown query, that should result in an NXDOMAIN. The webserver at that record has a link to buy the domain from centralnic, and a bunch of chinese language ads from Baidu. $ for RAND in $(uuid -n 10); do QUERY="$(uuid).${RAND}.$(uuid).uk.com"; echo "searching for ${QUERY}"; dig +short $QUERY; done searching for dc39f90a-a4aa-11e5-92e9-1c872c602432.dc39e492-a4aa-11e5-9d09-1c872c602432.dc3a0ba2-a4aa-11e5-b8dd-1c872c602432.uk.com 205.164.14.88 searching for dceaa728-a4aa-11e5-ad0a-1c872c602432.dc39e50a-a4aa-11e5-9d0a-1c872c602432.dceab920-a4aa-11e5-81a4-1c872c602432.uk.com 205.164.14.88 searching for dcf0df9e-a4aa-11e5-8613-1c872c602432.dc39e51e-a4aa-11e5-9d0b-1c872c602432.dcf0f218-a4aa-11e5-8abf-1c872c602432.uk.com 205.164.14.88 searching for dcf95dcc-a4aa-11e5-a599-1c872c602432.dc39e532-a4aa-11e5-9d0c-1c872c602432.dcf970be-a4aa-11e5-b099-1c872c602432.uk.com 205.164.14.88 searching for dcffa6c8-a4aa-11e5-81ac-1c872c602432.dc39e53c-a4aa-11e5-9d0d-1c872c602432.dcffba8c-a4aa-11e5-884c-1c872c602432.uk.com 205.164.14.88 searching for dd45fa4c-a4aa-11e5-82d0-1c872c602432.dc39e546-a4aa-11e5-9d0e-1c872c602432.dd460d0c-a4aa-11e5-a519-1c872c602432.uk.com 205.164.14.88 searching for ddacda6e-a4aa-11e5-89ba-1c872c602432.dc39e55a-a4aa-11e5-9d0f-1c872c602432.ddaced42-a4aa-11e5-913c-1c872c602432.uk.com 205.164.14.88 searching for ddb4995c-a4aa-11e5-bc63-1c872c602432.dc39e564-a4aa-11e5-9d10-1c872c602432.ddb4abfe-a4aa-11e5-9f73-1c872c602432.uk.com 205.164.14.88 searching for ddba4a82-a4aa-11e5-bb77-1c872c602432.dc39e56e-a4aa-11e5-9d11-1c872c602432.ddba5dce-a4aa-11e5-92cc-1c872c602432.uk.com 205.164.14.88 searching for ddc08ece-a4aa-11e5-80da-1c872c602432.dc39e582-a4aa-11e5-9d12-1c872c602432.ddc0a3b4-a4aa-11e5-b2b4-1c872c602432.uk.com 205.164.14.88

60 points by _jomo 11y ago

Ah, yes. There's an additional mess not documented there, which is in the standard C library for DNS resolution.[1] The semantics there are not quite what you might expect. A fully qualified domain name has a dot at the end, as in "example.com.". Such a domain name must be looked up relative to the root. For non fully qualified domains, "resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found." The idea was that if you're on "foo.com", and you want to reach "bar.com", you can just type "bar". This has some unexpected side effects if "ndots" is > 1, which it is on some systems. If you're on "foo.com", and you look up "nosuchdomain.com", the resolver tries "nosuchdomain.com." and gets a no-find. Then it tries "nosuchdomain.com.com." There, it gets a find, because "com.com" has a resolver which reports a find for anything of the form "*.com.com.", leading, of course, to a page of ads. Then there's the problem of single label top-level domains. If you type one word into a browser, should it be looked up as a domain or fed to a search engine? Browsers usually choose to search first. But try putting a "." after the query; browsers are inconsistent. There are an insane number of TLDs now.[2] Some of the one-word ccTLDs do resolve to an real IP address. "ac.", for example. Some of the new one-word TLDs, such as "gmail." and "fairwinds." resolve to "127.0.53.53", which is meaningless. ICANN took the position that single-word TLDs should not resolve to IP addresses, and mostly, they don't. Then there's the question of whether IPv6 addresses should be looked up first, second, or simultaneously. And, if simultaneously, do you take the first response, or wait for both responses, one of which may time out and stall your DNS query? [1] http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html [2] https://publicsuffix.org/list/public_suffix_list.dat https://publicsuffix.org/list/public_suffix_list.dat

n0us 11y ago
> "*.com.com.", leading, of course, to a page full of ads. had to laugh at this part. I tried a whois lookup but they have protection on. I'd be curious to know how much this person makes off this domain and whether or not they filled it up with ads as a kind of pun on the internet. I learned something new though, I did not know that some browsers would search the relative path for a non qualified name. Thanks for that info.
darkr 11y ago
> There, it gets a find, because "com.com" has a resolver which reports a find for anything of the form "*.com.com.", leading, of course, to a page of ads. There's a few insane SLDs, such as 'uk.com', (operated by centralnic - though owned by demys) which responds with an A record for any unknown query, that should result in an NXDOMAIN. The webserver at that record has a link to buy the domain from centralnic, and a bunch of chinese language ads from Baidu. $ for RAND in $(uuid -n 10); do QUERY="$(uuid).${RAND}.$(uuid).uk.com"; echo "searching for ${QUERY}"; dig +short $QUERY; done searching for dc39f90a-a4aa-11e5-92e9-1c872c602432.dc39e492-a4aa-11e5-9d09-1c872c602432.dc3a0ba2-a4aa-11e5-b8dd-1c872c602432.uk.com 205.164.14.88 searching for dceaa728-a4aa-11e5-ad0a-1c872c602432.dc39e50a-a4aa-11e5-9d0a-1c872c602432.dceab920-a4aa-11e5-81a4-1c872c602432.uk.com 205.164.14.88 searching for dcf0df9e-a4aa-11e5-8613-1c872c602432.dc39e51e-a4aa-11e5-9d0b-1c872c602432.dcf0f218-a4aa-11e5-8abf-1c872c602432.uk.com 205.164.14.88 searching for dcf95dcc-a4aa-11e5-a599-1c872c602432.dc39e532-a4aa-11e5-9d0c-1c872c602432.dcf970be-a4aa-11e5-b099-1c872c602432.uk.com 205.164.14.88 searching for dcffa6c8-a4aa-11e5-81ac-1c872c602432.dc39e53c-a4aa-11e5-9d0d-1c872c602432.dcffba8c-a4aa-11e5-884c-1c872c602432.uk.com 205.164.14.88 searching for dd45fa4c-a4aa-11e5-82d0-1c872c602432.dc39e546-a4aa-11e5-9d0e-1c872c602432.dd460d0c-a4aa-11e5-a519-1c872c602432.uk.com 205.164.14.88 searching for ddacda6e-a4aa-11e5-89ba-1c872c602432.dc39e55a-a4aa-11e5-9d0f-1c872c602432.ddaced42-a4aa-11e5-913c-1c872c602432.uk.com 205.164.14.88 searching for ddb4995c-a4aa-11e5-bc63-1c872c602432.dc39e564-a4aa-11e5-9d10-1c872c602432.ddb4abfe-a4aa-11e5-9f73-1c872c602432.uk.com 205.164.14.88 searching for ddba4a82-a4aa-11e5-bb77-1c872c602432.dc39e56e-a4aa-11e5-9d11-1c872c602432.ddba5dce-a4aa-11e5-92cc-1c872c602432.uk.com 205.164.14.88 searching for ddc08ece-a4aa-11e5-80da-1c872c602432.dc39e582-a4aa-11e5-9d12-1c872c602432.ddc0a3b4-a4aa-11e5-b2b4-1c872c602432.uk.com 205.164.14.88