Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dnsguru opened this issue May 16, 2020 · 2 comments
Closed

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

dnsguru opened this issue May 16, 2020 · 2 comments

Comments

@dnsguru
Copy link

dnsguru commented May 16, 2020

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

@pinheadmz
Copy link
Member

pinheadmz commented May 16, 2020

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
Copy link
Author

dnsguru commented May 17, 2020

@dnsguru dnsguru closed this as completed May 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants