pinheadmz
commented
4 years ago Thank you @dnsguru. I think this another exception that can be added to the HNS resolver. As far as the blockchain goes, all we are really doing is mapping strings (actually their hash) to 512 bytes of data. Although HNS names must satisfy some rules (length, character set) it makes sense to allow a broad range of usage at the protocol level, then narrow down what is acceptable on the application layer.
I think I've mentioned in your PR, this repo is effectively deprecated. This software was used to create a hard-coded set of constants that are used in the Handshake full node implementation. I therefore encourage you to please close this issue, and reopen a new one in https://github.com/handshake-org/hsd which is where any modification of this kind will actually be applied.
dnsguru
It is problematic to allow 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