8 Čec
2014
8 Čec
'14
14:24
hello,
i'm operating a small hidden master server (four zones spread out to two
external NS servers), and want to introduce dnssec.
so far, i have kept my zone files in /etc under version control, but now
knot starts overwriting them, which is kind of important because of the
serial number increments, but also removes file structure, and comments
and generally messes with the changelog.
i could not quite infer from the documentation what the recommended work
flow is in this situation:
* will things work if i just make the zone files read-only for bind?
* should i keep the original files separate and copy them over to the
knot-writable destinations for each refresh? if yes, can that be
automated from within knot?
in either case, i have to take care of the serial numbers. my current
numbering scheme (YYYYMMDDXX with year, month, day and per-day number)
produces sufficiently few automated changes that incrementing by 10 each
time i edit the unsigned file on one deay would work, but what is best
practice there?
best regards
chrysn
ps. please keep me in cc when replying, as i'm not subscribed to the
list.
--
There's always a bigger fish.
-- Qui-Gon Jinn
8 Čec
8 Čec
22:37
Hello Chrysn,
unfortunatelly, this is something we haven't figured out yet.
Currently, the signed zone is flushed back to the zone file and this is
the only place where the signed records are stored. We are considering
storing of the automatically generated DNSSEC records in a separate
file, however we have not settled on a specific solution yet.
In Knot DNS 1.5, there are some improvements - the DNSSEC records are
stored at the end of the zone file, which could improve the ability to
store the zone file in a VCS.
Another solution is to set 'zonefile-flush' option to a high value to
prevent zone file flushing, tune 'ixfr-fslimit', and refrain from using
'knotc flush'. In that case, the automatically generated records will be
stored in the journal only - with some drawbacks: The SOA serial is
updated during the signing (according to the 'serial-policy' config
option) and you will have to set the serial to a higher value when
updating the zone file. Otherwise the served zone can get corrupt. Also
the previous DNSSEC records will be dropped and recreated.
As you suggested, it is also possible to copy the updated zone from VCS
into a directory writable by Knot and issue 'knotc reload'. This
handling cannot be automated by Knot DNS, but a script to perform this
operation is simple to write. But keep in mind, that this solution will
have a similar drawbacks as the solution with disabled zone file syncing.
I hope this explanation will help you at least a little. I would
recommend to try the 1.5 version and to store a signed zone in the VCS,
or to go with the scripted solution you suggested. Please, let us know
whether it works for you.
Thanks & Regards,
Jan
On 8.7.2014 14:24, chrysn wrote:
hello,
i'm operating a small hidden master server (four zones spread out to two
external NS servers), and want to introduce dnssec.
so far, i have kept my zone files in /etc under version control, but now
knot starts overwriting them, which is kind of important because of the
serial number increments, but also removes file structure, and comments
and generally messes with the changelog.
i could not quite infer from the documentation what the recommended work
flow is in this situation:
* will things work if i just make the zone files read-only for bind?
* should i keep the original files separate and copy them over to the
knot-writable destinations for each refresh? if yes, can that be
automated from within knot?
in either case, i have to take care of the serial numbers. my current
numbering scheme (YYYYMMDDXX with year, month, day and per-day number)
produces sufficiently few automated changes that incrementing by 10 each
time i edit the unsigned file on one deay would work, but what is best
practice there?
best regards
chrysn
ps. please keep me in cc when replying, as i'm not subscribed to the
list.
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
9 Čec
9 Čec
1:30
ahoj jan,
ahoj ondrej (second paragraph is for you),
On Tue, Jul 08, 2014 at 10:37:22PM +0200, Jan Včelák wrote:
Currently, the signed zone is flushed back to the zone
file and this is
the only place where the signed records are stored. We are considering
storing of the automatically generated DNSSEC records in a separate
file, however we have not settled on a specific solution yet.
In Knot DNS 1.5, there are some improvements - the DNSSEC records are
stored at the end of the zone file, which could improve the ability to
store the zone file in a VCS.
thank you for your reply!
i've built 1.5 for debian stable from the experimental package (only the
--with systemd and dh_systemd dependency needed dropping), things seem
to work well. (i'm aware experimental packages don't go to backports,
but chances are 1.5 goes to testing before the next debian release).
for the time being, i'll probably version-track my master zone file
without direct connection to knot, and manually apply the diffs to the
signed zone files.
(entries are grouped by newlines, commented, and don't contain fqdns,
all of which is lost even with 1.5's grouped records).
using knot as someone with little experience in dns, that's what'd feel
natural to me:
zones {
my-domain.at {
file "/etc/knot/my-domain.at.zone";
file "/var/lib/knot/my-domain.at.zone";
}
}
where knot could determine based on write permissions where to write and
where not to, but for the purpose of reading just concatenate them.
alternatively, `rw-file` could be explicit about writing, or even
`ddns-file` and `dnssec-file` to separate those.
such a setup would allow clean separation of configured state (/etc) and
state the application manages and persists internally (/var/lib), and as
a side effect allow otherwise unrelated zones to share configuration
snipplets.
best regards
chrysn
--
I shouldn't have written all those tank programs.
-- Kevin Flynn
12:43
Hey chrysn,
JFTR I will upload Knot DNS 1.5.0 to the unstable once the dust settles.
Cheers,
Ondrej
On Wed, Jul 9, 2014, at 01:30, chrysn wrote:
ahoj jan,
ahoj ondrej (second paragraph is for you),
On Tue, Jul 08, 2014 at 10:37:22PM +0200, Jan Včelák wrote:
--
Ondřej Surý <ondrej(a)sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Currently, the signed zone is flushed back to the
zone file and this is
the only place where the signed records are stored. We are considering
storing of the automatically generated DNSSEC records in a separate
file, however we have not settled on a specific solution yet.
In Knot DNS 1.5, there are some improvements - the DNSSEC records are
stored at the end of the zone file, which could improve the ability to
store the zone file in a VCS.
thank you for your reply!
i've built 1.5 for debian stable from the experimental package (only the
--with systemd and dh_systemd dependency needed dropping), things seem
to work well. (i'm aware experimental packages don't go to backports,
but chances are 1.5 goes to testing before the next debian release).
for the time being, i'll probably version-track my master zone file
without direct connection to knot, and manually apply the diffs to the
signed zone files.
(entries are grouped by newlines, commented, and don't contain fqdns,
all of which is lost even with 1.5's grouped records).
using knot as someone with little experience in dns, that's what'd feel
natural to me:
zones {
my-domain.at {
file "/etc/knot/my-domain.at.zone";
file "/var/lib/knot/my-domain.at.zone";
}
}
where knot could determine based on write permissions where to write and
where not to, but for the purpose of reading just concatenate them.
alternatively, `rw-file` could be explicit about writing, or even
`ddns-file` and `dnssec-file` to separate those.
such a setup would allow clean separation of configured state (/etc) and
state the application manages and persists internally (/var/lib), and as
a side effect allow otherwise unrelated zones to share configuration
snipplets.
best regards
chrysn
--
I shouldn't have written all those tank programs.
-- Kevin Flynn
Email had 1 attachment:
+ signature.asc
1k (application/pgp-signature) 
15:45
Dne 8.7.2014 14:24, chrysn napsal(a):
hello,
i'm operating a small hidden master server (four zones spread out to two
external NS servers), and want to introduce dnssec.
so far, i have kept my zone files in /etc under version control, but now
knot starts overwriting them, which is kind of important because of the
serial number increments, but also removes file structure, and comments
and generally messes with the changelog.
Hello chrysn,
there is another possible solution: Switch zones to dynamic mode and
copy zone files to /var/lib. On every update of the unsigned zone files
in /etc, issue [nsupdate][1] which will compare the unsigned file in
/etc with current zone file in /var/lib (ignoring DNSSEC-related RRs)
and issue DNS UPDATE messages to apply changes from unsigned zone to
signed zone.
[1]: http://dotat.at/prog/nsdiff/
That way you can keep your unsigned files well organised and documented
yet you don't have to regenerate all the signatures on every zone file
change.
I haven't tried this in practice but I think it is the best possible
deployment scenario.
Cheers,
Ondřej Caletka
4028
days inactive
4029
days old
4 comments
4 participants
participants (4)
-
chrysn -
Jan Včelák -
Ondřej Caletka -
Ondřej Surý