buffrr / hsd-axfr Goto Github PK

View Code? Open in Web Editor NEW

10.0 10.0 2.0 16 KB

HSD plugin that implements DNS zone transfer protocol (AXFR)

JavaScript 100.00%

hsd-axfr's People

Contributors

Stargazers

Watchers

Forkers

miguelgargallo james-stevens

hsd-axfr's Issues

One last error I can't get rid of :)

In bind I've disabled IXFR, DNS Cookies & EDNS, but I'm still left with one error in hsd when bind pulls an AXFR

I have no idea in the cycle when it occurs. bind will usually poll the SOA Serial over UDP before deciding to do an AXFR.

Nov 27 14:00:43 hasroot user.notice hsd: [error] (ns) EFORMERR: unexpected authority.
Nov 27 14:00:43 hasroot user.notice hsd:     at RootServer.answer (/usr/local/hsd/node_modules/bns/lib/server/dns.js:242:13)
Nov 27 14:00:43 hasroot user.notice hsd:     at RootServer.handle (/usr/local/hsd/node_modules/bns/lib/server/dns.js:316:24)
Nov 27 14:00:43 hasroot user.notice hsd:     at Server.<anonymous> (/usr/local/hsd/node_modules/bns/lib/server/dns.js:72:20)
Nov 27 14:00:43 hasroot user.notice hsd:     at Server.emit (events.js:400:28)
Nov 27 14:00:43 hasroot user.notice hsd:     at TCPSocket.fire (/usr/local/hsd/node_modules/bns/lib/internal/net.js:350:17)
Nov 27 14:00:43 hasroot user.notice hsd:     at Parser.<anonymous> (/usr/local/hsd/node_modules/bns/lib/internal/net.js:365:12)
Nov 27 14:00:43 hasroot user.notice hsd:     at Parser.emit (events.js:400:28)
Nov 27 14:00:43 hasroot user.notice hsd:     at Parser.feed (/usr/local/hsd/node_modules/bns/lib/internal/net.js:574:12)
Nov 27 14:00:43 hasroot user.notice hsd:     at Socket.<anonymous> (/usr/local/hsd/node_modules/bns/lib/internal/net.js:396:19)
Nov 27 14:00:43 hasroot user.notice hsd:     at Socket.emit (events.js:400:28)
Nov 27 14:03:27 hasroot user.notice hsd: [warning] (axfr) name collision for xn--cckwcxetd. (prefer icann: true)
Nov 27 14:03:51 hasroot user.notice hsd: [warning] (axfr) name collision for music. (prefer icann: true)
Nov 27 14:05:40 hasroot user.notice hsd: [warning] (axfr) name collision for xn--jlq480n2rg. (prefer icann: true)
Nov 27 14:06:13 hasroot user.notice hsd: [warning] (axfr) name collision for xn--4dbrk0ce. (prefer icann: true)

Here's the relevant options I added - might be useful to anybody else if they're interested in this kind of thing :)

options {
...
        check-names master ignore;
        check-names slave ignore;
        check-names response ignore;
        check-sibling no;
        check-integrity no;

        request-ixfr no;
        send-cookie no;
        answer-cookie no;
        require-server-cookie no;
...
        };

server 127.0.0.9 { edns no; };

There's absolutely no need for the AXFR from hsd to support any of these, so I'm more than happy to disable then all, but (as you know) I do think the hsd resolver really should support DNS Cookies.

BTW: 127.0.0.9 is my hsd instance.

exec /usr/local/hsd/bin/hsd \
        --plugins=/usr/local/hsd/axfr \
        --axfr-icann-servers='127.1.0.1' \
        --axfr-prefer-icann \
        --prefix=/ext/hsd-data/ \
        --ns-host 127.0.0.9 \
        --ns-port 53 \
        --no-sig0 \
        --log-level=${log} 2>&1 | logger -t hsd

