chjj / bns Goto Github PK

View Code? Open in Web Editor NEW

66.0 66.0 24.0 3.43 MB

Recursive DNS server and resolver for node.js

License: Other

JavaScript 100.00%

bns's People

Contributors

Stargazers

Watchers

bns's Issues

Dynamic DNS RFC 2136 Support

I'd like to be able to dynamically update my zone file in a safe and secure way. Looking for prior art, I came across this RFC for Dynamic DNS - https://tools.ietf.org/html/rfc2136

Looking through the bns codebase, I didn't see any mentions of Dynamic DNS or ways to update the zone file dynamically without building a wrapper around the AuthServer and calling setFile with an updated zone file. This doesn't seem like the ideal solution.

RFC 2136 at least uses the DNS protocol itself to update the zone file, so that an additional HTTP server doesn't need to be ran. It also includes a permission system

the requestor's permission to update the RRs named in
the Update Section may be tested in an implementation dependent
fashion or using mechanisms specified in a subsequent Secure DNS
Update protocol. If the requestor does not have permission to
perform these updates, the server may write a warning message in its
operations log, and may either signal REFUSED to the requestor, or
ignore the permission problem and proceed with the update.

Supporting a very easy way for users to update their zone files is important for Handshake.

Lazy require causing webpack warning

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

This is being thrown when including hsd in a project being built with webpack

Return SERVFAIL when dnssec fails to validate

All popular resolvers (1.1.1.1, 8.8.8.8, etc.) do not return records if DNSSEC verification fails. But bns returns records with the ad flag (correctly) unset.

other resolvers:

❯ dig @8.8.8.8 dnssec-failed.org

; <<>> DiG 9.18.1 <<>> @8.8.8.8 dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31099
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dnssec-failed.org.             IN      A

;; Query time: 840 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon May 16 15:47:44 IST 2022
;; MSG SIZE  rcvd: 46

What bns does:

❯ dig @127.0.0.1 -p 5350 dnssec-failed.org

; <<>> DiG 9.18.1 <<>> @127.0.0.1 -p 5350 dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14474
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: f166791f3edc3b37 (echoed)
;; QUESTION SECTION:
;dnssec-failed.org.             IN      A

;; ANSWER SECTION:
dnssec-failed.org.      300     IN      A       96.99.227.255

;; Query time: 3900 msec
;; SERVER: 127.0.0.1#5350(127.0.0.1) (UDP)
;; WHEN: Mon May 16 15:53:34 IST 2022
;; MSG SIZE  rcvd: 74

Doc example doesn't seem to work

It looks like the readme examples are out of date.

In the Base Server example, dns.Server is undefined (it's not exported from require("bns")).

If I change it to bns.DNSServer, server.on("query") is never invoked and an assertion error is emitted from server.on("error").

If I change it to bns.AuthServer, server.on("query") is invoked, but it looks like you shouldn't call res.send() ("res.send is not a function" is emitted). An assertion error happens in this case also.

If I change it to bns.StubServer, ditto, except Error: No servers available is emitted instead of the assertion failure.

Since you're apparently not supposed to call res.send(), does that mean it's not possible to have an async response?

([email protected])

Cannot use TCP DNS query

CNAME in Zones

Currently, bns only returns CNAME from a Zone as an authoritative server if the CNAME record is requested directly. If a server is authoritative for a certain name, I believe it should respond with the CNAME record to queries for all record types.

Wildcard entries returning answers for non-matching zone in authoritative nameserver

Trying to run an AuthServer locally with both of these setups:

server.setOrigin('myzone.');
server.zone.fromString('*.myzone. 21600 IN A 10.20.30.40');

server.setOrigin('myzone.');
server.zone.fromString('* 21600 IN A 10.20.30.40');

In both cases I'm getting unexpected results for names that do not match the zone:

dig @127.0.0.1 -p 5300 test.com

; <<>> DiG 9.14.6 <<>> @127.0.0.1 -p 5300 test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16083
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.com.                      IN      A

;; ANSWER SECTION:
test.myzone.            21600   IN      A       10.20.30.40

;; Query time: 10 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1)
;; WHEN: Mon Apr 27 15:01:21 EDT 2020
;; MSG SIZE  rcvd: 64

bns is attaching the first label in the query to the zone and returning.

aa flag not set by authoritative nameserver when answering subdomain

Need to look into this, not sure if this is correct or not.

I have a zone with origin localhost and A records for localhost and *.localhost (so this issue might be related to the wildcard)

root, `aa` flag is present

$ dig @127.0.0.1 localhost

; <<>> DiG 9.16.3 <<>> @127.0.0.1 localhost
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63489
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;localhost.                     IN      A

;; ANSWER SECTION:
localhost.              21600   IN      A       127.0.0.1
*.localhost.            21600   IN      A       127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jul 05 18:06:51 EDT 2020
;; MSG SIZE  rcvd: 72

