knot-dns-users

knot-dns-users@lists.nic.cz

7 participants
749 discussions

by André Cruz

Hi, When i try to install knot via ports as your documentation sayshttps://www.knot-dns.cz/docs/2.4/html/installation.html [cid:f31a0a83-7640-46e7-8586-d353f8c3d8f0] it points me to a verison of 2015 https://www.freshports.org/dns/knot Can you guys change the line to # cd /usr/ports/dns/knot3 just to be more clear for a new user of freebsd https://www.freshports.org/dns/knot3 Com os meus melhores cumprimentos, André Cruz

1 rok, 6 měsíců

module 'mod-onlinesign/authsignal', incompatible with automatic signing

by Erwin Lansing

Howdy, I’m trying to get Knot 3.3.5 to use authenticated DNSSEC bootstrapping following the blog article and docs. However, I’m getting an error for the signalling zones, but I fail to figure out what I may have overlooked. error: [_signal.ns2.droso.dk <http://signal.ns2.droso.dk/>.] module 'mod-onlinesign/authsignal', incompatible with automatic signing Relevant knot.conf snippets (in order): policy: - id: ecc algorithm: ecdsap256sha256 nsec3: on rrsig-refresh: 7d mod-onlinesign: - id: authsignal nsec-bitmap: [CDS, CDNSKEY] policy: ecc template: - id: default … dnssec-signing: on dnssec-policy: ecc … zone: - domain: _signal.ns2.droso.dk <http://signal.ns2.droso.dk/> module: [mod-authsignal, mod-onlinesign/authsignal] Any hint appreciated Best Erwin

1 rok, 6 měsíců

KNOT resolver and NS serverers with CNAME

by Josef Karliak

Good morning, ISC bind is strict about CNAME of NS server: skipping nameserver 'aa.bb.cz' because it is a CNAME, while resolving '9.4/4.3.2.1.in-addr.arpa/PTR'. How about Knot resolver ? Thanks and best regards J.Karliak

1 rok, 7 měsíců

Remotely adding zones

by Einar Bjarni Halldórsson

Hi, I have a use case, where today we’re running BIND and a daemon uses rndc to create/remove/update zones on secondary servers. According to `man knotc` knotc only supports UNIX sockets (old ubuntu man page showed ‘-p’ parameter to specify port). I know I could use a catalog zone, but that would be a bigger change than I prefer right now. The primary server is running BIND+DLZ with a PostgreSQL backend. Replacing the primary is on the roadmap, but for now, I just want to replace the secondaries. Is there a good way to remotely add zones to a knot secondary? .einar

1 rok, 8 měsíců

knotc reload after updates to knot.conf

by Angus Clarke

Hello, When doing something quite dramatic in knot.conf like adding and/or removing a zone, is "knotc reload" a suitable approach to honour those changes or would you recommend restarting the whole process? "knotc reload" seems to work just fine in test, I'm just looking for some further confidence I suppose. Thanks Angus

1 rok, 8 měsíců

kzonecheck for bookworm

by Randy Bush

a bit confused here. knot package for bookworm does not seem to include kzonecheck. nor does knot-dnsutils. where/how to get? thanks randy

1 rok, 8 měsíců

AXFR sender FINs 10% of the way through transfer

by Randy Bush

debian 12 # uname -a Linux rip.psg.com 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux # knotc --version knotc (Knot DNS), version 3.2.6 AXFR of a 750k zone from seattle to, lebanon, europe, iceland, southern africa, ...) fails over v5 and v6, i.e. somewhat larger rtt same AXFR seattle seattle or seattle to ashburn works v4 and v6. seattle to dallas v4 good, v6 fails, but it smells of an HE.net hop. when it fails, it is always within a hundred or so mytes of the same place, approximately 10% through the file. pcap of seattle->beirut at https://archive.psg.com/240323.beirut.pcap the last payload is in frame 217. at 219, seattle (b) sends a FIN/PSH/ACK. then at 251, after acking everything, beirut (nabil) FIN/ACKs seattle's FIN and we're dead. i am not positive this is the key question as my tcp fu is a bit rusty. but why did seattle send the FIN at 219, 10% through the file? randy

1 rok, 8 měsíců

silly nit

by Randy Bush

in address: [185.91.97.18, 2a05:e380:2:4::2] # nabil.beirutix.net if this is a tab character ^ # knotc conf-check error: config, file '/etc/knot/knot.conf', line 324, item 'address', value '2a05:e380:2:4::2' (tabulator character is not allowed) blanks are ok # knotc --version knotc (Knot DNS), version 3.2.6 yes, that is the latest on debian 12 randy

1 rok, 8 měsíců

bitw signing as secondary

by Randy Bush

server runs a tld as primary, but slds are hidden primaries which the server pulls as a secondary, wants to sign bump-in-the-wire, and then make available to public secondaries. i think that the doc says this is doable, but instructions are insufficiently explicit for this idjit. i am fetching the slds into policy: - id: pol-256-256 algorithm: rsasha256 # was ecdsap256sha256 sra uses ecdsap384sha384 manual: on ... template: - id: signed storage: /var/lib/knot/sec-sign dnssec-signing: on dnssec-policy: pol-256-256 zonefile-sync: -1 zonefile-load: difference journal-content: all serial-policy: unixtime ... zone: - domain: sld.tld file: tld.sld # sorry, i like alpha sort in `ls` :) master: hidden-fetch template: signed acl: [allow-local, secondaries-push] the policy and template are those from signing primary zone; which i suspect is ill advised. i did generate keying as i would when signing a primary zone # keymgr sld.tld generate algorithm=rsasha256 ksk=yes zsk=yes 7a618eaf94ea1d903233cb547faa24bae8cb49a5 # knotc zone-reload sld.tld OK # keymgr sld.tld ds sld.tld. DS 63562 8 2 2d25e465f131900413d7e8a90ad1b96c75ba835de63dfee08610b113a779d41f sld.tld. DS 63562 8 4 ed9c31c495703ec354f1a1835c9878339224cc06ac3001151c2ebb89524b25190efa424348c999b0c4df940edffa8409 any kind soul(s) care to whack me with a clue bat? randy

1 rok, 9 měsíců

Possible signing bug? Missing wildcard NSEC for RCODE 3 subdomains

by Matthew Pounsett

I got a report of an NSEC error from someone who tried to connect to a mistyped hostname. I've done a bit of poking, and it looks like we're seeing a missing wildcard NSEC for domain names that are two subdomains down from the apex, but not for subdomains of the apex. Though, I admit I can't see the problem myself. Querying by hand I see what looks like an identical response, but resolvers and DNSViz report problems with the deeper name. For example, nonexistent.dns-oarc.net and nonexistent.sjc.dns-oarc.net ( sjc.dns-oarc.net is a real subdomain with hosts in it, not an ENT)... kdig output and DNSViz results below. We're running knot/unknown,now 3.3.5-cznic.1~bullseye from deb.knot-dns.cz, and this is the relevant policy statement for the zone: policy: - id: ecdsa algorithm: ecdsap256sha256 ksk-lifetime: 365d ksk-submission: parent_zone_sbm zsk-lifetime: 30d rrsig-lifetime: 14d rrsig-refresh: 7d We are mid-KSK-roll, waiting on the DS submission check. Have I misconfigured something here, or is there a signing bug, or is this something else? Thanks! Matt --- nonexistent.sjc.dns-oarc.net: DNSviz reports this is fine. <https://dnsviz.net/d/nonexistent.dns-oarc.net/ZfNH1w/dnssec/> ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 9380 ;; Flags: qr aa; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; nonexistent.dns-oarc.net. IN A ;; AUTHORITY SECTION: dns-oarc.net. 3600 IN SOA ns1.dns-oarc.net. hostmaster.dns-oarc.net. 2024031400 300 60 604800 3600 nfsen.dns-oarc.net. 3600 IN NSEC ns.dns-oarc.net. A AAAA RRSIG NSEC dns-oarc.net. 3600 IN NSEC fs1.10g.dns-oarc.net. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY CDS CDNSKEY CAA dns-oarc.net. 3600 IN RRSIG SOA 13 2 14400 20240328021935 20240314004935 6048 dns-oarc.net. [omitted] nfsen.dns-oarc.net. 3600 IN RRSIG NSEC 13 3 3600 20240326215132 20240312202132 6048 dns-oarc.net. [omitted] dns-oarc.net. 3600 IN RRSIG NSEC 13 2 3600 20240322045130 20240308032130 6048 dns-oarc.net. [omitted] ;; Received 518 B ;; Time 2024-03-14 18:57:33 UTC ;; From 64.191.0.128@53(UDP) in 0.3 ms nonexistent.sjc.dns-oarc.net: resolvers and DNSViz report a missing wildcard NSEC <https://dnsviz.net/d/nonexistent.sjc.dns-oarc.net/ZfNH6w/dnssec/> ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 660 ;; Flags: qr aa; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; nonexistent.sjc.dns-oarc.net. IN A ;; AUTHORITY SECTION: dns-oarc.net. 3600 IN SOA ns1.dns-oarc.net. hostmaster.dns-oarc.net. 2024031400 300 60 604800 3600 newmail.sjc.dns-oarc.net. 3600 IN NSEC pdu-7301.sjc.dns-oarc.net. A AAAA RRSIG NSEC shin-cubes.dns-oarc.net. 3600 IN NSEC an1.10g.sjc.dns-oarc.net. A AAAA RRSIG NSEC dns-oarc.net. 3600 IN RRSIG SOA 13 2 14400 20240328021935 20240314004935 6048 dns-oarc.net. [omitted] newmail.sjc.dns-oarc.net. 3600 IN RRSIG NSEC 13 4 3600 20240326215132 20240312202132 6048 dns-oarc.net. [omitted] shin-cubes.dns-oarc.net. 3600 IN RRSIG NSEC 13 3 3600 20240326215132 20240312202132 6048 dns-oarc.net. [omitted] ;; Received 544 B ;; Time 2024-03-14 18:57:33 UTC ;; From 64.191.0.128@53(UDP) in 0.3 ms

1 rok, 9 měsíců

← Newer
1
...
4
5
6
7
8
9
10
...
75
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users