Knot DNS issueshttps://gitlab.nic.cz/knot/knot-dns/-/issues2024-03-14T16:18:03+01:00https://gitlab.nic.cz/knot/knot-dns/-/issues/924Zone check isn't resulting to error in case of invalid zone file2024-03-14T16:18:03+01:00Grigoriev SemyonZone check isn't resulting to error in case of invalid zone fileIm trying to validate modified zone file and in case of invalid file rollback changes
Expected beh using knotc:
```bash
knotc -b zone-freeze example.com.
knotc -b zone-flush example.com.
nano /var/lib/knot/example.com.zone // modifying ...Im trying to validate modified zone file and in case of invalid file rollback changes
Expected beh using knotc:
```bash
knotc -b zone-freeze example.com.
knotc -b zone-flush example.com.
nano /var/lib/knot/example.com.zone // modifying file
knotc zone-check example.com // resulting to error if zone file is invalid
knotc zone-flush example.com // if error rollback changes
knotc zone-thaw example.com // thaw zone
```
Code example:
```python
import libknot.control
# Initialization
ctl = libknot.control.KnotCtl()
ctl.connect("/var/run/knot/knot.sock")
ctl.set_timeout(60)
ctl.send_block(cmd="zone-check", zone="example.com") ## how to get an error from zone-check if zone file is invalid?
```
Code example is not resulting to error if zone file is invalid. Receive block also doesn't help
How to validate zone file and get error if its invalid?https://gitlab.nic.cz/knot/knot-dns/-/issues/923Incorrect `alpn` processing2024-03-06T15:20:27+01:00Jeroen KoekkoekIncorrect `alpn` processingI'm implementing `alpn`'s double escaping in my own zone parser and decided to check what BIND and Knot do. I noticed some strange behavior using `kzonecheck` (version 3.3.4).
`foo SVCB 1 . alpn=foo\\\092,bar`
is incorrectly printed as:...I'm implementing `alpn`'s double escaping in my own zone parser and decided to check what BIND and Knot do. I noticed some strange behavior using `kzonecheck` (version 3.3.4).
`foo SVCB 1 . alpn=foo\\\092,bar`
is incorrectly printed as:
`foo SVCB 1 . alpn=foo\\,bar`
`foo SVCB 1 . alpn="foo\\092,bar"`
is incorrectly printed as:
`foo SVCB 1 . alpn="foo\\\\,bar`https://gitlab.nic.cz/knot/knot-dns/-/issues/921prometheus metrics are all gauges2024-03-01T09:02:55+01:00Marcel Kochprometheus metrics are all gaugesMetrics that should be a counter are also gauges. This results in the inability to use functions like `rate` to get the queries/sec, as these functions only works with metrics of type counter.
The metrics endpoint is currently automatic...Metrics that should be a counter are also gauges. This results in the inability to use functions like `rate` to get the queries/sec, as these functions only works with metrics of type counter.
The metrics endpoint is currently automatic generated form metrics knot provides. Therefore, it is not straight forward to define the type. Probably a hard mapping is required.
Example with current and *required* behavior:
```diff
# HELP knot_query_type
- # TYPE knot_query_type gauge
+ # TYPE knot_query_type counter
knot_query_type{section="mod-stats",type="SOA"} 25.0
knot_query_type{section="mod-stats",type="PTR"} 97.0
```
Edit: I am willing to provide a Pull Request after a possible solution has been discussed.https://gitlab.nic.cz/knot/knot-dns/-/issues/922Bus Error (coredump)2024-02-27T01:33:03+01:00solidcc2Bus Error (coredump)Hi, Knot, tag: v3.3.3 coredump with bus error, when reload. Can anyone help me troubleshoot?
I developed a personal module based on v3.3.3 without modifying the code in libknot.
I stress test the knotd with 5 process.
1. knotd process...Hi, Knot, tag: v3.3.3 coredump with bus error, when reload. Can anyone help me troubleshoot?
I developed a personal module based on v3.3.3 without modifying the code in libknot.
I stress test the knotd with 5 process.
1. knotd process
2. watch -n 1 knotc reload
3. dnsperf -m tcp
4. dnsperf -m udp
5. python script to change config every few seconds
then knotd and knotc failed in the same line, but the time of crash is not same.
this is stack of knotc
![screenshot-20240226-190324](/uploads/e1739a5964e95894fd912c5150e5e40b/screenshot-20240226-190324.png)
this is stack of knotd
![screenshot-20240226-190424](/uploads/ba8b153b6fb12c7d8cb872d62152ad46/screenshot-20240226-190424.png)
this is pos of crash
![20240226-190931](/uploads/c884d38bcd658c1f5448304ec5dddf61/20240226-190931.jpeg)
Info of env:
os: Debian GNU/Linux 10 (buster)
kernel+arch: Linux 5.4.56.bsk.10-amd64 #5.4.56.bsk.10 SMP Debian 5.4.56.bsk.10 Fri Sep 24 12:17:03 UTC
x86_64 GNU/Linux
gcc: gcc (Debian 8.3.0-6) 8.3.0
make: GNU Make 4.2.1
glibc: ldd (Debian GLIBC 2.28-10) 2.28https://gitlab.nic.cz/knot/knot-dns/-/issues/871Apex is not freed in the zone_contents_free function2024-02-26T13:13:29+01:00Fairy ZhangApex is not freed in the zone_contents_free functionMay I ask why apex is not freed in the zone_contents_free function?
I use "knotc zone-reload -f $zonename" to reload the zone which has been updated just now while there are many queries.
But the segmentation fault may occur sometimes. ...May I ask why apex is not freed in the zone_contents_free function?
I use "knotc zone-reload -f $zonename" to reload the zone which has been updated just now while there are many queries.
But the segmentation fault may occur sometimes. And this could happed in knot 3.1.1 with both geoip module and other module which I have added.
And the bt like this:
```
#0 0x00007f7f5d57402e in knot_dname_labels (name=0x1 <error: Cannot access memory at address 0x1>, pkt=0x0)
at libknot/dname.c:725
#1 0x00007f7f5d5741b9 in knot_dname_in_bailiwick (name=0x55fc20dde900 "3",
bailiwick=0x1 <error: Cannot access memory at address 0x1>) at libknot/dname.c:772
#2 0x000055fc19fad33f in zone_contents_find_dname (zone=0x7f79a400caf0, name=0x55fc20dde900 "3",
match=0x7f7ed003c140, closest=0x7f7ed003c148, previous=0x7f7ed003c150) at knot/zone/contents.c:275
#3 0x000055fc19fbd3de in solve_name (pkt=pkt@entry=0x7f7ed003c338, qdata=qdata@entry=0x7f7ed003c038,
state=<optimized out>) at knot/nameserver/internet.c:415
#4 0x000055fc19fbd7df in solve_answer (ctx=0x0, qdata=0x7f7ed003c038, pkt=0x7f7ed003c338, state=<optimized out>)
at knot/nameserver/internet.c:442
#5 answer_query (qdata=0x7f7ed003c038, pkt=0x7f7ed003c338) at knot/nameserver/internet.c:615
#6 internet_process_query (pkt=pkt@entry=0x7f7ed003c338, qdata=qdata@entry=0x7f7ed003c038)
at knot/nameserver/internet.c:681
#7 0x000055fc19f9dfa0 in query_internet (ctx=0x7f7ecbdfca70, pkt=0x7f7ed003c338)
at knot/nameserver/process_query.c:151
#8 process_query_out (ctx=0x7f7ecbdfca70, pkt=0x7f7ed003c338) at knot/nameserver/process_query.c:594
#9 0x000055fc19f71e12 in knot_layer_produce (pkt=0x7f7ed003c338, ctx=0x7f7ecbdfca70) at ./knot/query/layer.h:134
#10 udp_handle (xdp_msg=0x0, tx=0x7f7f5de1ea40, rx=<optimized out>, ss=0x7f7f5de1e040, fd=<optimized out>,
udp=0x7f7ecbdfca70) at knot/server/udp-handler.c:93
#11 udp_recvmmsg_handle (ctx=0x7f7ecbdfca70, d=0x7f7f5de1e038) at knot/server/udp-handler.c:314
#12 0x000055fc19f721a2 in udp_master (thread=thread@entry=0x55fc1b3d8b10) at knot/server/udp-handler.c:540
#13 0x000055fc19f6dbed in thread_ep (data=0x55fc1b3d8b10) at knot/server/dthreads.c:146
#14 0x00007f7f5cf074a4 in start_thread (arg=0x7f7ecbdfd700) at pthread_create.c:456
#15 0x00007f7f5c28dd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
```
I just want to know if apex should be freed if zone contents is freed?https://gitlab.nic.cz/knot/knot-dns/-/issues/5refactoring - split parser as a separate project2024-02-26T12:16:06+01:00Ghost Userrefactoring - split parser as a separate project:sunny: code cleanup (split)
:partly_sunny: autotools fiddling
(relicensing)
(fork as a new project, probably coordinate with @ondrej):sunny: code cleanup (split)
:partly_sunny: autotools fiddling
(relicensing)
(fork as a new project, probably coordinate with @ondrej)v1.4.0 alphaDaniel SalzmanDaniel Salzmanhttps://gitlab.nic.cz/knot/knot-dns/-/issues/648per zone statistics does not work with templates2024-02-16T09:04:20+01:002bitper zone statistics does not work with templatesHey there, I'm using knot version 2.8.1 and tried to make a configuration via templating:
```
mod-stats:
- id: custom
dns-presence: on
query-type: on
template:
- id: default
storage: "/var/db/knot/"
file: "%s.zone"
...Hey there, I'm using knot version 2.8.1 and tried to make a configuration via templating:
```
mod-stats:
- id: custom
dns-presence: on
query-type: on
template:
- id: default
storage: "/var/db/knot/"
file: "%s.zone"
module: mod-stats/custom
```
example zone looks like
```
zone:
- domain: 4.e.1.0.c.0.0.0.0.0.0.0.a.2.ip6.arpa.
module: mod-synthrecord/b38fe5a0-ab74-4b17-a3cf-06e6d256d5fb
template: default
```
but i just got the server statistics output...
when i put the mod-stats module without the template it works, configuration looks like this:
```
zone:
- domain: 4.e.1.0.c.0.0.0.0.0.0.0.a.2.ip6.arpa.
module: mod-synthrecord/b38fe5a0-ab74-4b17-a3cf-06e6d256d5fb
module: mod-stats-/custom
```
anny suggestions?https://gitlab.nic.cz/knot/knot-dns/-/issues/269Add support for GSS-API DDNS2024-02-16T08:57:41+01:00Ondřej SurýAdd support for GSS-API DDNSFor request: http://www.abclinuxu.cz/zpravicky/knot-dns-1.5.0/diskuse#19 or for Bind 9 details see: http://jpmens.net/2012/06/29/dynamic-dns-updates-using-gss-tsig-and-kerberos/For request: http://www.abclinuxu.cz/zpravicky/knot-dns-1.5.0/diskuse#19 or for Bind 9 details see: http://jpmens.net/2012/06/29/dynamic-dns-updates-using-gss-tsig-and-kerberos/backburnerhttps://gitlab.nic.cz/knot/knot-dns/-/issues/919knotc zone-reload and crash2024-02-15T17:05:19+01:00hjlogzwknotc zone-reload and crashWhen using **knotc zone-reload**, accidental program crashes may occur. The following is detailed information:
knot version: 3.0.1
the core file info:
warning: Unexpected size of section `.reg-xstate/189700' in core file.
[Thre...When using **knotc zone-reload**, accidental program crashes may occur. The following is detailed information:
knot version: 3.0.1
the core file info:
warning: Unexpected size of section `.reg-xstate/189700' in core file.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/opt/knot/sbin/knotd -c /opt/etc/knot/knot.conf -d'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Unexpected size of section `.reg-xstate/189700' in core file.
#0 0x00007fa3cf4b3d05 in knot_dname_labels (name=name@entry=0x40 <error: Cannot access memory at address 0x40>,
pkt=pkt@entry=0x0) at libknot/dname.c:751
751 libknot/dname.c: No such file or directory.
[Current thread is 1 (Thread 0x7e40b6df4700 (LWP 189700))]
(gdb) bt
#0 0x00007fa3cf4b3d05 in knot_dname_labels (name=name@entry=0x40 <error: Cannot access memory at address 0x40>,
pkt=pkt@entry=0x0) at libknot/dname.c:751
#1 0x00007fa3cf4b4430 in knot_dname_in_bailiwick (name=name@entry=0x7e40540008cc "\003abc\atestdns\003com",
bailiwick=0x40 <error: Cannot access memory at address 0x40>) at libknot/dname.c:802
#2 0x000055c024e6eeaf in zone_contents_find_dname (zone=0x7e40a80e7010, name=0x7e40540008cc "\003abc\atestdns\003com",
match=0x7e3fafaab358, closest=0x7e3fafaab360, previous=0x7e3fafaab368) at knot/zone/contents.c:297
#3 0x000055c024ec298d in solve_name (state=0, pkt=0x7e3fafaab560, qdata=0x7e3fafaab038) at knot/nameserver/internet.c:405
#4 0x000055c024ec2fdc in solve_answer (ctx=0x0, qdata=0x7e3fafaab038, pkt=0x7e3fafaab560, state=<optimized out>)
at knot/nameserver/internet.c:441
#5 answer_query (qdata=0x7e3fafaab038, pkt=0x7e3fafaab560) at knot/nameserver/internet.c:700
#6 internet_process_query (pkt=pkt@entry=0x7e3fafaab560, qdata=0x7e3fafaab038) at knot/nameserver/internet.c:767
#7 0x000055c024ea4a93 in query_internet (ctx=0x7e40b6df3a90, pkt=0x7e3fafaab560) at knot/nameserver/process_query.c:150
#8 process_query_out (ctx=0x7e40b6df3a90, pkt=0x7e3fafaab560) at knot/nameserver/process_query.c:637
#9 0x000055c024e6c99a in knot_layer_produce (pkt=0x7e3fafaab560, ctx=0x7e40b6df3a90) at ./knot/query/layer.h:134
#10 udp_handle (xdp_msg=0x0, tx=0x7fa3a8002a40, rx=0x7fa3a8002720, ss=0x7fa3a8002040, fd=<optimized out>, udp=0x7e40b6df3a90)
at knot/server/udp-handler.c:169
#11 udp_recvmmsg_handle (ctx=ctx@entry=0x7e40b6df3a90, d=d@entry=0x7fa3a8002038, unused=unused@entry=0x0)
at knot/server/udp-handler.c:404
#12 0x000055c024e6ce91 in udp_master (thread=thread@entry=0x55c026aca740) at knot/server/udp-handler.c:689
#13 0x000055c024e68a65 in thread_ep (data=0x55c026aca740) at knot/server/dthreads.c:146
#14 0x00007fa3ce5a44a4 in start_thread (arg=0x7e40b6df4700) at pthread_create.c:456
#15 0x00007fa3cd42bd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
Could you provide some suggestions? What may be the problem causing it?https://gitlab.nic.cz/knot/knot-dns/-/issues/243dnssec-library: universal signing context (TSIG/SIG0)2024-02-15T11:20:54+01:00Ghost Userdnssec-library: universal signing context (TSIG/SIG0)TSIG signing & checking API in processing contexts
* I want a generic layer that can accept packets and keys
* Caller shouldn't have to store digest, tsig data... everything should be transparent
* Context-aware operation - transfers hav...TSIG signing & checking API in processing contexts
* I want a generic layer that can accept packets and keys
* Caller shouldn't have to store digest, tsig data... everything should be transparent
* Context-aware operation - transfers have relaxed requirements on TSIG checking
* Replace the old tsigop-based APIsbackburnerhttps://gitlab.nic.cz/knot/knot-dns/-/issues/914KSK rollover should only happen if previous rollover was completed2024-02-02T16:41:42+01:00Tuomo SoiniKSK rollover should only happen if previous rollover was completedI found an issue that knot try to rollover KSK even when previous KSK rollover was not completed (DS was not submitted to upstream).
If previous KSK rollover was not confirmed there shouldn't be new one.
On this system there was submis...I found an issue that knot try to rollover KSK even when previous KSK rollover was not completed (DS was not submitted to upstream).
If previous KSK rollover was not confirmed there shouldn't be new one.
On this system there was submission check configured but because responsible persons never actually updated DS record on toplevel, knot tried to do another KSK rollover. Result was two CDS and CDNSKEY records, one for previous ksk and another for next one. I think best way to avoid this would be to only start timer for next KSK rollover after DS submission has been confirmed either by submission check or manually.https://gitlab.nic.cz/knot/knot-dns/-/issues/916Infinite loop in knot_rrset_to_wire_extra2024-01-25T14:49:37+01:00Alexandre FERRIEUXInfinite loop in knot_rrset_to_wire_extraHello,
A `kresd` in perfectly smooth production for months suddenly climbs to 100%CPU and stays there indefinitely. On this 4-CPU machine, we started 4 `kresd`, and only one had the problem.
Gdb stack below:
```gdb
(gdb) where
#0 0x00...Hello,
A `kresd` in perfectly smooth production for months suddenly climbs to 100%CPU and stays there indefinitely. On this 4-CPU machine, we started 4 `kresd`, and only one had the problem.
Gdb stack below:
```gdb
(gdb) where
#0 0x00007f2ff0d86373 in ?? () from /lib/x86_64-linux-gnu/libknot.so.12
#1 0x00007f2ff0d86c7f in knot_rrset_to_wire_extra () from /lib/x86_64-linux-gnu/libknot.so.12
#2 0x00007f2ff0d85843 in knot_pkt_put_rotate () from /lib/x86_64-linux-gnu/libknot.so.12
#3 0x00007f2ff0dd9790 in ?? () from /lib/libkres.so.9
#4 0x00007f2ff0ddb03d in kr_resolve_finish () from /lib/libkres.so.9
#5 0x0000000000420f5a in ?? ()
#6 0x00000000004215a8 in ?? ()
#7 0x000000000041bcb1 in ?? ()
#8 0x0000000000416831 in ?? ()
#9 0x00007f2ff0ccb9ad in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#10 0x00007f2ff0ccda23 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#11 0x00007f2ff0cbc714 in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
#12 0x000000000040de40 in ?? ()
#13 0x00007f2ff077cd0a in __scalbn (x=0, n=-733217408) at ../sysdeps/ieee754/dbl-64/wordsize-64/s_scalbn.c:35
#14 0x00007fff661c6628 in ?? ()
#15 0x00000004c005bb00 in ?? ()
#16 0x000000000040cfc0 in ?? ()
#17 0x00007f2ff0c03478 in ?? () from /lib/x86_64-linux-gnu/libgnutls.so.30
#18 0x0000000000000000 in ?? ()
(gdb)
```
Disassembly around the top address shows this tight loop:
```gdb
0x00007f2ff0d86359: movzwl (%r14),%r14d
0x00007f2ff0d8635d: rol $0x8,%r14w
0x00007f2ff0d86362: add $0x4000,%r14w
0x00007f2ff0d86368: movzwl %r14w,%r14d
0x00007f2ff0d8636c: add %rdi,%r14
0x00007f2ff0d8636f: movzbl (%r14),%esi
=> 0x00007f2ff0d86373: and $0xffffffc0,%esi
0x00007f2ff0d86376: cmp $0xc0,%sil
0x00007f2ff0d8637a: jne 0x7f2ff0d861ef
0x00007f2ff0d86380: jmp 0x7f2ff0d86359
```
And a breakpoint set on the `jne` escape address `0x7f2ff0d861ef` ... is never hit. This confirms the above 10 instructions make up the "loop of death". Unfortunately we have no clue on the stimulus, though nothing of importance happened at the system level (disk, CPU, RAM).
Versions involved are displayed below.
```shell
root@dns6-gp:~# dpkg -l | grep knot
ii knot-dnsutils 3.1.7-cznic.1~bullseye amd64 DNS clients provided with Knot DNS (kdig, knsupdate)
ii knot-resolver 5.5.0-cznic.1 amd64 caching, DNSSEC-validating DNS resolver
ii knot-resolver-module-http 5.3.1-1 amd64 HTTP module for Knot Resolver
ii knot-resolver-release 1.9-1 all Knot Resolver official upstream repositories
ii libknot12:amd64 3.1.7-cznic.1~bullseye amd64 DNS shared library from Knot DNS
```https://gitlab.nic.cz/knot/knot-dns/-/issues/492DDNS: when one update fails, whole bunch of other innocent updates is thrown ...2024-01-24T13:24:47+01:00Libor PeltanDDNS: when one update fails, whole bunch of other innocent updates is thrown awayFor the matter of performance, incoming DDNS requests are queued up, and from time to time, whole queue is processed at once.
To avoid partially-applied-and-then-failed updates, they are first processed into zone_update_t structure and ...For the matter of performance, incoming DDNS requests are queued up, and from time to time, whole queue is processed at once.
To avoid partially-applied-and-then-failed updates, they are first processed into zone_update_t structure and then, if all went well, applied to the zone.
The bug here is, that if one updates fails (e.g. attempt to update out-of-zone record), the process_bulk() function immediately aborts, and the rest of the updates, which had the bad luck of being queued together with the bad update, is thrown away.backburnerhttps://gitlab.nic.cz/knot/knot-dns/-/issues/915kxdpgun couldn't customize .edns_size2024-01-19T09:33:04+01:00perlangkxdpgun couldn't customize .edns_sizeI found that kxdpgun couldn't customize the .edns_size when I use it to test server with DNSSEC.
It was fixed to the value 1232 in line:145 of src/utils/kxdpgun/main.c
I have tried to add one option '-e <udp_payload_size>', it could sen...I found that kxdpgun couldn't customize the .edns_size when I use it to test server with DNSSEC.
It was fixed to the value 1232 in line:145 of src/utils/kxdpgun/main.c
I have tried to add one option '-e <udp_payload_size>', it could send the query as expected and handle the response where the data section is less than 1480 bytes, but couldn't regonize the response more than 1480.
The referece code is:
```
[root@localhost kxdpgun]# diff -Naur main.c_20240111 main.c
--- main.c_20240111 2023-12-13 14:21:33.000000000 +0800
+++ main.c 2024-01-11 09:49:05.000000000 +0800
@@ -1111,6 +1111,7 @@
" -v, --vlan <id> "SPACE"Add VLAN 802.1Q header with the given id.\n"
" -m, --mode <mode> "SPACE"Set XDP mode (auto, copy, generic).\n"
" -G, --qlog <path> "SPACE"Output directory for qlog (useful for QUIC only).\n"
+ " -e, --edns-size "SPACE"UDP payload size, default is 1232, range 513-4096\n"
" -h, --help "SPACE"Print the program help.\n"
" -V, --version "SPACE"Print the program version.\n"
"\n"
@@ -1230,6 +1231,7 @@
{ "remote-mac", required_argument, NULL, 'R' },
{ "vlan", required_argument, NULL, 'v' },
{ "mode", required_argument, NULL, 'm' },
+ { "edns-size", optional_argument, NULL, 'e' },
{ NULL }
};
@@ -1237,7 +1239,7 @@
bool default_at_once = true;
double argf;
char *argcp, *local_ip = NULL, *filename = NULL;
- while ((opt = getopt_long(argc, argv, "hVt:Q:b:rp:T::U::F:I:l:i:L:R:v:m:G:", opts, NULL)) != -1) {
+ while ((opt = getopt_long(argc, argv, "hVt:Q:b:rp:T::U::F:I:l:i:L:R:v:m:G:e:", opts, NULL)) != -1) {
switch (opt) {
case 'h':
print_help();
@@ -1375,6 +1377,16 @@
return false;
}
break;
+ case 'e':
+ assert(optarg);
+ arg = atoi(optarg);
+ if (arg > 512 && arg <= 4096) {
+ ctx->edns_size = arg;
+ } else {
+ ERR2("invalid edns size '%s'", optarg);
+ return false;
+ }
+ break;
default:
print_help();
return false;
```https://gitlab.nic.cz/knot/knot-dns/-/issues/917Error when using catalog-zone2024-01-17T10:45:39+01:00Martin HuněkError when using catalog-zoneWhen using catalog zone on master in generate mode, the server fails with:
error: config, file '/etc/knot/knot.conf', line 72, section 'zone[crb-m1-default-catalog.]' ('catalog-role' must correspond to configured 'catalog-zone')
The err...When using catalog zone on master in generate mode, the server fails with:
error: config, file '/etc/knot/knot.conf', line 72, section 'zone[crb-m1-default-catalog.]' ('catalog-role' must correspond to configured 'catalog-zone')
The error points to an empty line just after the catalog zone definition.
`template:
- id: default
storage: "/var/lib/knot/zones"
file: "%s.zone"
notify: koncentrator
dnssec-signing: off
# dnssec-policy: ecdsa
zonefile-sync: -1
zonefile-load: difference-no-serial
journal-content: all
catalog-role: member
catalog-zone: crb-m1-default-catalog.
acl: koncentrator_acl
zone:
- domain: crb-m1-default-catalog.
catalog-role: generate
acl: koncentrator_acl
- domain: example.com.
template: default
`
Troubles start after adding any zone to the catalog. When catalog-* in the template is commented out, the server starts without issue. When the catalog-role and catalog-zone are present, the server terminates with the above-mentioned error.
The idea behind the configuration is to have multiple catalog zones that are interpreted in another hidden master, which collects multiple catalog zones and generates new ones that will be distributed to public-facing slaves. However, it seems like we are stuck in round 1.https://gitlab.nic.cz/knot/knot-dns/-/issues/913`knotc zone-check` complains about missing zone file when using the `dnsproxy...2024-01-09T16:12:51+01:00Frantisek Sumsal`knotc zone-check` complains about missing zone file when using the `dnsproxy` moduleHey!
I'm playing with the `dnsproxy` `knotd` module and I can't seem to convince `knotc zone-check` that proxied zones don't need a zone file (even with the [example](https://www.knot-dns.cz/docs/3.0/html/modules.html#id2) from the docu...Hey!
I'm playing with the `dnsproxy` `knotd` module and I can't seem to convince `knotc zone-check` that proxied zones don't need a zone file (even with the [example](https://www.knot-dns.cz/docs/3.0/html/modules.html#id2) from the documentation):
```yaml
# vi: ts=2 sw=2 et:
server:
rundir: "/run/knot"
user: knot:knot
automatic-acl: on
listen: [ 127.0.0.1@53 ]
log:
- target: syslog
any: debug
database:
storage: "/var/lib/knot"
remote:
- id: hidden
address: 1.1.1.1
mod-dnsproxy:
- id: forward
remote: hidden
fallback: off
zone:
- domain: example.com
module: mod-dnsproxy/forward
```
```
# dig +short example.com
93.184.216.34
# knotc zone-check
error: [example.com.] failed to check zone file (not exists)
# journalctl -b -u knot.service -p info -o short-monotonic --no-hostname
...
[868919.867204] systemd[1]: Starting knot.service...
[868919.880164] knotc[2358390]: Configuration is valid
[868919.904823] knotd[2358393]: info: Knot DNS 3.3.1 starting
[868919.905080] knotd[2358393]: info: loaded configuration file '/etc/knot/knot.conf', mapsize 512 MiB
[868919.905135] knotd[2358393]: info: using UDP reuseport, incoming TCP Fast Open
[868919.905186] knotd[2358393]: info: binding to interface 127.0.0.1@53
[868919.908665] knotd[2358393]: info: loading 1 zones
[868919.908907] knotd[2358393]: info: [example.com.] zone will be loaded
[868919.909070] knotd[2358393]: info: starting server
[868919.909365] knotd[2358393]: error: [example.com.] failed to parse zone file '/var/lib/knot/example.com.zone' (not exists)
[868919.909437] knotd[2358393]: info: [example.com.] zone not found
[868919.909471] knotd[2358393]: error: [example.com.] zone event 'load' failed (not exists)
[868919.911882] knotd[2358393]: info: control, binding to '/run/knot/knot.sock'
[868919.911954] knotd[2358393]: info: server started in the foreground, PID 2358393
[868919.912183] systemd[1]: Started knot.service.
```
Is there any way to avoid this error, so I can still use `zone-check` to make sure the config is valid? This is with both `3.3.1` and `3.4.dev0+1704656692.81a57d9bf`.https://gitlab.nic.cz/knot/knot-dns/-/issues/585Allow patterns for zone definitions?2024-01-04T13:24:40+01:00Daniel BaumannAllow patterns for zone definitions?Hi,
instead of having to write lines like this for each and every zone...
- domain: example.org
template: whatever
...it would be nice to able to use wildcards/patterns, e.g.:
- domain: *
template: something
- domain: example-*....Hi,
instead of having to write lines like this for each and every zone...
- domain: example.org
template: whatever
...it would be nice to able to use wildcards/patterns, e.g.:
- domain: *
template: something
- domain: example-*.*
template: something-different
etc.
Regards,
Danielhttps://gitlab.nic.cz/knot/knot-dns/-/issues/910When adding a zone, the zone reload option in Knotc doesn't seem to support it2024-01-04T08:18:46+01:00hjlogzwWhen adding a zone, the zone reload option in Knotc doesn't seem to support itWhen knot was running normally, I added a zone file and added it to knot. conf, and then used knot to execute zone reload, but the result was not quite accurate.
knot.conf:
server:
listen: 0.0.0.0@53
listen: ::@53
...When knot was running normally, I added a zone file and added it to knot. conf, and then used knot to execute zone reload, but the result was not quite accurate.
knot.conf:
server:
listen: 0.0.0.0@53
listen: ::@53
zone:
- domain: example.com
storage: /var/lib/knot/zones/
file: example.com.zone
- domain: test.com
storage: /var/lib/knot/zones/
file: test.com.zone
log:
- target: stdout
any: info
knotc:
./knotc -s /usr/local/var/run/knot/knot.sock -f zone-reload test.com
the knotd shows "no such zone found":
2024-01-03T20:06:50+0800 info: [test.com.] control, received command 'zone-reload'
2024-01-03T20:06:50+0800 error: [test.com.] control, error (no such zone found)
So when adding a zone, must we use reload instead of the zone reload option to successfully add it?https://gitlab.nic.cz/knot/knot-dns/-/issues/828Improve additional RRs for delegating DNS records2024-01-02T15:10:25+01:00Jeremy SakladImprove additional RRs for delegating DNS recordsWhen responding to a query for a delegation record, Knot DNS generally tries to include the A/AAAA records of any targets it is authoritative for in the response. While this is helpful, there is room for improvement.
I've identified res...When responding to a query for a delegation record, Knot DNS generally tries to include the A/AAAA records of any targets it is authoritative for in the response. While this is helpful, there is room for improvement.
I've identified resource records that are relevant for any client making a query, along with the specifications describing their role. The general principle is that the nameserver SHOULD provide everything a client must need to make use of the record it asked for.
For the sake of brevity, I'm not including CNAMEs in the descriptions below: in all cases, they SHOULD be followed to their target RRset if Knot DNS is authoritative for it.
When attaching a record, Knot DNS SHOULD recursively add relevant records for it as well. This is particularly important when SVCB-compatible records are involved.
If there is room in the response, Knot SHOULD include authoritative NSEC/NSEC3 records where applicable, in keeping with [RFC 8198](https://www.rfc-editor.org/rfc/rfc8198).
Note that some of these behaviors are based on Internet Drafts.
# MX
## Specifications
* [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321#section-5)
* [RFC 7672](https://www.rfc-editor.org/rfc/rfc7672)
## Behavior
If no MX records exist in response to a query, Knot DNS SHOULD attach additional records based on the implicit MX record (that is, as if there was an MX record pointing to its own owner).
For each MX record, implicit or explicit, Knot DNS SHOULD attach:
* Any authoritative A records at `[exchange]`
* Any authoritative AAAA records at `[exchange]`
* Any authoritative TLSA records at `_25._tcp.[exchange]`
If response size is a concern, Knot DNS MAY attach records only for the exchanges with the lowest preference (that is, the highest priority) that it is authoritative for.
# NS
## Specifications
* [draft-ietf-dnsop-glue-is-not-optional-07](https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/07/)
* [draft-ietf-dnsop-svcb-https-11][draft-ietf-dnsop-svcb-https-11]
* [draft-ietf-dnsop-svcb-dane-00][draft-ietf-dnsop-svcb-dane-00]
## Behavior
**Knot DNS MUST include all authoritative A/AAAA records it has for `[nameserver]`.** If space allows, Knot DNS SHOULD also attach:
* Any authoritative SVCB records at `_dns.[nameserver]`
# SRV
## Specifications
* [RFC 2782](https://www.rfc-editor.org/rfc/rfc2782)
* [RFC 4255](https://www.rfc-editor.org/rfc/rfc4255)
* [RFC 7671](https://www.rfc-editor.org/rfc/rfc7671#section-6)
## Behavior
Iff the record has a [service] name of `ssh`, Knot DNS SHOULD attach:
* Any authoritative A records at `[target]`
* Any authoritative AAAA records at `[target]`
* Any authoritative SSHFP records at `[target]`
Otherwise, for each SRV record, Knot DNS SHOULD attach:
* Any authoritative A records at `[target]`
* Any authoritative AAAA records at `[target]`
* Any authoritative TLSA records at `_[port]._[proto].[target]`
Knot DNS MAY forgo including NSEC/NSEC3 records for services it does not know (likely based on a predefined list) to use TLSA records, as their nonexistence may not be relevant. Given the difficulty of maintaining such a list, it may be best to forgo them for everything besides SSH and skip the hassle entirely.
If response size is a concern, Knot DNS MAY attach records only for the exchanges with the lowest preference (that is, the highest priority) that it is authoritative for.
# SVCB/HTTPS/[any future SVCB-compatible record]
## Specifications
* [draft-ietf-dnsop-svcb-https-11][draft-ietf-dnsop-svcb-https-11]
* [draft-ietf-dnsop-svcb-dane-00][draft-ietf-dnsop-svcb-dane-00]
## Behavior
For a single random AliasMode record (unless that record has a [TargetName] of `.`), Knot DNS SHOULD attach:
* Any authoritative records of the same type at `[TargetName]`
If no AliasMode records are present, for each ServiceMode record (including those with a [TargetName] of `.`, where the [TargetName] is interpreted as the owner name of that record), Knot DNS SHOULD attach:
* Any authoritative A records at `[TargetName]`
* Any authoritative AAAA records at `[TargetName]`
* Any authoritative TLSA records at `_[port]._[ALPN-derived transport].[TargetName]`
In contrast to SRV records, Knot DNS SHOULD attempt to maintain a list of the default ports and transports for services and protocols, as well as any new tags. Specific behavior should be added for each use as appropriate: for example, if any are defined to not use TLSA records in the future, that SHOULD be left out.
**For the purpose of adding additional records, Knot DNS MUST ignore records that contain a mandatory tag it does not understand.**
If response size is a concern, Knot DNS MAY attach additional records only for ServiceMode records with the lowest [SvcPriority] (that is, the highest priority) that it is authoritative for.
[draft-ietf-dnsop-svcb-https-11]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/11/
[draft-ietf-dnsop-svcb-dane-00]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-dane/00/https://gitlab.nic.cz/knot/knot-dns/-/issues/898zone event load failed2023-12-22T07:31:58+01:00yuchunyunzone event load failedI have two knot instances A&B fetching axfr/ixfr from the same upstream C, and I will make knot-A backup for knot-A frequently (parameters: +nozonefile +nojournal +notimers +kaspdb +catalog +noquic), then copy each backup to knot-B and o...I have two knot instances A&B fetching axfr/ixfr from the same upstream C, and I will make knot-A backup for knot-A frequently (parameters: +nozonefile +nojournal +notimers +kaspdb +catalog +noquic), then copy each backup to knot-B and online restore. The error
```
2023-11-16T09:16:20+0800 error: [top.] zone event 'load' failed (value is out of range)
```
occasionally appeared in the knot-B log, and there must be a warning in the front of that log.
```
2023-11-16T09:16:17+0800 warning: [top.] zone file changed with decreased SOA serial
```
I don't know what caused this, may I ask how I can troubleshoot it