subdomain, `aa` flag missing

$ dig @127.0.0.1 a.localhost

; <<>> DiG 9.16.3 <<>> @127.0.0.1 a.localhost
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44155
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;a.localhost.                   IN      A

;; ANSWER SECTION:
a.localhost.            21600   IN      A       127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jul 05 18:06:56 EDT 2020
;; MSG SIZE  rcvd: 56

dnssec.sign() requires all names in RRset to be equal

Referencing discussion at pinheadmz/handout@f98b5af#r38119497

I want to sign these two A records in my zone:

*.examplename. IN A <IP>
examplename. IN A <IP>

Using dnssec.sign() to sign an RRset calls dnssec.signRRSIG() which calls:

util.isRRSet()
dnssec.signatureHash()

dnssec.signatureHash() seems to allow A records with different names, particularly in the case of wildcards:

bns/lib/dnssec.js

Lines 381 to 389 in 3c757ce

    
           const rr = item.deepClone(); 
        
           const labels = splitName(rr.name); 
        
           // Server is using wildcards. 
        
           if (labels.length > sd.labels) { 
        
             const i = labels.length - sd.labels; 
        
             const name = labels.slice(i).join('.'); 
        
             rr.name = `*.${name}.`; 
        
           }

However the call never gets that far because an error is thrown in util.isRRSet() first:

bns/lib/util.js

