knot-dns-users Únor 2025

knot-dns-users@lists.nic.cz

4 participants
3 discussions

IXFR response has interspersed IXFR and OPT records and more

by Jeremy C. Reed

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.

2 měsíce, 2 týdny

mod-onlinesign: extra DNSKEY causes double signatures

by Peter Thomassen

Hi, Consider a zonefile with @ DNSKEY 257 3 13 ZAtZvaK2/uVw+LG2AA12Dt/ZZ+YN0IF3pFwjfBp8Jd2DXjVU0cdxfpkY StUdbFu24Js6T5uROHo8lSG9rhgduw== and configuration zone: - domain: example.com storage: /config/ file: example.com.zone module: mod-onlinesign -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525

3 měsíce

Dynamic update fails after zone creation via catalog

by Daniel Gröber

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

3 měsíce, 1 týden

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users Únor 2025