rpc dumpzone: dump HNS root zone to file
Closes #152
File output is standard zone file format: https://tools.ietf.org/html/rfc1035#section-5.1
Replaces https://github.com/handshake-org/hsd/pull/280 Based on https://github.com/james-stevens/handshake-bridge by @james-stevens
Major differences from these two predecessors:
- Reads from the Urkel Tree, not the
txn(which include record updates between the 36-block commit cycle) - Includes
TXTrecords (handshake-bridge didn't either by design or by accident by callingResource.toDNS()which results in a referral-only answer)
sample:
melanie. 21600 IN NS ns1.melanie.
melanie. 21600 IN NS ns1.melanie.
xn--u86c8154b. 21600 IN NS ns1.xn--u86c8154b.
xn--u86c8154b. 21600 IN NS ns1.xn--u86c8154b.
cybermage. 21600 IN NS ns1.cybermage.
cybermage. 21600 IN NS ns1.cybermage.
proofofconcept. 21600 IN NS ns.proofofconcept.
proofofconcept. 21600 IN TXT "A simple social network for Handshake"
proofofconcept. 21600 IN TXT "support: hs1qde7jaw6qgzzfu83upn3twvsyhh0zrshg76qe0x"
proofofconcept. 21600 IN DS 17552 8 2 BBBE70AF5CD965360442CBEF40E3299344AF493D339592B93DAA29F7 839C1D58 ; alg = RSASHA256 ; hash = SHA256
chostner. 21600 IN NS ns1.chostner.
chostner. 21600 IN NS ns1.chostner.
n08. 21600 IN NS ns1.n08.
n08. 21600 IN NS ns1.n08.
nongcun. 21600 IN NS ns1.nongcun.
nongcun. 21600 IN NS ns1.nongcun.
xn--mgbkl3fffp. 21600 IN TXT "dummy"
xn--h1alfddcd4f2a. 21600 IN TXT "dummy"
Pull Request Test Coverage Report for Build 602759748
- 5 of 47 (10.64%) changed or added relevant lines in 1 file are covered.
- 1100 unchanged lines in 13 files lost coverage.
- Overall coverage decreased (-0.07%) to 59.347%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % |
|---|---|---|---|
| lib/node/rpc.js | 5 | 47 | 10.64% |
| <!-- | Total: | 5 | 47 |
| Files with Coverage Reduction | New Missed Lines | % |
|---|---|---|
| lib/covenants/rules.js | 1 | 68.63% |
| lib/protocol/consensus.js | 1 | 82.79% |
| lib/net/netaddress.js | 3 | 66.28% |
| lib/covenants/namestate.js | 4 | 89.34% |
| lib/net/brontide.js | 8 | 56.09% |
| lib/net/peer.js | 12 | 33.59% |
| lib/net/hostlist.js | 32 | 38.16% |
| lib/net/pool.js | 34 | 30.34% |
| lib/node/fullnode.js | 38 | 60.91% |
| lib/wallet/walletdb.js | 128 | 77.88% |
| <!-- | Total: | 1100 |
| Totals | |
|---|---|
| Change from base Build 377501416: | -0.07% |
| Covered Lines: | 19525 |
| Relevant Lines: | 30628 |
💛 - Coveralls
Handling a shutdown gracefully during this is also something to consider
Excluding TXT wasn't intentional, I copied the code from #280, but if the name is a delegated subdomain, there should NOT be any TXT records in the parent zone for it anyway. An RFC DNS server would NEVER serve those records, they belong in the zone file for the sub-domain NOT the parent.
The parent owns the DS - and NS & any necessary IPv4 or IPv6 would be served, but all other records for a delegated subdomain would be ignored. named-checkzone will probably fail & moan to you about it.
So having these TXT and expecting them to be served & used is quite a big break of RFC :-1:
If there are TXT in the zone file for the sub-domain (extremely common, e.g for email SPF records), how do you expect a TXT request to be handled?
- Give out ONLY the ones in the ROOT (breaks SPF)
- Give out ONLY those in the zone file (RFC)
- Merge both sets and give out that
By reading the data from the Urkel Tree, you probably solve a few race conditions if data is updated when the dump is run (:+1:), but it would also be nice if the SOA Serial given, when polled over UDP (say), reflected the Urkel Tree update-time, instead of just being the current date & time ... That way the zone data dumped would be consistent with the SOA Serial ... we did discuss this.
Using the Urkel Tree also means if you dump the zone on two different servers, within the same 36-block commit cycle, you should get the same zone - this is good & highly desirable for failover purposes :+1:
Added one more commit https://github.com/handshake-org/hsd/pull/534/commits/e80b835b3a05308a71fac7b5a8647573280ad085 which fixes another SYNTH4/SYNTH6 decoding issue that should have been caught in https://github.com/handshake-org/hsd/pull/444
Example output of my own mainnet name omnitude with SYNTH records:
omnitude. 21600 IN NS _5l6tm80._synth.
omnitude. 21600 IN DS 26614 8 2 A20BC6F9ADA0883326A05374D0D0C0E6290CEF580D00B9B957703014 41733B7F ; alg = RSASHA256 ; hash = SHA256
omnitude. 21600 IN NS _400hjs000l2gol000fvvsc9cpg._synth.
_5l6tm80._synth. 21600 IN A 45.77.219.32
_400hjs000l2gol000fvvsc9cpg._synth. 21600 IN AAAA 2001:19f0:5:450c:5400:3ff:fe31:2ccc
Also worth noting that https://github.com/handshake-org/hsd/pull/566 may affect this rpc output concerning TXT records in the root zone, but I think we decided that was ok. Currently this branch will print TXT even if NS is present:
proofofconcept. 21600 IN NS ns.proofofconcept.
proofofconcept. 21600 IN TXT "A simple social network for Handshake"
proofofconcept. 21600 IN TXT "support: hs1qde7jaw6qgzzfu83upn3twvsyhh0zrshg76qe0x"
proofofconcept. 21600 IN DS 17552 8 2 BBBE70AF5CD965360442CBEF40E3299344AF493D339592B93DAA29F7 839C1D58 ; alg = RSASHA256 ; hash = SHA256
ns.proofofconcept. 21600 IN A 142.93.115.133
new TODO: some names have unknown resource versions, bypass them, otherwise the process will throw and abort.
diff --git a/lib/node/rpc.js b/lib/node/rpc.js
index 1973aa98e..96f276574 100644
--- a/lib/node/rpc.js
+++ b/lib/node/rpc.js
@@ -2629,7 +2629,19 @@ class RPC extends RPCBase {
continue;
const fqdn = bns.util.fqdn(ns.name.toString('ascii'));
- const resource = Resource.decode(ns.data);
+
+ let resource;
+ try {
+ resource = Resource.decode(ns.data);
+ } catch (e) {
+ this.logger.warning(
+ 'could not process resource for name: %s (%s)',
+ fqdn,
+ e.message
+ );
+ continue;
+ }
+
const zone = resource.toZone(fqdn);
for (const record of zone) {
if (fd == null)
result:
[debug] (node-rpc) dumpzone names processed: 2230000
[debug] (node-rpc) dumpzone names processed: 2240000
[warning] (node-rpc) could not process resource for name: roivantsciences. (Unknown serialization version: 2.)
TBH: I think buffrr's AXFR plug-in is a better solution than this, so (personally) I'd just drop this
https://github.com/buffrr/hsd-axfr