Lines 483 to 492 in 3c757ce

    
           const name = rrset[0].name; 
        
           for (let i = 1; i < rrset.length; i++) { 
        
             const rr = rrset[i]; 
        
             if (rr.type !== type 
        
                 || rr.class !== class_ 
        
                 || !util.equal(rr.name, name)) { 
        
               return false; 
        
             }

ModuleNotFoundError: No module named 'distutils'

Hey, since python update 3.12 the distutils module has been deprecated, because of that I am getting an error when I'm trying to install bns package. Here is the [node-gyp](nodejs/node-gyp#2869) GitHub repository to the problem.

npm ERR! code 1
npm ERR! path C:\Users\xxx\applications\node\node_modules\bcrypto
npm ERR! command failed
npm ERR! command C:\Windows\system32\cmd.exe /d /s /c node-gyp rebuild
npm ERR! gyp info it worked if it ends with ok
npm ERR! gyp info using [email protected]
npm ERR! gyp info using [email protected] | win32 | x64
npm ERR! gyp info find Python using Python version 3.12.0 found at "C:\Python312\python.exe"
npm ERR! gyp info find VS using VS2022 (17.5.33414.496) found at:
npm ERR! gyp info find VS "C:\Program Files\Microsoft Visual Studio\2022\Community"
npm ERR! gyp info find VS run with --verbose for detailed information
npm ERR! gyp info spawn C:\Python312\python.exe
npm ERR! gyp info spawn args [
npm ERR! gyp info spawn args 'C:\Users\xxx\applications\node\node_modules\node-gyp\gyp\gyp_main.py',
npm ERR! gyp info spawn args 'binding.gyp',
npm ERR! gyp info spawn args '-f',
npm ERR! gyp info spawn args 'msvs',
npm ERR! gyp info spawn args '-I',
npm ERR! gyp info spawn args 'C:\Users\xxx\applications\node\node_modules\bcrypto\build\config.gypi',
npm ERR! gyp info spawn args '-I',
npm ERR! gyp info spawn args 'C:\Users\xxx\applications\node\node_modules\node-gyp\addon.gypi',
npm ERR! gyp info spawn args '-I',
npm ERR! gyp info spawn args 'C:\Users\xxx\AppData\Local\node-gyp\Cache\19.0.0\include\node\common.gypi',
npm ERR! gyp info spawn args '-Dlibrary=shared_library',
npm ERR! gyp info spawn args '-Dvisibility=default',
npm ERR! gyp info spawn args '-Dnode_root_dir=C:\Users\xxx\AppData\Local\node-gyp\Cache\19.0.0',
npm ERR! gyp info spawn args '-Dnode_gyp_dir=C:\Users\xxx\applications\node\node_modules\node-gyp',
npm ERR! gyp info spawn args '-Dnode_lib_file=C:\\Users\\xxx\\AppData\\Local\\node-gyp\\Cache\\19.0.0\\<(target_arch)\\node.lib',
npm ERR! gyp info spawn args '-Dmodule_root_dir=C:\Users\xxx\applications\node\node_modules\bcrypto',
npm ERR! gyp info spawn args '-Dnode_engine=v8',
npm ERR! gyp info spawn args '--depth=.',
npm ERR! gyp info spawn args '--no-parallel',
npm ERR! gyp info spawn args '--generator-output',
npm ERR! gyp info spawn args 'C:\Users\xxx\applications\node\node_modules\bcrypto\build',
npm ERR! gyp info spawn args '-Goutput_dir=.'
npm ERR! gyp info spawn args ]
npm ERR! Traceback (most recent call last):
npm ERR! File "C:\Users\xxx\applications\node\node_modules\node-gyp\gyp\gyp_main.py", line 42, in
npm ERR! import gyp # noqa: E402
npm ERR! ^^^^^^^^^^
npm ERR! File "C:\Users\xxx\applications\node\node_modules\node-gyp\gyp\pylib\gyp_init_.py", line 9, in
npm ERR! import gyp.input
npm ERR! File "C:\Users\xxx\applications\node\node_modules\node-gyp\gyp\pylib\gyp\input.py", line 19, in
npm ERR! from distutils.version import StrictVersion
npm ERR! ModuleNotFoundError: No module named 'distutils'
npm ERR! gyp ERR! configure error
npm ERR! gyp ERR! stack Error: gyp failed with exit code: 1
npm ERR! gyp ERR! stack at ChildProcess.onCpExit (C:\Users\xxx\applications\node\node_modules\node-gyp\lib\configure.js:325:16)
npm ERR! gyp ERR! stack at ChildProcess.emit (node:events:513:28)
npm ERR! gyp ERR! stack at ChildProcess._handle.onexit (node:internal/child_process:293:12)
npm ERR! gyp ERR! System Windows_NT 10.0.19045
npm ERR! gyp ERR! command "C:\Users\xxx\AppData\Roaming\nvm\v19.0.0\node.exe" "C:\Users\xxx\applications\node\node_modules\node-gyp\bin\node-gyp.js" "rebuild"
npm ERR! gyp ERR! cwd C:\Users\xxx\applications\node\node_modules\bcrypto
npm ERR! gyp ERR! node -v v19.0.0
npm ERR! gyp ERR! node-gyp -v v9.4.0
npm ERR! gyp ERR! not ok

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\xxx\AppData\Local\npm-cache_logs\2023-11-02T18_54_17_595Z-debug-0.log

Fix bogus vs insecure check

I mentioned this in hsd and hnsd as well. Unbound has two variables in the result secure and bogus.

In all cases, if the answer is bogus we should return servfail.
If the answer is secure add the Authenticated Data (AD) bit.
If the answer is not secure set the Authenticated Data (AD) bit to false.

bogus indicates a security failure which means that the result shouldn't be trusted. This allows us to do authenticated denial of existence.

One thing that's nice to have but not necessary is that if the CD bit is set (checking disabled) in the question we probably shouldn't do anything about this and return the bogus result (but it's not really a big deal since they will get servfail from the validating resolver anyway).

bns-prove: support PKCS 11 for HSM signing

ICANN TLD owners can claim their names on Handshake following the reserved name-claim process. However, TXT records are prohibited in the apex of a TLD zone, so those users will have to use the bns-prove tool to create the DNSSEC proof outside the legacy DNS. The tool currently requires direct access to the ZSK and KSK:

From https://hsd-dev.org/guides/claims.html:

The private keys themselves must be stored in BIND’s private key format (v1.3) and naming convention.

This poses a problem to TLD owners who use secure hardware to sign DNSSEC messages.

One solution could be adding two additional functions to bns-prove:

Format the claim TXT record in such a way that HSMs can sign it. This may be unnecessary since the HSM operator likely already has a process in place for signing DNS records with the machine. Formatting the TXT signing request with PKCS11 may refine this process.
Combine the signed TXT as returned by the HSM into the root of the DNSSEC proof so the Handshake claim transaction can be completed and submitted to the network.

TypeError: Server is not a constructor

Using your example 'Base Server', throws an error because the Server ist not a constructor.

OS: Arch Linux (lts-kernel 5.4), Windows 10 Home
NodeJS: v15.3.0

Should Authoritative Nameserver refer non-zone queries to the root zone?

Running a few bns nameservers now for Handshake domains, I've been hit by multiple Amplification Attacks

I think in AuthNS mode (with recursion off a.k.a. this.ra: false), the server should either not reply at all, or reply as minimally as possible.

Examples

Querying local `bns` `AuthNS`

$ dig @127.0.0.1 -p 5300 myzonewd

; <<>> DiG 9.14.6 <<>> @127.0.0.1 -p 5300 myzonewd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15969
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;myzonewd.			IN	A

;; AUTHORITY SECTION:
.			3600000	IN	NS	a.root-servers.net.
.			3600000	IN	NS	b.root-servers.net.
.			3600000	IN	NS	c.root-servers.net.
.			3600000	IN	NS	d.root-servers.net.
.			3600000	IN	NS	e.root-servers.net.
.			3600000	IN	NS	f.root-servers.net.
.			3600000	IN	NS	g.root-servers.net.
.			3600000	IN	NS	h.root-servers.net.
.			3600000	IN	NS	i.root-servers.net.
.			3600000	IN	NS	j.root-servers.net.
.			3600000	IN	NS	k.root-servers.net.
.			3600000	IN	NS	l.root-servers.net.
.			3600000	IN	NS	m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	3600000	IN	A	198.41.0.4
a.root-servers.net.	3600000	IN	AAAA	2001:503:ba3e::2:30
b.root-servers.net.	3600000	IN	A	199.9.14.201
b.root-servers.net.	3600000	IN	AAAA	2001:500:200::b
c.root-servers.net.	3600000	IN	A	192.33.4.12
c.root-servers.net.	3600000	IN	AAAA	2001:500:2::c
d.root-servers.net.	3600000	IN	A	199.7.91.13
d.root-servers.net.	3600000	IN	AAAA	2001:500:2d::d
e.root-servers.net.	3600000	IN	A	192.203.230.10
e.root-servers.net.	3600000	IN	AAAA	2001:500:a8::e
f.root-servers.net.	3600000	IN	A	192.5.5.241
f.root-servers.net.	3600000	IN	AAAA	2001:500:2f::f
g.root-servers.net.	3600000	IN	A	192.112.36.4
g.root-servers.net.	3600000	IN	AAAA	2001:500:12::d0d
h.root-servers.net.	3600000	IN	A	198.97.190.53
h.root-servers.net.	3600000	IN	AAAA	2001:500:1::53
i.root-servers.net.	3600000	IN	A	192.36.148.17
i.root-servers.net.	3600000	IN	AAAA	2001:7fe::53
j.root-servers.net.	3600000	IN	A	192.58.128.30
j.root-servers.net.	3600000	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	3600000	IN	A	193.0.14.129
k.root-servers.net.	3600000	IN	AAAA	2001:7fd::1
l.root-servers.net.	3600000	IN	A	199.7.83.42
l.root-servers.net.	3600000	IN	AAAA	2001:500:9f::42
m.root-servers.net.	3600000	IN	A	202.12.27.33
m.root-servers.net.	3600000	IN	AAAA	2001:dc3::35

;; Query time: 4 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1)
;; WHEN: Mon Apr 27 12:43:45 EDT 2020
;; MSG SIZE  rcvd: 820

Querying a CSC Global nameserver

$dig @156.154.130.100 iwefjwoiefjowief.oweifjowiejfoiwjef

; <<>> DiG 9.14.6 <<>> @156.154.130.100 iwefjwoiefjowief.oweifjowiejfoiwjef
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48484
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;iwefjwoiefjowief.oweifjowiejfoiwjef. IN	A

;; Query time: 8 msec
;; SERVER: 156.154.130.100#53(156.154.130.100)
;; WHEN: Mon Apr 27 12:43:21 EDT 2020
;; MSG SIZE  rcvd: 53

Root zone NSEC should be returned for missing DS in zone, not NS referral

See handshake-org/hsd#291 (comment)

Longer discussion went down on telegram but heres some important quotes:

DS is wierd
it belongs to the parent zone
so its the parent zone that needs to proove it doesn't exist

HNS root returns referral if DS is missing

(--ns-port=5300)

$ dig js ds +dnssec @127.0.0.1 -p 5300

; <<>> DiG 9.16.1-Ubuntu <<>> js ds +dnssec @127.0.0.1 -p 5300
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56349
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;js.				IN	DS

;; AUTHORITY SECTION:
js.			21600	IN	NS	ns2.nameserver.io.
js.			21600	IN	NS	ns1.nameserver.io.
js.			21600	IN	NS	ns3.nameserver.io.
js.			21600	IN	NS	ns4.nameserver.io.
js.			10800	IN	RRSIG	NS 13 1 21600 20210626153707 20200625153707 60944 . whxQmC/AXf90C/xY+z2kfUKRMpgIgxfMiVYB/HuzdrAon7Cf6xTRVzai P7jOdrn9unHpABmViJ+xK7k4Kbsatw==

;; SIG0 PSEUDOSECTION:
.			0	ANY	SIG	0 253 0 0 20200626213707 20200626093707 27687 . Kb1AOc4Jfyl2qXW3QgCjhfuVIBwXzVYTqCOtQRs2799yvNnat6hDqsD4 /Q9yrYYganNHLFfI1lYRbaGtoqL8Kg==

;; Query time: 184 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1)
;; WHEN: Fri Jun 26 11:37:07 EDT 2020
;; MSG SIZE  rcvd: 305

