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
Hello!
I have an issue.
Knot is configured as a secondary server, and when receiving a zone, a
"trailing data" error occurs, preventing the zone from being loaded from
the primary server.
```
Jan 30 11:03:40 hostname knotd[5407]: info: [domain.com.] refresh, remote
50788646-db98-4caa-b26e-95b30a470796, address 1.2.3.4@53, failed (trailing
data)
```
The same warning appears when using the `kdig` utility:
```bash
kdig @1.2.3.4 domain.com AXFR > /tmp/domain.com
;; WARNING: malformed reply packet (trailing data)
;; WARNING: malformed reply packet (trailing data)
```
The issue occurs specifically with large zones. If the zone requires 2
messages to be received (e.g., `Received 32720 B (2 messages, 442
records)`), one warning appears. If it requires 3 messages (e.g., `Received
49083 B (3 messages, 878 records)`), two warnings appear.
However, if I place this zone (`/tmp/domain.com`) into `/var/lib/knot` and
then execute:
```bash
knotc reload
knotc zone-refresh domain.com
```
Knot successfully loads the zone.
Unfortunately, due to confidentiality, I cannot share the contents of the
zone. Additionally, I do not have precise information about the software
installed on the primary server. However, if BIND is used as the secondary
server, there are no issues. A regular `dig` command also does not return
any errors.
Is there any way to make Knot ignore the "trailing data" error and
successfully load the zone?
Thank you for your help!
Hello,
I have an issue with a behaviour change in knot 3.4.1.
Before 3.4.1, trying to send a conf-abort command using knotc to knot when there was no pending transaction properly returned an error, but since 3.4.1, instead of receiving an error, the connection hangs, and failed after a timeout.
Some digging shows that this is due to a change in commit 69328dd7799253978605f7dac29175945971e63f
Instead of returning and error as it should, ctl_process skip the command processing when it does not expect a conf-abort command.
Is this a bug, or is this behaviour intended ?
Just to give you some context about my use case, I wrote a daemon that is using libknot to sync the dns configuration, and as knot does not supports multiple transaction, it has to make sure there is no dangling transaction before trying to apply changes (in case the daemon did crash while applying a previous change). Until 3.4.1, it did that by simply sending a conf-abort before starting the new transaction.
Thanks
Hi Guys,
a happy new year to all of you!
Due to policy reasons we need to make knot use a HSM in the future. Is
anybody successfully using some cloud based HSM services like Google
Cloud HSM for DNSSEC signing?
Any information is helpful, thanks!
BR
Thomas
