Bare TLD resolutions

David Conrad drc at virtualized.org
Wed Sep 17 16:46:12 UTC 2014


Jay,

On Sep 17, 2014, at 9:09 AM, Jay Ashworth <jra at baylink.com> wrote:
> it seems there are two major potential points of possible collision:
> 
> 1) User network uses "fake" TLD which is no longer fake, and local 
> resolver server blows it
> 
> 2) User network blows it worse, and tries to resolve a monocomponent name
> off non-local servers.

A common case of name collision is driven by the “DNS search path”, e.g., if you have a “search path” of “bar.com;foo.bar.com” and you type “telnet baz”, _some_ resolver libraries will try to resolve “baz.bar.com”, if that fails then “baz.foo.bar.com”, if that fails then “baz.”, if that fails return an error to the user.

However, the "search path” algorithm was never fully standardized and there are implementations that try “baz.” first (there are even some implementations that will split up the path elements, e.g., if ‘baz.bar.com’ fails, the resolver library will try ‘baz.com’).

In my view, given the lack of standardization and the potential security implications, search paths shouldn’t be used at all.

> The latter would seem to be avoidable by making sure that *DNS resolution
> of bare TLDs always returns NXDOMAIN*.

It is quite rare that a TLD is queried for directly. Resolver libraries generally do not parse the name being queried and send the minimum to the authoritative servers. That is, if a resolver is asked for “foo.bar.com”, it sends the entire string to the root server and gets back a referral to the COM servers — it generally does not parse “foo.bar.com” to get the TLD and send “COM” to the root servers to get the referral. This latter behavior is called “QNAME minimization” and is a good idea for performance and privacy (and other reasons), but not yet generally implemented because it is a bit tricky in the general case. 

> If it isn't, does anyone know of any domains dumb enough to actual 
> return something for a lookup on the bare TLD?

There are a few ccTLDs that provide apex wildcards: they’ll return an “A” record for any random goop (.WS is an example), however this behavior is banned from gTLDs (an outcome of the SiteFinder debacle).

> Is there actually *any* good reason why a lookup on a bare TLD ("com.")
> might return a valid record?

Some of the folks in ICANN’s new gTLD program, typically the folks who’ve gone for “brand” TLDs (e.g., .bmw), have argued for what’s called “dotless” domains: they want people to be able to do stuff like point their browsers at “http://bmw” and have the web page for BMW show up.  Unfortunately for them, several oceans have already gone under that particular bridge (see https://www.icann.org/en/system/files/files/sac-053-en.pdf) and ICANN has (to date) resisted those requests. (I actually don’t know if the folks behind .BMW wanted dotless domains — just using BMW as an example)

> And what about Naomi?

Never was a big fan of the chair.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140917/4cbab2a8/attachment.sig>


More information about the NANOG mailing list