Legacy DNS root returns NSEC from root if DS is missing

$ dig zw ds +dnssec @e.root-servers.net

; <<>> DiG 9.16.1-Ubuntu <<>> zw ds +dnssec @e.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48613
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;zw.				IN	DS

;; AUTHORITY SECTION:
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2020062600 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20200709050000 20200626040000 48903 . ZYoQbgv4WW1+/saL6BPSJjEpo3Ci7SFTgyK1AlRO62pogyJavdy+3U5e 5SXfT/ZWvj1wlFzz+I+fw093WOTwSs2zsqIRACzM0H4LfLJ8T6Fcltdi sHoLwWFPByWoMolOhRj2TvONrJZIld6DsbqPfpVzfZ3BKVNZ2V+tJF8q 5Hdxpn1uDwUndQcu58pzQ9sY0R0LTZJAIlRqQEai2HrvWgXXzuXzARkb KbdnBMi+JCYZMSisNxn/VHwAW6mYMmSufaPZ5CmpKCCNvgMMqzCorE1h VAPdsKsLnq5+UQmb114EhbE920yqEMHQpGI78a3gCPdHhun1IXkd9etC c758AQ==
zw.			86400	IN	NSEC	. NS RRSIG NSEC
zw.			86400	IN	RRSIG	NSEC 8 1 86400 20200709050000 20200626040000 48903 . XNkyjdhGGspX4ZgdqndU9YSWRs8ovA+QTraldzMvVfuUKfQ5yu5Jq9MG 12vxe0RwBzqZEWMfqQMS7Z9Nto0o2eqYl0d0UpE913kKiec4go7AthKS NSPp3t78y7r5Dd/K5cJnGxEHuI2Jvbms5DoZ6tVI5FvN+PHiFx6vmILb d+DErt/PkdnBR/SgmSQw8o0OoA3yGMTPX8D8R/Ocf7dLaDep7oiMdImo fFxbelB+imC/d7QI1K+K6EGfXOHuSNNhVY1voUGkUzQeIeWj+28QCSRz 8Ypm83G1UJK0uyfvfK2jAnqrT2jppy0F8CTyoeemQNvTL8xSBwcVfqSe v5sWyA==

