knot-dns-users May 2019

knot-dns-users@lists.nic.cz

6 participants
5 discussions

Problems with serial when using knot as standalone DNSSEC signer

by Sebastian Wiesinger

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

6 years, 1 month

Knot není dostupný na UDP

by Ondřej Budín

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

6 years, 1 month

Unexpect results with geoip subnet mode

by Conrad Hoffmann

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

6 years, 1 month

Open Build Service package repositories update

by Tomas Krizek

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

6 years, 1 month

knsupdate refused after some time

by Bjoern Franke

Hi, I'm using a script to dynamically update an IPv4. After some time, the update gets refused. Script: KNOT_SERVER='194.59.205.151' KNOT_KEY='hmac-sha256:dyndns:somerandomkey' croot='schafweide.org' domain='home.schafweide.org' knsupdate -y "${KNOT_KEY}" <<EOF server ${KNOT_SERVER} zone ${croot}. update delete $domain 60 A update add $domain 60 A $1 send quit EOF Error message: ;; ->>HEADER<<- opcode: UPDATE; status: REFUSED; id: 61622 ;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1 ;;schafweide.org. IN SOA dyndns. 0 ANY TSIG hmac-sha256. 1556969992 300 32 21LTowPMGditU419LSHez6CRtRblLLZZcxtu89RCocI= 61622 NOERROR 0 ;; ERROR: update failed with error 'REFUSED' After "systemctl restart knot" the update just runs fine. I'm wondering what's wrong there. Regards Bjoern

6 years, 2 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users May 2019