2 Srp
2021
2 Srp
'21
16:57
Hi,
We are testing migration from bind to knot, to implement dnssec. We like
many things about knot! Thank you for making it available!
So far many things work, but we do have some uncertainties. Hope they're
not too basic to ask here...
We are using ubuntu, knot 3.1.0, our static bind zone files saved as
/var/lib/knot/zones/db.domain.com and also the non-binary knot config.
(in /etc/knot/knot.conf)
1) I wanted to test the knotc zone-backup command, but we're getting:
error: backup init failed (operation not permitted)
Is the zone-backup command geared towards binary zones? Are our static
zone files the reason this doesn't work? I realise we can simply copy
the zone files, so in our case, the backup command probably adds nothing.
2) I have enabled DNSSEC, and upon restart we saw the keys being
generated, and files appeared under /var/lib/knot/keys
I guess keeping copies of the files there is adequate backup too? No
"knotc zone-backup" required here as well?
3) After each knot restart, we are seeing:
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info:
[1.2.3.4.in-addr.arpa.] DNSSEC, zone is up-to-date
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [1.2.3.4.in-addr.arpa.] loaded,
serial none -> 2017041004, 106139 bytes
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [1.2.3.4.in-addr.arpa.] DNSSEC, next
signing at 2021-08-09T16:10:10+0200
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [domain.com.] DNSSEC, zone is
up-to-date
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [domain.com.] loaded, serial none
-> 2021072903, 183151 bytes
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: info: [domain.com.] DNSSEC, next signing at
2021-08-09T16:10:10+0200
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: warning: [domain.com.] failed to update
zone file (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error: [domain.com.] zone event
'journal flush' failed (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: warning: [1.2.3.4.in-addr.arpa.] failed to
update zone file (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error: [1.2.3.4.in-addr.arpa.] zone event
'journal flush' failed (operation not permitted)
We would like to understand the warnings/errors here too. Why would knot
try to update the zone files, and why it is failing? I have set the
permissions on the zone files 660 / knot:knot so it should be able edit
them. (but again: why would knot want to update them?)
Thanks for any feedback!
MJ
2 Srp
2 Srp
17:23
On 02/08/2021 16:57, mj wrote:
Hi MJ,
By default, Knot flushes zone files to the disk in plain zone file
format. However, I have a suggestion for you. Instead of keeping the
signed zones on disk in zone file format, use Knot's journal. You should
use the following options for your zone, or your default template:
journal-content: all
zonefile-load: differences-no-serial
zonefile-sync: -1
With these settings, Knot will load the unsigned zone from your zone
file on disk. It will sign the zone, and store the file contents of the
zone into its journal. Knot will not touch your unsigned zone on disk.
Whenever you need to change the zone, you can edit the zone file in
/var/lib/knot/db.domain.com, and run:
knotc zone-reload domain.com
Knot will read the zone file, find the differences, re-sign the parts of
the zone that need to be re-signed, and store everything into the
journal. Also note that you don't need to remember to update the serial
number in the SOA record of the zone. Knot will automatically increment
it by one whenever it needs to re-sign the zone, and the correct serial
will be stored in the journal. If you don't like the serial number to be
just incremented, you can use a different policy, by setting
"serial-policy" to either "unixtime" or "dateserial" (this
latter
setting is only useful if your zone doesn't change more than 100 times
in one day).
Regards,
Anand Buddhdev
RIPE NCC
We are testing migration from bind to knot, to
implement dnssec. We like
many things about knot! Thank you for making it available!
This is great! You'll love Knot! I'm not a developer, but I use Knot,
and I can provide some answers.
1) I wanted to test the knotc zone-backup command, but
we're getting:
You should not need to backup your zone files with the "knotc
zone-backup" command. Instead, just do filesystem copy of the files.
error: backup init failed (operation not
permitted)
Is the zone-backup command geared towards binary zones? Are our static
zone files the reason this doesn't work? I realise we can simply copy
the zone files, so in our case, the backup command probably adds nothing. 2) I have enabled DNSSEC, and upon restart we saw the
keys being
generated, and files appeared under /var/lib/knot/keys
I guess keeping copies of the files there is adequate backup too? No
"knotc zone-backup" required here as well?
Yes, you can backup /var/lib/knot/keys, and that should be adequate.
Aug 2
16:44:56 Latitude-E7470 knotd[259063]: warning: [domain.com.]
failed to update zone file (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error: [domain.com.]
zone event 'journal flush' failed (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: warning:
[1.2.3.4.in-addr.arpa.] failed to update zone file (operation not
permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error:
[1.2.3.4.in-addr.arpa.] zone event 'journal flush' failed (operation
not permitted)
We would like to understand the warnings/errors here too. Why would knot
try to update the zone files, and why it is failing? I have set the
permissions on the zone files 660 / knot:knot so it should be able edit
them. (but again: why would knot want to update them?) 
17:38
On 2021-08-02 08:23, Anand Buddhdev wrote:
On 02/08/2021 16:57, mj wrote:
Hi MJ,
By default, Knot flushes zone files to the disk in plain zone file
format. However, I have a suggestion for you. Instead of keeping the
signed zones on disk in zone file format, use Knot's journal. You should
use the following options for your zone, or your default template:
journal-content: all
zonefile-load: differences-no-serial
zonefile-sync: -1
With these settings, Knot will load the unsigned zone from your zone
file on disk. It will sign the zone, and store the file contents of the
zone into its journal. Knot will not touch your unsigned zone on disk.
Whenever you need to change the zone, you can edit the zone file in
/var/lib/knot/db.domain.com, and run:
knotc zone-reload domain.com
Knot will read the zone file, find the differences, re-sign the parts of
the zone that need to be re-signed, and store everything into the
journal. Also note that you don't need to remember to update the serial
number in the SOA record of the zone. Knot will automatically increment
it by one whenever it needs to re-sign the zone, and the correct serial
will be stored in the journal. If you don't like the serial number to be
just incremented, you can use a different policy, by setting
"serial-policy" to either "unixtime" or "dateserial" (this
latter
setting is only useful if your zone doesn't change more than 100 times
in one day).
I would only add to the great advice already given; that if you *do*
find
yourself working with the zone files on disk, and their in sync with
knots journal copy. That you use zone-freeze && zone-thaw as appropriate.
Lastly; the Operation not permitted messages you are receiving, may also
be caused if knot (or whomever knot runs as) doesn't own the
directories/folder that your zones are kept in.
--Chris
We are testing migration from bind to knot, to
implement dnssec. We like
many things about knot! Thank you for making it available!
This is great! You'll love Knot! I'm not a developer, but I use Knot,
and I can provide some answers.
1) I wanted to test the knotc zone-backup
command, but we're getting:
You should not need to backup your zone files with the "knotc
zone-backup" command. Instead, just do filesystem copy of the files.
error: backup init failed (operation not
permitted)
Is the zone-backup command geared towards binary zones? Are our static
zone files the reason this doesn't work? I realise we can simply copy
the zone files, so in our case, the backup command probably adds nothing. 2) I have enabled DNSSEC, and upon restart we saw
the keys being
generated, and files appeared under /var/lib/knot/keys
I guess keeping copies of the files there is adequate backup too? No
"knotc zone-backup" required here as well?
Yes, you can backup /var/lib/knot/keys, and that should be adequate.
Aug 2
16:44:56 Latitude-E7470 knotd[259063]: warning: [domain.com.]
failed to update zone file (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error: [domain.com.]
zone event 'journal flush' failed (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: warning:
[1.2.3.4.in-addr.arpa.] failed to update zone file (operation not
permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error:
[1.2.3.4.in-addr.arpa.] zone event 'journal flush' failed (operation
not permitted)
We would like to understand the warnings/errors here too. Why would knot
try to update the zone files, and why it is failing? I have set the
permissions on the zone files 660 / knot:knot so it should be able edit
them. (but again: why would knot want to update them?)
Regards,
Anand Buddhdev
RIPE NCC
17:45
Hi Anand and also Chris,
Thanks for your suggestions!
I implemented
journal-content: all
zonefile-load: difference-no-serial
zonefile-sync: -1
through the template and it worked perfectly.
Next up: configuring knot for the secondary zones that we host.
Thanks for the help again!
MJ
On 02/08/2021 17:23, Anand Buddhdev wrote:
On 02/08/2021 16:57, mj wrote:
Hi MJ,
By default, Knot flushes zone files to the disk in plain zone file
format. However, I have a suggestion for you. Instead of keeping the
signed zones on disk in zone file format, use Knot's journal. You should
use the following options for your zone, or your default template:
journal-content: all
zonefile-load: differences-no-serial
zonefile-sync: -1
With these settings, Knot will load the unsigned zone from your zone
file on disk. It will sign the zone, and store the file contents of the
zone into its journal. Knot will not touch your unsigned zone on disk.
Whenever you need to change the zone, you can edit the zone file in
/var/lib/knot/db.domain.com, and run:
knotc zone-reload domain.com
Knot will read the zone file, find the differences, re-sign the parts of
the zone that need to be re-signed, and store everything into the
journal. Also note that you don't need to remember to update the serial
number in the SOA record of the zone. Knot will automatically increment
it by one whenever it needs to re-sign the zone, and the correct serial
will be stored in the journal. If you don't like the serial number to be
just incremented, you can use a different policy, by setting
"serial-policy" to either "unixtime" or "dateserial" (this
latter
setting is only useful if your zone doesn't change more than 100 times
in one day).
Regards,
Anand Buddhdev
RIPE NCC
We are testing migration from bind to knot, to
implement dnssec. We like
many things about knot! Thank you for making it available!
This is great! You'll love Knot! I'm not a developer, but I use Knot,
and I can provide some answers.
1) I wanted to test the knotc zone-backup
command, but we're getting:
You should not need to backup your zone files with the "knotc
zone-backup" command. Instead, just do filesystem copy of the files.
error: backup init failed (operation not
permitted)
Is the zone-backup command geared towards binary zones? Are our static
zone files the reason this doesn't work? I realise we can simply copy
the zone files, so in our case, the backup command probably adds nothing. 2) I have enabled DNSSEC, and upon restart we saw
the keys being
generated, and files appeared under /var/lib/knot/keys
I guess keeping copies of the files there is adequate backup too? No
"knotc zone-backup" required here as well?
Yes, you can backup /var/lib/knot/keys, and that should be adequate.
Aug 2
16:44:56 Latitude-E7470 knotd[259063]: warning: [domain.com.]
failed to update zone file (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error: [domain.com.]
zone event 'journal flush' failed (operation not permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: warning:
[1.2.3.4.in-addr.arpa.] failed to update zone file (operation not
permitted)
Aug 2 16:44:56 Latitude-E7470 knotd[259063]: error:
[1.2.3.4.in-addr.arpa.] zone event 'journal flush' failed (operation
not permitted)
We would like to understand the warnings/errors here too. Why would knot
try to update the zone files, and why it is failing? I have set the
permissions on the zone files 660 / knot:knot so it should be able edit
them. (but again: why would knot want to update them?)
3 Srp
3 Srp
10:16
On 02/08/2021 17:45, mj wrote:
Next up: configuring knot for the secondary zones that
we host.
A follow-up question on the knot-as-secondary project.
Know has to be secondary (like bind was) for some external zones, hosted
on windows server 2019 dns. (they are just regular public dns zones,
nothing AD related)
I installed knot on the same server as bind, so on the other side all
ACLs etc should still be valid, and yes:
kdig AXFR sub3.company.com @1.2.3.4
on the knot
server returns the complete zone, and it looks good.
(willing to share it if needed)
However, knotd says:
Aug 03 09:52:47 knot systemd[1]: Started Knot DNS
server.
Aug 03 09:52:47 knot knotd[11400]: info: [sub3.company.com.] AXFR, incoming, remote
1.2.3.4@53, started
Aug 03 09:52:47 knot knotd[11400]: debug: [sub3.company.com.] refresh, remote
prim_master, address 1.2.3.4@53, failed (trailing data)
Aug 03 09:52:47 knot knotd[11400]: warning: [sub3.company.com.] refresh, remote
prim_master_master not usable
Aug 03 09:52:47 knot knotd[11400]: error: [sub3.company.com.] refresh, failed (no usable
master)
Aug 03 09:52:47 knot knotd[11400]: error: [sub3.company.com.] zone event
'refresh' failed (no usable master)
Below is the knot config:
server:
rundir: "/run/knot"
user: knot:knot
listen: [ 0.0.0.0@53 ]
log:
- target: syslog
any: debug
database:
storage: "/var/lib/knot"
remote:
- id: prim_master
address: 1.2.3.4
acl:
- id: notify_from_prim
address: 1.2.3.4
action: notify
template:
- id: default
storage: "/var/lib/knot"
file: "%s.zone"
journal-content: all
zonefile-load: difference-no-serial
zonefile-sync: -1
zone:
- domain: sub3.company.com
storage: /var/lib/knot/zones
master: prim_master
acl: notify_from_prim
Switching back to bind, and it all works.
Is there some kind of incompatibility between knot and windows 2019 DNS?
(again: regular public DNS zone, no AD records etc)
Examples above are for sub3.company.com, but the same goes for sub2 and
sub1.
I am also asking my colleages about more details and perhaps logs from
the windows side of things.
But asking here: is there anything wrong in my knot.conf?
Thanks!
10:53
On 03/08/2021 10:16, mj wrote:
I am also asking my colleages about more details and
perhaps logs from
the windows side of things.
New info from their side:
On the windows 2019 side, the failing zone transfers are logged as
"Successful zone transfers"
So windows DNS is under the impression it all went fine...
For the record:
knotc zone-retransfer
just gives the same
refresh failed (trailing data), and refresh, remote
prim_master not usable
Ideas?
11:01
Hi MJ,
the "trailing data" is quite a specific error. It means that the
incomming DNS packet does not comply with standards in the way that it
contains some garbage data after its end.
Are you sure that you are not getting this error when trying with kdig?
Could you try to capture the communication with Wireshark (better on the
Knot side) and check the actual wire format of the packets?
Libor
Dne 03. 08. 21 v 10:53 mj napsal(a):
On 03/08/2021 10:16, mj wrote:
I am also asking my colleages about more details
and perhaps logs
from the windows side of things.
New info from their side:
On the windows 2019 side, the failing zone transfers are logged as
"Successful zone transfers"
So windows DNS is under the impression it all went fine...
For the record:
knotc zone-retransfer
just gives the
same refresh failed (trailing data), and refresh,
remote prim_master not usable
Ideas?
11:11
Hi,
Yes, I'm positive, and I've tried kdig on all three subdomains, and they
all look fine:
root@knot:/var/lib/knot/zones# kdig AXFR
sub3.company.com @1.2.3.4
;; AXFR for sub3.company.com.
....... regular zone records stuff, nothing strange
;; Received 1914 B (23 messages, 23 records)
;; Time 2021-08-03 11:07:54 CEST
;; From 1.2.3.4@53(TCP) in 48.9 ms
I will check about the wireshark stuff later.
MJ
On 03/08/2021 11:01, libor.peltan wrote:
Hi MJ,
the "trailing data" is quite a specific error. It means that the
incomming DNS packet does not comply with standards in the way that it
contains some garbage data after its end.
Are you sure that you are not getting this error when trying with kdig?
Could you try to capture the communication with Wireshark (better on the
Knot side) and check the actual wire format of the packets?
Libor
Dne 03. 08. 21 v 10:53 mj napsal(a):
>
> On 03/08/2021 10:16, mj wrote:
>> I am also asking my colleages about more details and perhaps logs
>> from the windows side of things.
>
> New info from their side:
>
> On the windows 2019 side, the failing zone transfers are logged as
> "Successful zone transfers"
>
> So windows DNS is under the impression it all went fine...
>
> For the record:
>> knotc zone-retransfer
> just gives the same refresh failed (trailing data), and refresh,
> remote prim_master not usable
>
> Ideas?
12:04
Hi,
I think I know some medicine for your broken XFR ;-)
Try adding `no-edns: on` to the remote section of the MS primary server. It's an
undocumented option for better interoperability with broken software.
It seems the option is still needed :-/
Daniel
On 8/3/21 11:11 AM, mj wrote:
Hi,
Yes, I'm positive, and I've tried kdig on all three subdomains, and they all look
fine:
root@knot:/var/lib/knot/zones# kdig AXFR
sub3.company.com @1.2.3.4
;; AXFR for sub3.company.com.
....... regular zone records stuff, nothing strange
;; Received 1914 B (23 messages, 23 records)
;; Time 2021-08-03 11:07:54 CEST
;; From 1.2.3.4@53(TCP) in 48.9 ms
I will check about the wireshark stuff later.
MJ
On 03/08/2021 11:01, libor.peltan wrote:
> Hi MJ,
>
> the "trailing data" is quite a specific error. It means that the incomming
DNS packet does not comply with standards in the way that it contains some garbage data
after its end.
>
> Are you sure that you are not getting this error when trying with kdig?
>
> Could you try to capture the communication with Wireshark (better on the Knot side)
and check the actual wire format of the packets?
>
> Libor
>
> Dne 03. 08. 21 v 10:53 mj napsal(a):
>>
>> On 03/08/2021 10:16, mj wrote:
>>> I am also asking my colleages about more details and perhaps logs from the
windows side of things.
>>
>> New info from their side:
>>
>> On the windows 2019 side, the failing zone transfers are logged as
"Successful zone transfers"
>>
>> So windows DNS is under the impression it all went fine...
>>
>> For the record:
>>> knotc zone-retransfer
>> just gives the same refresh failed (trailing data), and refresh, remote
prim_master not usable
>>
>> Ideas?
12:13
Yes, we have liftoff!
Haha :-)
What quick and good help here on this mailinglist! *impressed*
Thank you, all!
MJ
On 03/08/2021 12:04, Daniel Salzman wrote:
Hi,
I think I know some medicine for your broken XFR ;-)
Try adding `no-edns: on` to the remote section of the MS primary server. It's an
undocumented option for better interoperability with broken software.
It seems the option is still needed :-/
Daniel
On 8/3/21 11:11 AM, mj wrote:
> Hi,
>
> Yes, I'm positive, and I've tried kdig on all three subdomains, and they all
look fine:
>
>> root@knot:/var/lib/knot/zones# kdig AXFR sub3.company.com @1.2.3.4
>> ;; AXFR for sub3.company.com.
> ....... regular zone records stuff, nothing strange
>> ;; Received 1914 B (23 messages, 23 records)
>> ;; Time 2021-08-03 11:07:54 CEST
>> ;; From 1.2.3.4@53(TCP) in 48.9 ms
>
> I will check about the wireshark stuff later.
>
> MJ
>
>
> On 03/08/2021 11:01, libor.peltan wrote:
>> Hi MJ,
>>
>> the "trailing data" is quite a specific error. It means that the
incomming DNS packet does not comply with standards in the way that it contains some
garbage data after its end.
>>
>> Are you sure that you are not getting this error when trying with kdig?
>>
>> Could you try to capture the communication with Wireshark (better on the Knot
side) and check the actual wire format of the packets?
>>
>> Libor
>>
>> Dne 03. 08. 21 v 10:53 mj napsal(a):
>>>
>>> On 03/08/2021 10:16, mj wrote:
>>>> I am also asking my colleages about more details and perhaps logs from
the windows side of things.
>>>
>>> New info from their side:
>>>
>>> On the windows 2019 side, the failing zone transfers are logged as
"Successful zone transfers"
>>>
>>> So windows DNS is under the impression it all went fine...
>>>
>>> For the record:
>>>> knotc zone-retransfer
>>> just gives the same refresh failed (trailing data), and refresh, remote
prim_master not usable
>>>
>>> Ideas?
21:16
Hi,
Sorry to come back again, but it seems we still have an issue:
Knot is not serving our secondary zones after restarting, until we issue
a "knotc zone-retransfer sub3.company.com". Then it will start answering
queries for the zone.
A knot restart logs:
knotd[4436]: info: [sub3.company.com.] zone will be
loaded
knotd[4436]: info: [sub3.company.com.] zone loaded from journal, serial 2016110905
knotd[4436]: info: [sub3.company.com.] failed to parse zone file (not exists)
To demonstrate, after having restarted knot:
root@knot:/etc/knot# kdig sub3.company.com @4.5.6.7
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 13771
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; sub3.company.com. IN A
;; Received 30 B
;; Time 2021-08-03 20:44:29 CEST
;; From 4.5.6.7@53(UDP) in 0.0 ms
root@knot:/etc/knot# knotc zone-retransfer
sub3.company.com
OK
Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] control, received command
'zone-retransfer'
root@www:/etc/knot# Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] AXFR,
incoming, remote 1.2.3.4@53, started
Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] AXFR, incoming, remote
1.2.3.4@53, finished, 0.02 seconds, 23 messages, 1914 bytes
Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] zone stored to journal, serial
2016090960
Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] refresh, remote 1.2.3.4@53,
zone updated, 0.12 seconds, serial none -> 2016090960
root@knot:/etc/knot# kdig sub3.company.com @4.5.6.7
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 44788
;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; sub3.company.com. IN A
;; ANSWER SECTION:
sub3.company.com. 3600 IN A 1.2.3.4
;; Received 46 B
;; Time 2021-08-03 20:44:44 CEST
;; From 4.5.6.7@53(UDP) in 0.1 ms
In knot.conf, we have set as a template: journal-content: all, and the
secondary zone is defined like:
- domain: sub3.company.com
storage: /var/lib/knot/zones
master: zones_master
acl: notify_from_master
As a side note: the directory /var/lib/knot/zones contains nothing
sub3.company.com related. (which explains the knot startup message
"failed to parse zone file (not exists)")
Why would knot after restart load the zone from journal, but not start
serving it? Have I misconfigured something?
Sorry to have asked so many questions in just two days. :-)
MJ
22:20
Hi MJ,
maybe you want to set up zonefile-load to none?
https://www.knot-dns.cz/docs/3.1/singlehtml/index.html#zonefile-load
Thanks,
Libor
Dne 03. 08. 21 v 21:16 mj napsal(a):
Hi,
Sorry to come back again, but it seems we still have an issue:
Knot is not serving our secondary zones after restarting, until we
issue a "knotc zone-retransfer sub3.company.com". Then it will start
answering queries for the zone.
A knot restart logs:
knotd[4436]: info: [sub3.company.com.] zone will
be loaded
knotd[4436]: info: [sub3.company.com.] zone loaded from journal,
serial 2016110905
knotd[4436]: info: [sub3.company.com.] failed to parse zone file (not
exists)
To demonstrate, after having restarted knot:
root@knot:/etc/knot# kdig sub3.company.com
@4.5.6.7
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 13771
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; sub3.company.com. IN A
;; Received 30 B
;; Time 2021-08-03 20:44:29 CEST
;; From 4.5.6.7@53(UDP) in 0.0 ms
root@knot:/etc/knot# knotc zone-retransfer
sub3.company.com
OK
Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] control,
received command 'zone-retransfer'
root@www:/etc/knot# Aug 3 20:44:39 www knotd[4186]: info:
[sub3.company.com.] AXFR, incoming, remote 1.2.3.4@53, started
Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] AXFR,
incoming, remote 1.2.3.4@53, finished, 0.02 seconds, 23 messages,
1914 bytes
Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] zone
stored to journal, serial 2016090960
Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] refresh,
remote 1.2.3.4@53, zone updated, 0.12 seconds, serial none -> 2016090960
root@knot:/etc/knot# kdig sub3.company.com
@4.5.6.7
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 44788
;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; sub3.company.com. IN A
;; ANSWER SECTION:
sub3.company.com. 3600 IN A 1.2.3.4
;; Received 46 B
;; Time 2021-08-03 20:44:44 CEST
;; From 4.5.6.7@53(UDP) in 0.1 ms
In knot.conf, we have set as a template: journal-content: all, and the
secondary zone is defined like:
- domain: sub3.company.com
storage: /var/lib/knot/zones
master: zones_master
acl: notify_from_master
As a side note: the directory /var/lib/knot/zones contains nothing
sub3.company.com related. (which explains the knot startup message
"failed to parse zone file (not exists)")
Why would knot after restart load the zone from journal, but not start
serving it? Have I misconfigured something?
Sorry to have asked so many questions in just two days. :-)
MJ
4 Srp
4 Srp
10:47
Hi Libor,
Thanks again for quick and accurate assistane.
It worked perfectly.
As I took the secondary config from
https://www.knot-dns.cz/docs/3.1/singlehtml/#secondary-slave-zone
should that perhaps be added in the config sample there..?
All the best!
MJ
On 8/3/21 10:20 PM, libor.peltan wrote:
Hi MJ,
maybe you want to set up zonefile-load to none?
https://www.knot-dns.cz/docs/3.1/singlehtml/index.html#zonefile-load
Thanks,
Libor
Dne 03. 08. 21 v 21:16 mj napsal(a):
> Hi,
>
> Sorry to come back again, but it seems we still have an issue:
>
> Knot is not serving our secondary zones after restarting, until we
> issue a "knotc zone-retransfer sub3.company.com". Then it will start
> answering queries for the zone.
>
> A knot restart logs:
>
>> knotd[4436]: info: [sub3.company.com.] zone will be loaded
>> knotd[4436]: info: [sub3.company.com.] zone loaded from journal,
>> serial 2016110905
>> knotd[4436]: info: [sub3.company.com.] failed to parse zone file (not
>> exists)
>
> To demonstrate, after having restarted knot:
>
>> root@knot:/etc/knot# kdig sub3.company.com @4.5.6.7
>> ;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 13771
>> ;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
>>
>> ;; QUESTION SECTION:
>> ;; sub3.company.com. IN A
>>
>> ;; Received 30 B
>> ;; Time 2021-08-03 20:44:29 CEST
>> ;; From 4.5.6.7@53(UDP) in 0.0 ms
>
>
>> root@knot:/etc/knot# knotc zone-retransfer sub3.company.com
>> OK
>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] control,
>> received command 'zone-retransfer'
>> root@www:/etc/knot# Aug 3 20:44:39 www knotd[4186]: info:
>> [sub3.company.com.] AXFR, incoming, remote 1.2.3.4@53, started
>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] AXFR,
>> incoming, remote 1.2.3.4@53, finished, 0.02 seconds, 23 messages,
>> 1914 bytes
>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] zone
>> stored to journal, serial 2016090960
>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] refresh,
>> remote 1.2.3.4@53, zone updated, 0.12 seconds, serial none -> 2016090960
>
>
>> root@knot:/etc/knot# kdig sub3.company.com @4.5.6.7
>> ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 44788
>> ;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0
>>
>> ;; QUESTION SECTION:
>> ;; sub3.company.com. IN A
>>
>> ;; ANSWER SECTION:
>> sub3.company.com. 3600 IN A 1.2.3.4
>>
>> ;; Received 46 B
>> ;; Time 2021-08-03 20:44:44 CEST
>> ;; From 4.5.6.7@53(UDP) in 0.1 ms
>
>
> In knot.conf, we have set as a template: journal-content: all, and the
> secondary zone is defined like:
>
>> - domain: sub3.company.com
>> storage: /var/lib/knot/zones
>> master: zones_master
>> acl: notify_from_master
>
> As a side note: the directory /var/lib/knot/zones contains nothing
> sub3.company.com related. (which explains the knot startup message
> "failed to parse zone file (not exists)")
>
> Why would knot after restart load the zone from journal, but not start
> serving it? Have I misconfigured something?
>
> Sorry to have asked so many questions in just two days. :-)
>
> MJ
10:56
Hi MJ,
If you're using the same Knot instance to host a mix of primary (signed)
and secondary zones, then I suggest you set "zonefile-load" to "none"
in
your template, and then override it with "difference-no-serial" for the
primary zones. Secondary zones don't need a zone file at all. Incoming
XFRs are stored into the journal, and the zones are loaded entirely from
the journal at startup.
Regards,
Anand
On 04/08/2021 10:47, mj wrote:
Hi Libor,
Thanks again for quick and accurate assistane.
It worked perfectly.
As I took the secondary config from
https://www.knot-dns.cz/docs/3.1/singlehtml/#secondary-slave-zone
should that perhaps be added in the config sample there..?
All the best!
MJ
On 8/3/21 10:20 PM, libor.peltan wrote:
> Hi MJ,
>
> maybe you want to set up zonefile-load to none?
>
> https://www.knot-dns.cz/docs/3.1/singlehtml/index.html#zonefile-load
>
> Thanks,
>
> Libor
>
> Dne 03. 08. 21 v 21:16 mj napsal(a):
>> Hi,
>>
>> Sorry to come back again, but it seems we still have an issue:
>>
>> Knot is not serving our secondary zones after restarting, until we
>> issue a "knotc zone-retransfer sub3.company.com". Then it will start
>> answering queries for the zone.
>>
>> A knot restart logs:
>>
>>> knotd[4436]: info: [sub3.company.com.] zone will be loaded
>>> knotd[4436]: info: [sub3.company.com.] zone loaded from journal,
>>> serial 2016110905
>>> knotd[4436]: info: [sub3.company.com.] failed to parse zone file
>>> (not exists)
>>
>> To demonstrate, after having restarted knot:
>>
>>> root@knot:/etc/knot# kdig sub3.company.com @4.5.6.7
>>> ;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 13771
>>> ;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
>>>
>>> ;; QUESTION SECTION:
>>> ;; sub3.company.com. IN A
>>>
>>> ;; Received 30 B
>>> ;; Time 2021-08-03 20:44:29 CEST
>>> ;; From 4.5.6.7@53(UDP) in 0.0 ms
>>
>>
>>> root@knot:/etc/knot# knotc zone-retransfer sub3.company.com
>>> OK
>>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] control,
>>> received command 'zone-retransfer'
>>> root@www:/etc/knot# Aug 3 20:44:39 www knotd[4186]: info:
>>> [sub3.company.com.] AXFR, incoming, remote 1.2.3.4@53, started
>>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] AXFR,
>>> incoming, remote 1.2.3.4@53, finished, 0.02 seconds, 23 messages,
>>> 1914 bytes
>>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] zone
>>> stored to journal, serial 2016090960
>>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] refresh,
>>> remote 1.2.3.4@53, zone updated, 0.12 seconds, serial none ->
>>> 2016090960
>>
>>
>>> root@knot:/etc/knot# kdig sub3.company.com @4.5.6.7
>>> ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 44788
>>> ;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0
>>>
>>> ;; QUESTION SECTION:
>>> ;; sub3.company.com. IN A
>>>
>>> ;; ANSWER SECTION:
>>> sub3.company.com. 3600 IN A 1.2.3.4
>>>
>>> ;; Received 46 B
>>> ;; Time 2021-08-03 20:44:44 CEST
>>> ;; From 4.5.6.7@53(UDP) in 0.1 ms
>>
>>
>> In knot.conf, we have set as a template: journal-content: all, and
>> the secondary zone is defined like:
>>
>>> - domain: sub3.company.com
>>> storage: /var/lib/knot/zones
>>> master: zones_master
>>> acl: notify_from_master
>>
>> As a side note: the directory /var/lib/knot/zones contains nothing
>> sub3.company.com related. (which explains the knot startup message
>> "failed to parse zone file (not exists)")
>>
>> Why would knot after restart load the zone from journal, but not
>> start serving it? Have I misconfigured something?
>>
>> Sorry to have asked so many questions in just two days. :-)
>>
>> MJ
11:00
Did that.
Thanks!
On 8/4/21 10:56 AM, Anand Buddhdev wrote:
Hi MJ,
If you're using the same Knot instance to host a mix of primary (signed)
and secondary zones, then I suggest you set "zonefile-load" to "none"
in
your template, and then override it with "difference-no-serial" for the
primary zones. Secondary zones don't need a zone file at all. Incoming
XFRs are stored into the journal, and the zones are loaded entirely from
the journal at startup.
Regards,
Anand
On 04/08/2021 10:47, mj wrote:
> Hi Libor,
>
> Thanks again for quick and accurate assistane.
>
> It worked perfectly.
>
> As I took the secondary config from
> https://www.knot-dns.cz/docs/3.1/singlehtml/#secondary-slave-zone
>
> should that perhaps be added in the config sample there..?
>
> All the best!
> MJ
>
> On 8/3/21 10:20 PM, libor.peltan wrote:
>> Hi MJ,
>>
>> maybe you want to set up zonefile-load to none?
>>
>> https://www.knot-dns.cz/docs/3.1/singlehtml/index.html#zonefile-load
>>
>> Thanks,
>>
>> Libor
>>
>> Dne 03. 08. 21 v 21:16 mj napsal(a):
>>> Hi,
>>>
>>> Sorry to come back again, but it seems we still have an issue:
>>>
>>> Knot is not serving our secondary zones after restarting, until we
>>> issue a "knotc zone-retransfer sub3.company.com". Then it will
start
>>> answering queries for the zone.
>>>
>>> A knot restart logs:
>>>
>>>> knotd[4436]: info: [sub3.company.com.] zone will be loaded
>>>> knotd[4436]: info: [sub3.company.com.] zone loaded from journal,
>>>> serial 2016110905
>>>> knotd[4436]: info: [sub3.company.com.] failed to parse zone file
>>>> (not exists)
>>>
>>> To demonstrate, after having restarted knot:
>>>
>>>> root@knot:/etc/knot# kdig sub3.company.com @4.5.6.7
>>>> ;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 13771
>>>> ;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;; sub3.company.com. IN A
>>>>
>>>> ;; Received 30 B
>>>> ;; Time 2021-08-03 20:44:29 CEST
>>>> ;; From 4.5.6.7@53(UDP) in 0.0 ms
>>>
>>>
>>>> root@knot:/etc/knot# knotc zone-retransfer sub3.company.com
>>>> OK
>>>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] control,
>>>> received command 'zone-retransfer'
>>>> root@www:/etc/knot# Aug 3 20:44:39 www knotd[4186]: info:
>>>> [sub3.company.com.] AXFR, incoming, remote 1.2.3.4@53, started
>>>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] AXFR,
>>>> incoming, remote 1.2.3.4@53, finished, 0.02 seconds, 23 messages,
>>>> 1914 bytes
>>>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] zone
>>>> stored to journal, serial 2016090960
>>>> Aug 3 20:44:39 www knotd[4186]: info: [sub3.company.com.] refresh,
>>>> remote 1.2.3.4@53, zone updated, 0.12 seconds, serial none ->
>>>> 2016090960
>>>
>>>
>>>> root@knot:/etc/knot# kdig sub3.company.com @4.5.6.7
>>>> ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 44788
>>>> ;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;; sub3.company.com. IN A
>>>>
>>>> ;; ANSWER SECTION:
>>>> sub3.company.com. 3600 IN A 1.2.3.4
>>>>
>>>> ;; Received 46 B
>>>> ;; Time 2021-08-03 20:44:44 CEST
>>>> ;; From 4.5.6.7@53(UDP) in 0.1 ms
>>>
>>>
>>> In knot.conf, we have set as a template: journal-content: all, and
>>> the secondary zone is defined like:
>>>
>>>> - domain: sub3.company.com
>>>> storage: /var/lib/knot/zones
>>>> master: zones_master
>>>> acl: notify_from_master
>>>
>>> As a side note: the directory /var/lib/knot/zones contains nothing
>>> sub3.company.com related. (which explains the knot startup message
>>> "failed to parse zone file (not exists)")
>>>
>>> Why would knot after restart load the zone from journal, but not
>>> start serving it? Have I misconfigured something?
>>>
>>> Sorry to have asked so many questions in just two days. :-)
>>>
>>> MJ
1020
days inactive
1022
days old
14 comments
5 participants
participants (5)
-
Anand Buddhdev -
Chris -
Daniel Salzman -
libor.peltan -
mj