;; Query time: 16 msec
;; SERVER: 192.203.230.10#53(192.203.230.10)
;; WHEN: Fri Jun 26 11:37:37 EDT 2020
;; MSG SIZE  rcvd: 700

More stuff to look in to:

i've not checked all the proofs, some may not mattter, as this is a delegation-only domain
there are lots of places that use all sorts of different resolver s/w - using a machanism that conforms the RFC would mean any could work
there are five different basic proofs, two only apply to wildcard records - so apart from NXDOMAIN & NODATA there is "unsigned referral" (no DS record)
for NXDOMAIN you also need to prove there is no wildcard record that could have matched
ADD_NEXT_CLOSER|ADD_CLOSEST_ENCLOSER|ADD_NEXT_CLOSER_WILDCARD <- these are the NXDOMAIN proofs required
NODATA is just ADD_MY_NSEC
PROOF_NSEC_UNSIGNED_REFERRAL is ADD_NEXT_CLOSER|ADD_CLOSEST_ENCLOSER

DNSSEC Algorithm=4 should be `Reserved` not `ECC` (very minor change)

https://github.com/chjj/bns/blob/master/lib/constants.js#L521
https://github.com/chjj/bns/blob/master/lib/constants.js#L548
https://github.com/chjj/bns/blob/master/lib/internal/keys.js#L477

According to IANA alg=4 is Reserved, like 9 & 11 - so should be treated as not suitable for end-user use.

https://www.rfc-editor.org/rfc/rfc6725.html
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

I'm not exactly clear why RFC6725 is still "proposed" since 2012 - but the status of 9 & 11 where changed at the same time, so these three alg numbers should really be treated the same.

bind & all bind utilities will not work with zone data that had been allowed to have alg=4 in a DS record - it fails with incredibly unfriendly messages & took me ages to track down.

mgar. in the Handshake ROOT zone has been allowed to have alg=4, which means the Handshake ROOT AXFR now no longer works with bind.

How do wildcards in zones work?

Wildcards do not appear to be mapped by name in Zone. When resolving abc.example.com, it seems to return *.x.com as well.

There is also no check for duplicate objects in both the recordset or name set.

Missing support for `ZONEMD`

https://www.rfc-editor.org/rfc/rfc8976.html

Recursive Resolver returns TXT records from HNS root zone even if NS record is present

Running an hsd full node, this bug can be toggled on and off by using unbound's resolver instead.

Example:

On-chain resource:

$ hsd-rpc getnameresource kiba_gateaux
{
  "records": [
    {
      "type": "GLUE4",
      "ns": "ns1.kiba_gateaux.",
      "address": "44.231.6.183"
    },
    {
      "type": "NS",
      "ns": "ns1.kiba_gateaux."
    },
    {
      "type": "TXT",
      "txt": [
        "fAi/2CG3ZOp0zVogpD/rkA8DkMgpFjwShfspJhujL1BOm"
      ]
    },
    {
      "type": "TXT",
      "txt": [
        "fApXxmmBOlxD0soZapm5fUZ+cNm3DEtc6hAf3qlrv65Aq"
      ]
    }
  ]
}

