Handshake TLDs .0 and .1 ... .255 confusion with IPv4 Namespace

[dnsguru]

(Migrated from hs-names#9 as advised by @pinheadmz)

It is problematic to allow resolution for TLDs that are entirely numeric, as IPv4 addresses and DNS use the period as delimiters and this will confuse applications.

This refers to any digit between “0” and “9” (Unicode code points U+0030 to U+0039)

Specifically problematic are the .0 and then .1 through .255, but purely numeric TLDs of any size are also problematic when used as the entire host component of a URL, as many BSD networking stacks still convert Quad A record IP addresses from pure numeric entries.

Example: HNS TLD = .8, one could give a hostname 8.8.8 and put it in the .8 TLD, which would make that host 8.8.8.8 in the DNS, which could cause a lot of mayhem within HNS resolvers that might fall back to DNS.Google for lookups.

Example: HNS TLD = .1, one could establish a host 127.0.0 and put it in the .1 TLD, which would confuse certain software attempting to connect to 127.0.0.1, which is typically "localhost"

Other examples in the .0 and .1-.255 range are hopefully self-explanatory

The example of a purely numeric string outside of that range is largely with the use of the TLD itself as a resolution point...

See This Article which articulates the dotted quad binary to integer computation

[chjj]

Hi @dnsguru,

I think this is something we discussed in the past. Typically, most (if not all) applications do not query DNS for a hostname which deserializes to an IP address. I'm not aware of any web browser that does this for example. I've never seen an application query my local resolver for an IP address (ever). In my opinion, an application doing DNS queries on IP addresses is probably already broken in other ways and should not be used.

That said, accidents do happen. I agree there's still a fair case to be made that an application could mistakenly query an IP address and end up with disastrous results. Like @pinheadmz mentioned, I think an acceptable solution would be for resolvers to simply return NXDOMAIN for any [0-255] TLD and not even attempt to resolve via the HNS network.

I think we should maybe start to document edge cases like this to create guidelines for HNS resolver implementation. In the more immediate term we can implement this fix in hsd. Leaving this issue open.

[pinheadmz]

Please see https://github.com/pinheadmz/holdmyhand which requires update to hsd (review requested!) #558

[pinheadmz]

I'm going to close this now because, as the mathematicians like to say "the solution exists". #558 is merged, and the holdmyhand plugin has been released. Users or services interested in applying extra protection can do so in the applicaiton layer (i.e. with a plugin) and so I don't think this is a relevant issue to hsd anymore.