hnsd uses a hardcoded ICANN root zone. From the whitepaper:
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.
This doesn't work because it assumes the ICANN root zone never changes. We had to update the zone file in the past to fix the .org TLD already I believe. The .org TLD is now broken again. hnsd serves the following .org DS records:
org. 20416 IN DS 17883 7 1 38C5CF93B369C7557E0515FAAA57060F1BFB12C1
org. 20416 IN DS 17883 7 2 D889CAD790F01979E860D6627B58F85AB554E0E491FE06515F35548D 1EB4E6EE
but .org now has the following:
org. 76777 IN DS 26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
This issue will become more apparent once the DNSSEC PR is merged. The .org TLD will turn bogus. hnsd should use a dynamic fallback like hsd perhaps with the names reserved like in this issue. The root zone DOES change frequently.
ICANN doesn't even recommend keeping their root keys hardcoded and recommends some automated mechanisms like RFC5011 to keep the root keys up to date. Hardcoding the entire root zone is much more problematic.
hnsd uses a hardcoded ICANN root zone. From the whitepaper:
This doesn't work because it assumes the ICANN root zone never changes. We had to update the zone file in the past to fix the .org TLD already I believe. The .org TLD is now broken again. hnsd serves the following .org DS records:
but .org now has the following:
This issue will become more apparent once the DNSSEC PR is merged. The .org TLD will turn bogus. hnsd should use a dynamic fallback like hsd perhaps with the names reserved like in this issue. The root zone DOES change frequently.
ICANN doesn't even recommend keeping their root keys hardcoded and recommends some automated mechanisms like RFC5011 to keep the root keys up to date. Hardcoding the entire root zone is much more problematic.