Unbound

hsd

--> dig @127.0.0.1 -p 5350 kiba_gateaux txt

; <<>> DiG 9.16.3 <<>> @127.0.0.1 -p 5350 kiba_gateaux txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35434
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: daf70b0df009336e (echoed)
;; QUESTION SECTION:
;kiba_gateaux.                  IN      TXT

;; AUTHORITY SECTION:
kiba_gateaux.           3600    IN      SOA     a.misconfigured.powerdns.server. hostmaster.kiba_gateaux. 2020103002 10800 3600 604800 3600

;; SIG0 PSEUDOSECTION:
.                       0       ANY     SIG     0 253 0 0 20210106224327 20210106104327 15350 . FUhEtST8OCVWk0g56D7GQwdEya4G7CaHXUvh2om5dvVDr8aGT6SpI1tQ GLXnyh6VIy99kg3Y+Kc6e5tHv5VF0Q==

;; Query time: 543 msec
;; SERVER: 127.0.0.1#5350(127.0.0.1)
;; WHEN: Wed Jan 06 11:43:27 EST 2021
;; MSG SIZE  rcvd: 225

BNS

hsd --rs-no-unbound


--> dig @127.0.0.1 -p 5350 kiba_gateaux txt

; <<>> DiG 9.16.3 <<>> @127.0.0.1 -p 5350 kiba_gateaux txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23597
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5a698d897bd4b209 (echoed)
;; QUESTION SECTION:
;kiba_gateaux.                  IN      TXT

;; ANSWER SECTION:
kiba_gateaux.           21600   IN      TXT     "fAi/2CG3ZOp0zVogpD/rkA8DkMgpFjwShfspJhujL1BOm"
kiba_gateaux.           21600   IN      TXT     "fApXxmmBOlxD0soZapm5fUZ+cNm3DEtc6hAf3qlrv65Aq"

;; SIG0 PSEUDOSECTION:
.                       0       ANY     SIG     0 253 0 0 20210106224315 20210106104315 15350 . qMDd3WBUpH/Qc2CHACOpzgn+pDQJ9tp8s/rMObUISf0br55y5yrd4uAl RinvDIDF95nGXQdb8IKzExIW6aXFBw==

;; Query time: 86 msec
;; SERVER: 127.0.0.1#5350(127.0.0.1)
;; WHEN: Wed Jan 06 11:43:15 EST 2021
;; MSG SIZE  rcvd: 263

Allow AuthNS to host mulitple zones

I'm pretty sure this is something BIND can do - if I want to run a service where users can delegate their NS to me and I am authoritative over multiple zones.

With bns, an AuthNS can only have one zone:

bns/lib/server/auth.js

Line 20 in 03b0ea5

this.zone = new Zone();

I may explore a solution that serves an array of zones

Recursive resolver not setting `ad` bit -- unbound does.

There's going to be a lot of logs in this post. In summary, running hsd with --rs-no-unbound fails to verify the subdomain sebastian.rasor whereas the unbound resolver does verify it:

Invalid RRSIGs.

Queries

--rs-no-unbound

--> dig @127.0.0.1 -p 5350 sebastian.rasor +dnssec

; <<>> DiG 9.16.10 <<>> @127.0.0.1 -p 5350 sebastian.rasor +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45053
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 1743cb239b9132f9 (echoed)
;; QUESTION SECTION:
;sebastian.rasor.               IN      A

;; ANSWER SECTION:
sebastian.rasor.        300     IN      A       45.77.111.169
sebastian.rasor.        300     IN      RRSIG   A 8 2 300 20210311024641 20210209024641 3381 sebastian.rasor. Ipwqf6t2UuDuR2ygVidSiWCXvK6XB/D9AzWv0AFIzGEvd7iQaItOa1tm uXUK9DWtMwClZfBbxl10c3hMhdFZgHLWkXRCLiWgOcPlKyOekMFf+Dh8 zElNS6UEji5NV7vP2FCYbzAhweEsIJE28v9ofhHOZSVGsaRpQDeXnAif 5IEeFzA666QUE61xkShkTFOcrjwhdlq074lXpIOP2PyUBCK8ESwdn/kp 8ZFj5VCDgyHf9nTsfmSIpKYaL/s1jts6mRZhMCFlXGtRnE+ocj9LsGWa Ds6y8TKVDf3ZYPls17xgiBsTybL5PYkJgZzRrrc78F7avr7oa0mhxtZn qYAjvQ==

