I am testing IXFR for servers I did not install nor have easy access
to. version.server. says it is 3.2.6. I know there are IXFR changes
since then per the NEWS file and from git log. I don't see same
behavior on my different version different systems but they are also
configured differently.
The knot.conf zones are not configured with "zonefile-load: difference"
and the response effectively has the entire zone as if was AXFR and not
the changes. If I pass the IXFR SOA SERIAL to latest it has no changes
(answer has has the SOA only with same serial).
I used dnspython to output the response from doing IXFR queries (IXFR
question with SOA authoritative set with the serial in the query). I
noticed the output abruptly stops when "dig" doesn't stop.
So I used tcpdump many times to compare knot, named, and my other knot.
I found an odd behavior in this knot 3.2.6 response which dig ignores
and my dnspython fails.
After the expect record it has
1) OPT record with the requestors pay load size (class 1232) and edns rcode
and flags (all zeros ttl), then 00 rdlength and 00 rdata field.
2) then 28 bytes I don't understand such as:
40 11be dc80 0000 0101 fa00 0000 01
or
40 20be dc80 0000 0102 0300 0000 01
or
40 0fe1 6a81 0000 0102 0500 0000 00
or
12 8de1 6a81 0000 0100 9200 0000 00
3) then an IXFR record
following other labels ...
0363 6f6d 00 three characters "com" and end of domain
00 fb IXFR record type
00 01 INternet class
and then ends there, with NO ttl, rdlength, nor rdata.
4) followed by next label length, label ... etc with rrtype, class, ttl,
rdlength, rdata and so on.
This odd OPT, bytes I don't know, partial/broken IXFR record, may be
repeated a few times. I assume these were interspersed where IXFR's SOA
records should be.
I couldn't find an RFC that suggested using interspersed OPT nor IXFR
records. I find it odd that OPT record is in my ANSWER section.
I find it odd that the IXFR record is incomplete. And I don't know what
the other bytes are in-between.
This recognizable to anyone?
The IXFR works fine as seen with dig or when I use named as my
secondary but I assume the named is ignoring the junk parts too.
Hi Knots,
I use catalog zones to sync the set of zones my (hidden)master and slaves
handle. I'm trying to stop messing with zone files on my master, instead
switching exclusively to nsupdate (along with Tony Finch's nsdiff).
In my testing it seems updating the zone after adding it via a catalog is
not possible:
$ knotc zone-status dxld.at
[dxld.at.] role: master | serial: - | catalog: dxld.catalog. | re-sign: +9D15h6m14s
Yet the update fails:
$ knsupdate -y $SECRET <<EOF
> server ns0.dxld.at.
> zone dxld.at.
> add dxld.at. 3600 IN SOA ns0.dxld.at. hostmaster.dxld.at. 1 2m 5m 1w 5m
> send
update failed: SERVFAIL
Nothing is logged with `logging: any: debug` except a "ACL, allowed, action
update".
As soon as I create the zone on the server with zone{-begin,-set,-commit}
it starts working ofc. I guess this is just not supported, but is there a
good reason? I would find it quite convenient to do all my DNS ops over
port 53 without touching ssh ;-)
Thanks,
--Daniel
