hsd
hsd copied to clipboard
handshake-org
Unexpected dig +trace behavior
I am trying to find the nearest parent DS record for a domain, and I'm running into an issue that seems to be related to the synth address. The following works to find the DS records of the parents of www.isc.org.
➜ ~ dig @8.8.8.8 +trace www.isc.org | grep -w 'IN[[:space:]]*DS'
org. 86400 IN DS 26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
isc.org. 86400 IN DS 7250 13 2 A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697 CDA01CB2
But this does not work with my HSD recursive resolver running on port 53.
➜ ~ dig @127.0.0.1 +trace www.isc.org | grep -w 'IN[[:space:]]*DS'
dig: couldn't get address for '_fs00008._synth': no more
Came across this issue, and after configuring my hsd resolver in /etc/resolv.conf, the error disappears, but I do not got the expected response.
➜ ~ dig +trace www.isc.org | grep -w 'IN[[:space:]]*DS'
➜ ~
➜ ~ dig +trace www.isc.org
; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> +trace www.isc.org
;; global options: +cmd
. 515920 IN NS _fs00008._synth.
. 8320 IN RRSIG NS 13 0 518400 20230106011014 20220105011014 60944 . a651SserHwmby4rcVMsGMHAJLYAyBxLzrN1v7E4C+JE66Dz7zyP8ViK/ 8x0hebV5z4CMqOfX7zEFtpxPNy6G9g==
;; Received 256 bytes from 66.42.108.201#53(66.42.108.201) in 1 ms
www.isc.org. 200 IN CNAME dualstack.osff2.map.fastly.net.
www.isc.org. 200 IN RRSIG CNAME 13 3 300 20220123151519 20211224144419 27566 isc.org. QSz8TD9BvYxxQAS3OuatwDISaabQoqlVqH872T2adlty75gk7QQsiDLA vRseeGxzseaxkP7CYzCH365SaixmtA==
dualstack.osff2.map.fastly.net. 15 IN A 151.101.198.217
;; Received 302 bytes from 127.0.0.1#53(_fs00008._synth) in 1 ms
It also does not work for on chain TLDs. I have a single DS record on the blockchain for ns9.
➜ ~ dig ns9 DS
...
;; ANSWER SECTION:
ns9. 18612 IN DS 1 15 0 1FBC442BD3F7F5D5D6DCC3FD90EB67CF732A45525171752B3957BA27 835BC6CD
...
However, the DS record is absent from the trace.
➜ ~ dig +trace ns9 | grep -w 'IN[[:space:]]*DS'
➜ ~
➜ ~ dig +trace ns9
; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> +trace ns9
;; global options: +cmd
. 514976 IN NS _fs00008._synth.
. 7376 IN RRSIG NS 13 0 518400 20230106011014 20220105011014 60944 . a651SserHwmby4rcVMsGMHAJLYAyBxLzrN1v7E4C+JE66Dz7zyP8ViK/ 8x0hebV5z4CMqOfX7zEFtpxPNy6G9g==
;; Received 256 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms
ns9. 18404 IN NSEC ns9\000. RRSIG NSEC
ns9. 7604 IN RRSIG NSEC 13 1 21600 20230106011402 20220105011402 60944 . rlFhaSa+vbtDsM9FXGv9Zd7muco3aoexhO25LD9xzctuDaEwSLnsFo9s toDSwQKQqY1LzK3RWK8yaa+3Godnww==
. 83204 IN SOA . . 2022010601 1800 900 604800 21600
. 7604 IN RRSIG SOA 13 0 86400 20230106011402 20220105011402 60944 . Hhin3It1ZIVK1d8A/L6Cg2mHErtMMB0xV4DT470gU6Rdx/jmQ39po6cy vYoJd2Jh5kMLID+6XrG3noXPnMbCOA==
;; Received 386 bytes from 127.0.0.1#53(_fs00008._synth) in 1 ms
Is this an issue with the recursive resolver returning an incomplete response, or is it tied up with the synth address root server?
Is the recursive resolver really a recursive resolver?
➜ ~ dig +trace com | grep -w 'IN[[:space:]]*NS'
. 512784 IN NS _fs00008._synth.
➜ ~ dig @8.8.8.8 +trace com | grep -w 'IN[[:space:]]*NS'
. 25141 IN NS e.root-servers.net.
. 25141 IN NS h.root-servers.net.
. 25141 IN NS l.root-servers.net.
. 25141 IN NS i.root-servers.net.
. 25141 IN NS a.root-servers.net.
. 25141 IN NS d.root-servers.net.
. 25141 IN NS c.root-servers.net.
. 25141 IN NS b.root-servers.net.
. 25141 IN NS j.root-servers.net.
. 25141 IN NS k.root-servers.net.
. 25141 IN NS g.root-servers.net.
. 25141 IN NS m.root-servers.net.
. 25141 IN NS f.root-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
www.isc.org. 200 IN CNAME dualstack.osff2.map.fastly.net. www.isc.org. 200 IN RRSIG CNAME 13 3 300 20220123151519 20211224144419 27566 isc.org. QSz8TD9BvYxxQAS3OuatwDISaabQoqlVqH872T2adlty75gk7QQsiDLA vRseeGxzseaxkP7CYzCH365SaixmtA== dualstack.osff2.map.fastly.net. 15 IN A 151.101.198.217 ;; Received 302 bytes from 127.0.0.1#53(_fs00008._synth) in 1 ms
It's weird that you're getting a recursive answer here. Is 127.0.0.1#53 the address of hsd's recursive because _fs00008._synth should point to hsd root server. So this setup doesn't seem to be correct.
I was unable to reproduce your issue with this setup:
127.0.0.2 => hsd root server
127.0.0.3 => hsd recursive resolver.
$ hsd --ns-host 127.0.0.2 --ns-port 53 --rs-host 127.0.0.3 --rs-port 53
Update your /etc/resolv.conf to have 127.0.0.3 as your nameserver (recursive).
Now try
$ dig +trace www.isc.org | grep -w 'IN[[:space:]]*DS'
org. 86400 IN DS 26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
isc.org. 86400 IN DS 7250 13 2 A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697 CDA01CB2
However, the DS record is absent from the trace.
That's a different issue. You shouldn't have a DS record without an NS record (ns9 should have an NS record).
Ok, I see. This is also what @pinheadmz pointed out to me on Discord. The above configuration works for me.
Is this the prescribed behavior in the RFC — to not provide DS records in the absence of NS records?
Is this the prescribed behavior in the RFC — to not provide DS records in the absence of NS records?
Yes. "DS RRsets MUST NOT appear at non-delegation points or at a zone's apex." RFC3658 section-2.2.
DS stands for "Delegation Signer" it doesn't make sense to have a delegation signer without a delegation. What purpose would it serve? If you're trying to use a DS record for off-label uses then that would be a bad idea. Maybe a TXT record would be a better fit.
Thanks, this clears things up.
For context, I'm experimenting with a hybrid DHT/DNS system where zone files are decentralized data structures addressed by DS digest (e.g. see A Comparative Study of the DNS Design with DHT-Based Alternatives for why this isn't a crazy idea).
There may or may not be NS records assigned, and when they are assigned, the name servers are just proxy servers serving authoritative records that anyone can locate and verify off-DNS using the DS digest as an identifier. The DS record delegates ownership explicitly to the owner of the public key in manner that doesn't require trust in any particular name server.
An example of not assigning NS records would be a p2p protocol that wishes to utilize DNS as part of a naming system, but wants to force its users to resolve and verify records over DHT rather than over DNS (slower, but more secure). In this case, it will use DNS to resolve the DS digest, then locate and verify zone records over DHT. I don't know if it's ever actually advantageous to do this sort of thing, but I hope it at least shows that it's not too absurd to want this sort of behavior.
Using a TXT record in this scenario would just be redundant. There's a single public key that is used to both validate records with DNSSEC and to validate the zone file over DHT. It's not exactly "off-label," because when NS records are set, DNS works as expected with DNSSEC. In this case, records are also backed by a DHT that is e.g. more robust against DDoS attacks.