Root NS doesn't always "fall back" to ICANN: only if TLD is on reserved name list

[pinheadmz]

I notice something today about the HNS "dynamic fallback". We don't lookup via ICANN just because a name isn't in the HNS root zone. We check our own reserved list (filtered by root - so TLDs only not Alexa names) and only check names via ICANN if they are on that internal list. This means that TLDs like esurance. which are NO LONGER in the ICANN root zone, and TLDs like amazon. which were ADDED to the ICANN root zone after HNS mainnet launch will be resolved incorrectly.

I'm not sure the purpose of this, I'm sure the HNS designers were aware that ICANN could/would add more TLDs to its root zone over time.

Seems "obvious" (?) to remove this and fall back to ICANN how we've been thinking it works, but I'll try to see if theres a reason to use an (outdated) root zone for this instead...

hsd/lib/dns/server.js

Lines 328 to 348 in a94ce87

	// Non-existent domain.
	if (!data) {
	const item = reserved.getByName(tld);
	// This name is in the existing root zone.
	// Fall back to ICANN's servers if not yet
	// registered on the handshake blockchain.
	// This is an example of "Dynamic Fallback"
	// as mentioned in the whitepaper.
	if (item && item.root) {
	const res = await this.icann.lookup(tld);
	if (res.ad && res.code !== codes.NXDOMAIN) {
	res.ad = false;
	res.question = [qs];
	key.signZSK(res.authority, types.DS);
	key.signZSK(res.authority, types.NSEC);
	key.signZSK(res.authority, types.NSEC3);
	return res;
	}
	}

[pinheadmz]

Example:

HNS answers for com but not amazon

--> dig com ns +short
i.gtld-servers.net.
c.gtld-servers.net.
e.gtld-servers.net.
d.gtld-servers.net.
h.gtld-servers.net.
b.gtld-servers.net.
k.gtld-servers.net.
j.gtld-servers.net.
f.gtld-servers.net.
a.gtld-servers.net.
m.gtld-servers.net.
g.gtld-servers.net.
l.gtld-servers.net.
--> dig amazon ns +short
(no answer)

Cloudflare can answer for amazon

--> dig @1.1.1.1 amazon ns +short
dns1.nic.amazon.
dns2.nic.amazon.
dns3.nic.amazon.
dns4.nic.amazon.
dnsa.nic.amazon.
dnsb.nic.amazon.
dnsc.nic.amazon.
dnsd.nic.amazon.

[pinheadmz]

From the whitepaper:

Root Zone Fallback

Due to the fact that not all reserved root names will be claimed by nameholders
immediately, we propose two solutions for eventual transparent rollover to the
new system: Hardcoded Fallback, and Dynamic Fallback.

Hardcoded fallback involves hard-coding the existing ICANN zonefile into the
SPV software. When an absence proof is received by the authoritative server for
a pre-existing TLD, the hardcoded fallback is checked for records and returned
as a DNS response.

Dynamic fallback is similar, but involves querying ICANN's root servers and
validating the response against their trust anchors. This provides better
liveness, but bestows more power upon a centralized authority.

In both constructions, once a pre-reserved name is claimed by the proper owner,
the software will transparently begin to follow the blockchain instead of
either hardcoded records or ICANN's records.

So I guess its a question of trusting the root anchors. Although hsd would still need to be updated if we wanted to resolve "new" ICANN TLDs.

[pinheadmz]

Another perspective on this, after discussing with @buffrr is that the design might have intended to ignore all new ICANN domains after mainnet launched - simply because those strings would NOT be reserved on HNS and so a collision could be introduced after ICANN adds a new TLD. Imagine the .music story but reverse order: ICANN adds a new TLD .exciting and websites start popping up and getting user credentials etc. Then the TLD is acquired on HNS and assigned different NS records, and the HNS domain can phish user credentials. This order of events is a bit more troublesome than the .music story, and it explains why we only check the ICANN root if a TLD is on the reserved name list.