;; SIG0 PSEUDOSECTION:
.                       0       ANY     SIG     0 253 0 0 20210209101345 20210208221345 15350 . +zVVjI0QbVXeRCY/ojd0tx+Ekkof4o+OCWLDHfD4h1MWjVC3It5+ItJL ZN1NeGA/iW7RjcCUVlCOfjX1UKESzQ==

;; Query time: 69 msec
;; SERVER: 127.0.0.1#5350(127.0.0.1)
;; WHEN: Mon Feb 08 23:13:45 EST 2021
;; MSG SIZE  rcvd: 454

with unbound

--> dig @127.0.0.1 -p 5350 sebastian.rasor +dnssec

; <<>> DiG 9.16.10 <<>> @127.0.0.1 -p 5350 sebastian.rasor +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 182
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: d46ce3a95f53a17f (echoed)
;; QUESTION SECTION:
;sebastian.rasor.               IN      A

;; ANSWER SECTION:
sebastian.rasor.        300     IN      A       45.77.111.169
sebastian.rasor.        300     IN      RRSIG   A 8 2 300 20210311024641 20210209024641 3381 sebastian.rasor. Ipwqf6t2UuDuR2ygVidSiWCXvK6XB/D9AzWv0AFIzGEvd7iQaItOa1tm uXUK9DWtMwClZfBbxl10c3hMhdFZgHLWkXRCLiWgOcPlKyOekMFf+Dh8 zElNS6UEji5NV7vP2FCYbzAhweEsIJE28v9ofhHOZSVGsaRpQDeXnAif 5IEeFzA666QUE61xkShkTFOcrjwhdlq074lXpIOP2PyUBCK8ESwdn/kp 8ZFj5VCDgyHf9nTsfmSIpKYaL/s1jts6mRZhMCFlXGtRnE+ocj9LsGWa Ds6y8TKVDf3ZYPls17xgiBsTybL5PYkJgZzRrrc78F7avr7oa0mhxtZn qYAjvQ==

;; SIG0 PSEUDOSECTION:
.                       0       ANY     SIG     0 253 0 0 20210209101400 20210208221400 15350 . DIfBb2KgnM0zFbZG2EtY3e/w73Cj7ktlqC4+iwZYDdBibg0FqJ7BR3V0 6v/On4WDWl7Z/4DdoYtkuKc6omKt9A==

;; Query time: 95 msec
;; SERVER: 127.0.0.1#5350(127.0.0.1)
;; WHEN: Mon Feb 08 23:14:00 EST 2021
;; MSG SIZE  rcvd: 454

Logs --rs-no-unbound

