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

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...

https://github.com/handshake-org/hsd/blob/a94ce87a886e943a68d4a3e67068f6e473c21156/lib/dns/server.js#L328-L348

Start in lib/dns/server.js at lines 328-348 and trace how dynamic fallback checks the reserved root list before querying ICANN. Compare the handling of esurance. and amazon. with the intended fallback behavior; done means the resolution rule is clearly decided and covered for TLDs absent from or newly added to the ICANN root zone.

Written by the indexing model from the issue text.