Hi,
we're using knot as a bump-in-the-wire DNSSEC Signer. The setup is as
follows:
BIND9(unsigned) -> AXFR -> knot(signing) -> AXFR -> BIND9(signed)
The zone starts out with a low serial like 10 or 11. knot has a
serial-policy: unixtime for the zones.
Problem is, whenever an update is pushed the serial number is
decreased again from unixtime back to the original serial which
prevents the zone from propagating to the slaves.
Example (test zone):
template:
- id: slave-dnssec-ecdsap256
storage: "/var/lib/knot/slave"
file: "%s.zone"
zonefile-load: difference
dnssec-signing: on
dnssec-policy: ecdsap256
master: ns1_signer
notify: ns1
acl: acl_ns1
zone:
- domain: xn--78jubwhb.xn--q9jyb4c
template: slave-dnssec-ecdsap256
serial-policy: unixtime
Here is an example where first a manual "zone-sign" is done to update
the serial to current unixtime (12 -> 1559298292) and after that the
zone is transferred in again which results in a serial decrease
(1559298292 -> 13).
[xn--78jubwhb.xn--q9jyb4c.] control, received command 'zone-sign'
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, dropping previous signatures, re-signing zone
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 49852, algorithm ECDSAP256SHA256, KSK, public, active
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 55142, algorithm ECDSAP256SHA256, public, active
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, signing started
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, successfully signed
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, next signing at 2019-06-07T12:24:52
[xn--78jubwhb.xn--q9jyb4c.] zone file updated, serial 12 -> 1559298292
[xn--78jubwhb.xn--q9jyb4c.] notify, outgoing, remote 176.9.75.248@53, serial 1559298292
[xn--78jubwhb.xn--q9jyb4c.] AXFR, outgoing, remote 176.9.75.248@60025, started, serial 1559298292
[xn--78jubwhb.xn--q9jyb4c.] AXFR, outgoing, remote 176.9.75.248@60025, finished, 0.00 seconds, 1 messages, 1819 bytes
[xn--78jubwhb.xn--q9jyb4c.] notify, incoming, remote 176.9.75.248@9104, received, serial 13
[xn--78jubwhb.xn--q9jyb4c.] refresh, remote 176.9.75.248@53, remote serial 13, zone is outdated
[xn--78jubwhb.xn--q9jyb4c.] IXFR, incoming, remote 176.9.75.248@53, receiving AXFR-style IXFR
[xn--78jubwhb.xn--q9jyb4c.] AXFR, incoming, remote 176.9.75.248@53, starting
[xn--78jubwhb.xn--q9jyb4c.] AXFR, incoming, remote 176.9.75.248@53, finished, 0.00 seconds, 1 messages, 321 bytes
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 49852, algorithm ECDSAP256SHA256, KSK, public, active
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, key, tag 55142, algorithm ECDSAP256SHA256, public, active
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, signing started
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, successfully signed
[xn--78jubwhb.xn--q9jyb4c.] DNSSEC, next signing at 2019-06-07T12:25:21
[xn--78jubwhb.xn--q9jyb4c.] refresh, remote 176.9.75.248@53, zone updated, 0.10 seconds, serial 12 -> 13
[xn--78jubwhb.xn--q9jyb4c.] zone file updated, serial 1559298292 -> 13
[xn--78jubwhb.xn--q9jyb4c.] notify, outgoing, remote 176.9.75.248@53, serial 13
How to prevent this? We want knot to always use the current unixtime
for the zone.
Best Regards
Sebastian
--
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
Dobrý den,
zkouším rozjet Knot DNS, ovšem narazil jsem na problém - knotd mi
neposlouchá na UDP portu. Upozornil mě na to nástroj http://dnsviz.net.
Poradí mi někdo prosím, co by mohlo být špatně a jak z toho ven?
Mám podezření na modul *noudp*, ovšem marně se snažím dohledat nějaké
podrobnější informace, popisující jak vůbec moduly fungují a jak se s
nimi pracuje. Knot jsem instaloval z repositáře
https://deb.knot-dns.cz/knot-latest.
knotd (Knot DNS), version 2.8.1; Debian 9
Děkuji.
--
S pozdravem
Ondřej Budín
Hi there,
while trying to understand the algorithm employed in the
`find_best_view` function in the geoip module, I started wondering
whether this line is in there intentionally:
https://gitlab.labs.nic.cz/knot/knot-dns/blob/4015475b0d3e11c0bd6fcac8aceb6…
I am still trying to understand how this works with the actual geo data,
but here is a test case using the subnet mode that yields slightly
surprising results:
Using a geoip config like this for zone example.com:
bar.example.com:
- net: 127.0.0.0/8
A: 9.9.9.9
- net: 192.0.0.0/8
A: 1.1.1.1
- net: 192.168.0.0/16
A: 4.4.4.4
- net: 192.168.1.0/24
A: 8.8.8.8
If I query bar.example.com from 192.168.1.X, I get 4.4.4.4, which is
suprising because it is neither the most nor the least specific item.
The binary search returns the most specific one (8.8.8.8), which is sort
of what I would expect. However, above line immediately takes the `prev`
item without checking for `view_strictly_in_view`. Without the above
line, the whole function returns the most specific item, as I would expect.
Please note that this is mostly an intuition atm, as I have not yet had
the time to set up a similar test case for real geo data (which uses the
same algorithm). But I figured that someone more familiar with the code
might have enough context to tell whether this is correct or not or what
a suitable fix might look like.
Thanks a bunch,
Conrad
Hi,
I have a quick update about the upstream package repositories in
Open Build Service (OBS) for Knot DNS.
New repositories
----------------
- CentOS_7_EPEL - aarch64
- Fedora_30 - x86_64, armv7l, aarch64
- xUbuntu_19.04 - x86_64
- Debian_Next - x86_64 (Debian unstable rolling release)
New repositories for Debian 10 and CentOS 8 should be available shortly
after these distros are released, depending on their buildroot
availability in OBS.
Deprecated repositories
-----------------------
- Arch - x86_64
Due to many issues with Arch packaging in OBS (invalid package size,
incorrect signatures) and the fast pace of Arch updates, please consider
this repository deprecated in favor of the knot package in Arch
Community repo [1]. The Arch OBS repository will most likely be removed
in the future.
Also, please note I'll be periodically deleting repositories for distros
that reach their official end of life. In the coming months, this
concerns Ubuntu 18.10 and Fedora 28.
[1] - https://www.archlinux.org/packages/community/x86_64/knot/
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hello Knot team
I have just noticed that there are no more Debian packages for Debian 8 (Jessie) at https://deb.knot-dns.cz/knot/dists/. Debian 8 is in LTS until June 30, 2020 (see https://wiki.debian.org/LTS). Is the dropping of packages for Jessie intended or not? (I plan to migrate this summer, but for now it would be good to still get security fixes for Knot.)
Might be related to the PGP revocation?
Danilo
I have to integrate Knot in framework which will be testing for the
presence of a running instance of the Knot daemon by means of 'knotc
status'. This works fine, once knotd has loaded all the zones. However,
when launching it there will be a window of opportunity during which 'knotc
status' will fail, despite the fact that knotd is already running, but
still loading its zones.
Two questions:
1. Is this a correct description, or am I missing something here?
2. If it is right, is there a way, with the concourse of KNOT tools, to
find out whether knotd is already running or still loading zones?
I guess that, if it is a matter of just verifying that knotd is running,
using the 'ps' command would be simpler. I wonder, however, whether it can
be done with KNOT tools alone.