[D:2021-02-09T04:13:45Z] (rs) Querying sebastian.rasor. (A).
[D:2021-02-09T04:13:45Z] (rs) Switching authority: hints.local.
[D:2021-02-09T04:13:45Z] (rs) Switching zone: [.]
[D:2021-02-09T04:13:45Z] (rs) Querying server: 127.0.0.1 (32414) (tcp=false)
[S:2021-02-09T04:13:45Z] (ns) DNS Request:
[S:2021-02-09T04:13:45Z] (ns) ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32414
[S:2021-02-09T04:13:45Z] (ns) ;; flags: ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; OPT PSEUDOSECTION:
[S:2021-02-09T04:13:45Z] (ns) ; EDNS: version: 0, flags: do; udp: 4096
[S:2021-02-09T04:13:45Z] (ns) ;; QUESTION SECTION:
[S:2021-02-09T04:13:45Z] (ns) ;sebastian.rasor. IN A
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; MSG SIZE  rcvd: 44
[S:2021-02-09T04:13:45Z] (ns) DNS Response:
[S:2021-02-09T04:13:45Z] (ns) ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32414
[S:2021-02-09T04:13:45Z] (ns) ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 2
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; OPT PSEUDOSECTION:
[S:2021-02-09T04:13:45Z] (ns) ; EDNS: version: 0, flags: do; udp: 4096
[S:2021-02-09T04:13:45Z] (ns) ;; QUESTION SECTION:
[S:2021-02-09T04:13:45Z] (ns) ;sebastian.rasor. IN A
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; AUTHORITY SECTION:
[S:2021-02-09T04:13:45Z] (ns) rasor. 21600 IN NS ns1.rasor.
[S:2021-02-09T04:13:45Z] (ns) rasor. 21600 IN DS 28654 8 2 8C5D881B7650C12FDB10BB9A6FAE3BF51DF47961F68D003EE17AA8E7 9F22BF83  ; alg = RSASHA256 ; hash = SHA256
[S:2021-02-09T04:13:45Z] (ns) rasor. 10800 IN RRSIG DS 13 1 21600 20220209041345 20210208041345 60944 . UmHpuZ/4RyvRziwNBHzDgXBSeHWWMDEIYRLp9emtiH1dsdwVd3iAmABk LCExWf6qm9Fsj9vimhhrNW20m79zTA==  ; alg = ECDSAP256SHA256
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; ADDITIONAL SECTION:
[S:2021-02-09T04:13:45Z] (ns) ns1.rasor. 21600 IN A 45.77.111.169
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; MSG SIZE  rcvd: 250
[D:2021-02-09T04:13:45Z] (rs) Verifying zone change to [.]
[D:2021-02-09T04:13:45Z] (rs) Checking signatures...
[D:2021-02-09T04:13:45Z] (rs) Querying server: 127.0.0.1 (55484) (tcp=false)
[S:2021-02-09T04:13:45Z] (ns) DNS Request:
[S:2021-02-09T04:13:45Z] (ns) ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55484
[S:2021-02-09T04:13:45Z] (ns) ;; flags: ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; OPT PSEUDOSECTION:
[S:2021-02-09T04:13:45Z] (ns) ; EDNS: version: 0, flags: do; udp: 4096
[S:2021-02-09T04:13:45Z] (ns) ;; QUESTION SECTION:
[S:2021-02-09T04:13:45Z] (ns) ;. IN DNSKEY
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; MSG SIZE  rcvd: 28
[S:2021-02-09T04:13:45Z] (ns) DNS Response:
[S:2021-02-09T04:13:45Z] (ns) ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55484
[S:2021-02-09T04:13:45Z] (ns) ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; OPT PSEUDOSECTION:
[S:2021-02-09T04:13:45Z] (ns) ; EDNS: version: 0, flags: do; udp: 4096
[S:2021-02-09T04:13:45Z] (ns) ;; QUESTION SECTION:
[S:2021-02-09T04:13:45Z] (ns) ;. IN DNSKEY
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; ANSWER SECTION:
[S:2021-02-09T04:13:45Z] (ns) . 10800 IN DNSKEY 257 3 13 T9cURJ2M/Mz9q6UsZNY+Ospyvj+Uv+tgrrWkLtPQwgU/Xu5Yk0l02Sn5 ua2xAQfEYIzRO6v5iA+BejMeEwNP4Q==  ; KSK ; alg = ECDSAP256SHA256 ; key id = 35215
[S:2021-02-09T04:13:45Z] (ns) . 10800 IN DNSKEY 256 3 13 I5nPs6clFa1gnwn9IpVDGdJLfEONzgD1NcfuEwEIVuIoHdZGgvVblsLN bRO+spW3nQYHg92svhy1HOjTiFBIsQ==  ; ZSK ; alg = ECDSAP256SHA256 ; key id = 60944
[S:2021-02-09T04:13:45Z] (ns) . 10800 IN RRSIG DNSKEY 13 0 10800 20220209041345 20210208041345 35215 . z5XC4Q/6ryOkAcHyGHQ/O5B0sqBuTs73hgHGVh2JqHhomIx6YtrvkPsD czvZYft74nN6PWRC59bDQg9UOwxDJA==  ; alg = ECDSAP256SHA256
[S:2021-02-09T04:13:45Z] (ns) 
[S:2021-02-09T04:13:45Z] (ns) ;; MSG SIZE  rcvd: 280
[D:2021-02-09T04:13:45Z] (rs) Validated DNSSEC signatures.
[D:2021-02-09T04:13:45Z] (rs) Switching authority: ns1.rasor.
[D:2021-02-09T04:13:45Z] (rs) Switching zone: [.->rasor.]
[D:2021-02-09T04:13:45Z] (rs) Querying server: 45.77.111.169 (26868) (tcp=false)
[D:2021-02-09T04:13:45Z] (rs) Verifying zone change to [rasor.]
[D:2021-02-09T04:13:45Z] (rs) Checking signatures...
[D:2021-02-09T04:13:45Z] (rs) Querying server: 45.77.111.169 (18276) (tcp=false)
[D:2021-02-09T04:13:45Z] (rs) Invalid RRSIGs.
[D:2021-02-09T04:13:45Z] (rs) Trust chain broken due to lack of child verification.
[D:2021-02-09T04:13:45Z] (rs) Traversed zones: ., rasor. for sebastian.rasor. (A).
[D:2021-02-09T04:13:45Z] (rs) Finishing resolving sebastian.rasor. (A) (hops=1).

Zone management guides

Docs or README examples on using bns-keygen and bns-prove would be helpful, as Handshake users start registering names and spin up nameservers.

	const rr = item.deepClone();
	const labels = splitName(rr.name);

	// Server is using wildcards.
	if (labels.length > sd.labels) {
	const i = labels.length - sd.labels;
	const name = labels.slice(i).join('.');
	rr.name = `*.${name}.`;
	}

	const name = rrset[0].name;

	for (let i = 1; i < rrset.length; i++) {
	const rr = rrset[i];

	if (rr.type !== type
	\|\| rr.class !== class_
	\|\| !util.equal(rr.name, name)) {
	return false;
	}