AXFR is broken :(

After months of faultless operation - the AXFR has broken

Jul  6 13:34:53 hasroot user.notice hsd: [warning] (axfr) name collision for wiki. (prefer icann: true)
Jul  6 13:38:21 hasroot user.notice hsd: [warning] (axfr) Name hotonlyfans. uses unsupported serialization format - skipping

the last name that comes out is this

ns2.xn--9h8hy3b.        21600   IN      A       54.214.136.246
benhc.                  21600   IN      NS      ns1.benhc.
benhc.                  21600   IN      NS      ns2.benhc.
ns1.benhc.              21600   IN      A       44.231.6.183
ns2.benhc.              21600   IN      A       54.214.136.246
xn--zqsz0jk9vinb.       21600   IN      NS      ns1.xn--zqsz0jk9vinb.
xn--zqsz0jk9vinb.       21600   IN      NS      ns2.xn--zqsz0jk9vinb.
ns1.xn--zqsz0jk9vinb.   21600   IN      A       44.231.6.183
ns2.xn--zqsz0jk9vinb.   21600   IN      A       54.214.136.246
klostermann.            21600   IN      NS      ns1.kloste<no-end-of-line>

Fake IPv4 / IPv6 record is not included in AXFR

If you request the NS for . (from hns) a fake IPv4 address (for the NS hostname) is returned, this is not included in an AXFR of the zone, which causes bind to reject the zone.

$ dig @127.0.0.9 . ns

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

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

;; ANSWER SECTION:
.                       518400  IN      NS      _fs00028._synth.

;; ADDITIONAL SECTION:
_fs00028._synth.        518400  IN      A       127.0.0.9

;; Query time: 0 msec
;; SERVER: 127.0.0.9#53(127.0.0.9)
;; WHEN: Fri Nov 12 17:59:22 UTC 2021
;; MSG SIZE  rcvd: 72

... but ....

$ dig @127.0.0.9 . axfr > /tmp/hns
$ grep _fs00028._synth /tmp/hns
.                       518400  IN      NS      _fs00028._synth.
$

This causes bind to reject the zone

Nov 12 17:40:21 hasroot local0.err named-handshake-bridge[4407]: zone ./IN (signed): NS '_fs00028._synth' has no address records (A or AAAA)
Nov 12 17:40:21 hasroot local0.err named-handshake-bridge[4407]: zone ./IN (signed): not loaded due to errors.
Nov 12 17:40:21 hasroot local0.err named-handshake-bridge[4407]: zone ./IN (signed): receive_secure_db: bad zone
Nov 12 17:40:22 hasroot local0.err named-handshake-bridge[4407]: zone ./IN (signed): receive_secure_serial: failure

I'm actually very confused, cos I've not upgraded either hsd or bind since the time when it was working, so I have no idea why this has now stopped working ?!?!?!?!

Sep 16 12:15:13 hasroot daemon.notice named-handshake-bridge[974]: starting BIND 9.16.20 (Extended Support Version) <id:26db37f>
Sep 17 15:26:46 hasroot daemon.notice named-handshake-bridge[4550]: starting BIND 9.16.20 (Extended Support Version) <id:26db37f>
Oct 20 15:58:29 hasroot daemon.notice named-handshake-bridge[8015]: starting BIND 9.16.20 (Extended Support Version) <id:26db37f>
Oct 20 16:04:09 hasroot local0.err named-handshake-bridge[8015]: zone ./IN (signed): NS '_fs00028._synth' has no address records (A or AAAA)
Nov 12 17:31:48 hasroot daemon.notice named-handshake-bridge[4361]: starting BIND 9.16.20 (Extended Support Version) <id:26db37f>
Nov 12 17:32:28 hasroot local0.err named-handshake-bridge[4361]: zone ./IN (signed): NS '_fs00028._synth' has no address records (A or AAAA)
Nov 12 17:33:58 hasroot daemon.notice named-handshake-bridge[4407]: starting BIND 9.16.20 (Extended Support Version) <id:26db37f>
Nov 12 17:40:21 hasroot local0.err named-handshake-bridge[4407]: zone ./IN (signed): NS '_fs00028._synth' has no address records (A or AAAA)

Here you can see v9.16.20 both working fine & not working !!!!

Despite having ...

        check-names master ignore;
        check-names slave ignore;
        check-names response ignore;
        check-sibling no;
        check-integrity no;

Support NOTIFY and change SOA serial

The plugin should give a consistent SOA serial across multiple hsd instances.

I'm thinking the serial should be:

serial = floor(block height / 36)

So every zone version reflects a snapshot of the urkel tree. For example, if the block height = 90000, the SOA serial would be 2500.

Chain Reorgs problem:

If there is a reorg the exact same serial may give two different zones!! So the plugin should store the zone file and wait a few more blocks for confirmation BEFORE sending NOTIFY or updating SOA.

Example:

Block height = 90000
Current SOA serial = 2499, zone file stored 2499.zone (published)
Next SOA serial = 2500, zone file stored 2500.zone (inactive)

After maybe 12 confirmations/blocks

Block height = 90012
old SOA serial= 2499, zone file stored 2499.zone (removed)
Current SOA serial = 2500, zone file stored 2500.zone (published)

This solution requires the plugin to store two zones internally to keep SOA serial consistent and increasing order.

Got this error when `hsd` gets an AXFR request from ISC's `bind`

[info] (net) Received 16 addrs (hosts=205, peers=8) (40.113.229.250:12038).
[error] (ns) Out of bounds read (offset=32).
    at BufferReader.readU32BE (/opt/hsd-orig/node_modules/bufio/lib/reader.js:256:10)
    at EXPIREOption.read (/opt/hsd-orig/node_modules/bns/lib/wire.js:5825:22)
    at Function.read (/opt/hsd-orig/node_modules/bufio/lib/struct.js:143:23)
    at readOption (/opt/hsd-orig/node_modules/bns/lib/wire.js:6620:27)
    at Option.read (/opt/hsd-orig/node_modules/bns/lib/wire.js:5441:19)
    at Function.read (/opt/hsd-orig/node_modules/bufio/lib/struct.js:143:23)
    at OPTRecord.read (/opt/hsd-orig/node_modules/bns/lib/wire.js:3788:32)
    at Function.read (/opt/hsd-orig/node_modules/bufio/lib/struct.js:143:23)
    at readData (/opt/hsd-orig/node_modules/bns/lib/wire.js:6513:24)
    at Record.read (/opt/hsd-orig/node_modules/bns/lib/wire.js:1885:17)
[info] (axfr) [127.0.0.1:47597]  Starting zone transfer

My guess would be bind is sending some extra records at the end of the AXFR request, like an EDNS0 or DNS Cookie or something. The transfer then seems to start fine - but its ducking slow as heck, so still waiting for it to complete.

BTW: would be REALLY nice if the SOA Serial reflected the version of the data, instead of just giving the current date & time - that way I could run two copies of hsd and pull the zone file from either & if one had been down and was still catching up, bind wouldn't end up pulling stale data from it.

If you are pulling the AXFR from the frozen data, instead of the live data (this is the preferred choice but sorry, I don't know your terminology for these two data sets), the SOA Serial should reflect the "version" of the frozen data, e.g. the unix timestamp of the last packet that got included or something.

Conflict between `hsd` and the DNS RFCs

There is a conflict between the way hsd and an RFC DNS server treats the status of record in the blockchain / ROOT Zone. Obviously, by the time I've used this plug-in to pull the records out, they are no longer in the blockchain, as such.

Namebase set up all their TLDs like this

handshake.              21600   IN      NS      ns1.handshake.
ns1.handshake.          21600   IN      A       44.231.6.183

I have no idea why they didn't use a single NS for all of them, like ns1.namebase, or simply give all of them either a single CNAME or single IPv4, there is really no need to delegate them at all, but hey - it is what it is.

hsd will treat these records as authoritative & resolve the domain fine. However, bind will (correctly) treat these both as GLUE records and re-query for them from the authoritative source - in this case 44.231.6.183.

Namebase's mistake is that, according to 44.231.6.183, not only does ns1.handshake not exist, but also handshake also has no NS records. Therefore, correctly bind will not resolve this domain, however hsd will.

In a way this is a philosophical question as to the status of the records in the blockchain, but from an RFC DNS point of view, when a subdomain is delegated, it's the delegated NS that are the authoritative source of truth (AA=1) & all records (except the DS) in the parent zone are treated as GLUE records - "hearsay". You can't really have two different authoritative sources of truth, becuase they could give different answers.

However, if hsd was "fixed" to be RFC compliant, all namebase helds TLDs (except those staked & delegated to the registry) will almost certainly stop working - so at least 99% of Handshake TLDs.

My guess would be that unbound using the light-client plug-in would behave the same as bind, unless the light client tags the blockchain records as AA=1. It would be interesting to know.

I reported this issue to namebase, but the person who responded gave the response that they didn't understand what was being reported.

When I use the term "correctly", I only mean "as per the DNS RFCs", not as any kind of moral judgement.

buffrr / hsd-axfr Goto Github PK

hsd-axfr's People

Contributors

Stargazers

Watchers

Forkers

hsd-axfr's Issues

One last error I can't get rid of :)

AXFR is broken :(

Fake IPv4 / IPv6 record is not included in AXFR

Support NOTIFY and change SOA serial

Got this error when `hsd` gets an AXFR request from ISC's `bind`

Conflict between `hsd` and the DNS RFCs

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent