Knot DNS issueshttps://gitlab.nic.cz/knot/knot-dns/-/issues2024-02-16T13:49:37+01:00https://gitlab.nic.cz/knot/knot-dns/-/issues/920kzonecheck should optionally warn for the use of implicit labels2024-02-16T13:49:37+01:00Daniel Kahn Gillmorkzonecheck should optionally warn for the use of implicit labelsAn "implicit label" in a zonefile is where the first value (the label) of a record is omitted, and it inherits from the previous record. Maybe there's a better name for that that i'm unaware of.
Implicit labels are a potential footgun, ...An "implicit label" in a zonefile is where the first value (the label) of a record is omitted, and it inherits from the previous record. Maybe there's a better name for that that i'm unaware of.
Implicit labels are a potential footgun, because reordering of the zonefile is likely to cause them to be remapped.
I was recently burned by making this mistake. ☹
It would be great if i could ask kzonecheck to warn me when there are any implicit labels in a zonefile, for example, by adding a `--strict` option, or a `--no-implicit-labels` option, or perhaps just by emitting a warning when placed in `--verbose` mode.https://gitlab.nic.cz/knot/knot-dns/-/issues/723knot_dname_cmp is not comparing null octets correctly2021-06-15T11:12:07+02:00Buffrrknot_dname_cmp is not comparing null octets correctlyThis name `hello\000.dev.` is greater than `test.hello.dev.` according to canonical DNS Name Order (RFC4034 section 6.1 ).
```c
knot_dname_t *d1 = knot_dname_from_str_alloc("test.hello.dev.");
knot_dname_t *d2 = knot_dname_from_str_all...This name `hello\000.dev.` is greater than `test.hello.dev.` according to canonical DNS Name Order (RFC4034 section 6.1 ).
```c
knot_dname_t *d1 = knot_dname_from_str_alloc("test.hello.dev.");
knot_dname_t *d2 = knot_dname_from_str_alloc("hello\\000.dev.");
printf("%d\n", knot_dname_cmp(d1, d2)); // output: 116
// doesn't happen with \001
d2 = knot_dname_from_str_alloc("hello\\001.dev.");
printf("%d\n", knot_dname_cmp(d1, d2)); // output: -1
```
This was causing issues with NSEC validation in knot resolver which I mentioned on gitter chat.Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-dns/-/issues/710Geo module of knot-3.0.1 does't support txt escape2021-04-05T09:16:28+02:00mscbgGeo module of knot-3.0.1 does't support txt escapeI want to configure a txt record like "a\"d\"b", but it don't work in geo module. Also, I find some other escape don't work either (https://www.rfc-editor.org/rfc/rfc1464.txt). Any bugs?
"a\"d\"b" means " a \ " d \ " b "I want to configure a txt record like "a\"d\"b", but it don't work in geo module. Also, I find some other escape don't work either (https://www.rfc-editor.org/rfc/rfc1464.txt). Any bugs?
"a\"d\"b" means " a \ " d \ " b "https://gitlab.nic.cz/knot/knot-dns/-/issues/656Compression of names in RDATA2019-11-16T13:42:26+01:00Anand BuddhdevCompression of names in RDATAI've just noticed that Knot 2.8.4 doesn't compress names in the RDATA of a response. Mostly this is not a problem. However, there is one special query, where this behaviour results in a sub-optimal response. This is the priming query aga...I've just noticed that Knot 2.8.4 doesn't compress names in the RDATA of a response. Mostly this is not a problem. However, there is one special query, where this behaviour results in a sub-optimal response. This is the priming query against a root name server (without EDNS). Whereas BIND and NSD both return a priming response containing 15 glue records, Knot only returns 4 glue records, because it has no more space left for the others. This does not break anything, but a resolver has to issue several follow-up queries to obtain the remaining A and AAAA records of the root name servers.