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/912JSON Schema for the configuration file2024-02-28T22:22:32+01:00Jakub JirutkaJSON Schema for the configuration fileSince the configuration format is based on YAML, it’s possible to describe it using a JSON schema. This would allow us to validate the configuration against the JSON schema and, even more interestingly, use it for auto-completion, inline...Since the configuration format is based on YAML, it’s possible to describe it using a JSON schema. This would allow us to validate the configuration against the JSON schema and, even more interestingly, use it for auto-completion, inline documentation and basic validation in any text editor that supports JSON schema for YAML (e.g. via the YAML Language Server).
I noticed that Knot Resolver already [provides JSON schema](https://knot-resolver.readthedocs.io/en/latest/config-overview.html#json-schema) for its new configuration format.
Can you please provide JSON schema for the Knot configuration format?https://gitlab.nic.cz/knot/knot-dns/-/issues/853khost ignores "search" in /etc/resolv.conf2023-09-28T04:58:59+02:00PSLLSPkhost ignores "search" in /etc/resolv.confI assume I see a bug in `khost`, like it ignores **search** directive in `/etc/resolv.conf`
```
$ khost --version
khost (Knot DNS), version 2.7.8
```
```
$ tail -4 /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search ...I assume I see a bug in `khost`, like it ignores **search** directive in `/etc/resolv.conf`
```
$ khost --version
khost (Knot DNS), version 2.7.8
```
```
$ tail -4 /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search home
```
I run local DNS/DHCP server for LAN and I use "private" domain "home". Local DNS server is at 192.168.222.1. Test with `host`, it works:
```
$ host -V
host 9.16.1-Ubuntu
```
```
$ host android-tablet2 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases:
android-tablet2.home is an alias for android-broken.home.
Host android-broken.home not found: 3(NXDOMAIN)
Host android-broken.home not found: 3(NXDOMAIN)
```
```
$ host android-tablet2.home 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases:
android-tablet2.home is an alias for android-broken.home.
Host android-broken.home not found: 3(NXDOMAIN)
Host android-broken.home not found: 3(NXDOMAIN)
```
`khost` fails when I do not specify domain:
```
$ khost android-tablet2.home 192.168.222.1
android-tablet2.home. is an alias for android-broken.home.
```
```
$ khost android-tablet2 192.168.222.1
Host android-tablet2. type A error: NXDOMAIN
Host android-tablet2. type AAAA error: NXDOMAIN
Host android-tablet2. type MX error: NXDOMAIN
```
---
Evidence that `/etc/resolv.conf` is ignored by `khost`:
```
$ strace host android-tablet2 192.168.222.1 2>&1 | grep etc
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY) = 6
```
```
$ strace khost android-tablet2 192.168.222.1 2>&1 | grep etc
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
stat("/etc/gnutls/config", 0x7ffce4583150) = -1 ENOENT (No such file or directory)
```https://gitlab.nic.cz/knot/knot-dns/-/issues/833Complete offline signing and AXFR for GeoIP2023-09-29T08:37:27+02:00Lukas LihotzkiComplete offline signing and AXFR for GeoIPCurrently, mod-geoip does support `policy: presigned_zone`, but the module still needs to sign the non-default RRsets on loading, so the ZSK key needs to be present on the server. It isn't obvious how to store other, non-default RRsets i...Currently, mod-geoip does support `policy: presigned_zone`, but the module still needs to sign the non-default RRsets on loading, so the ZSK key needs to be present on the server. It isn't obvious how to store other, non-default RRsets in a pre-signed zone file. Also, these non-default RRsets cannot be shared over AXFR, so secondaries cannot easily imitate the mod-geoip behavior of the primary.
I have thought about a solution that solves both problems: CASE records that wrap other RRs with a prepended case id string. Such CASE records can be stored in zone files and transmitted over AXFR, but are always unpacked for normal queries. An example from the mod-geoip documentation could be expressed like this with CASE records:
```
foo.example.com. CASE "CZ;Prague" CNAME cz.foo.example.com.
foo.example.com. CASE "US;Las Vegas" CNAME vegas.foo.example.net.
foo.example.com. CASE "US;*" CNAME us.foo.example.net.
foo.example.com. CNAME foo.example.net. ; default case
```
DNSSEC signing would handle CASE records specially and produce an RRSIG per case id that is also wrapped into a CASE record like this:
```
foo.example.com. CASE "CZ;Prague" RRSIG CNAME 5 3 86400 20030322173103 ( … )
foo.example.com. CASE "US;Las Vegas" RRSIG CNAME 5 3 86400 20030322173103 ( … )
foo.example.com. CASE "US;*" RRSIG CNAME 5 3 86400 20030322173103 ( … )
foo.example.com. RRSIG CNAME 5 3 86400 20030322173103 ( … ) ; default case
```
This would be similar to a proposal I made for PowerDNS (https://github.com/PowerDNS/pdns/issues/12597), where I also write about this idea in more detail. PowerDNS may accept an implementation of it. What do you think about this idea? Would you accept an implementation of this for Knot DNS?https://gitlab.nic.cz/knot/knot-dns/-/issues/675[feature request] add support for +trace to kdig2022-06-20T22:28:34+02:00hexchain[feature request] add support for +trace to kdigIt would be good if kdig can support `+trace`, like `dig +trace` or `drill -T`.
(It is a bit strange to me that this does not seem to be asked before.)It would be good if kdig can support `+trace`, like `dig +trace` or `drill -T`.
(It is a bit strange to me that this does not seem to be asked before.)https://gitlab.nic.cz/knot/knot-dns/-/issues/649[feature request] statistics file format2024-02-28T22:37:58+01:002bit[feature request] statistics file formatas in the description above, it would be nice, if we could choose the output file format for the statistics. I'm currently trying to write an exporter for SNMP instead of YAML, JSON would be much easier (there are already modules doing t...as in the description above, it would be nice, if we could choose the output file format for the statistics. I'm currently trying to write an exporter for SNMP instead of YAML, JSON would be much easier (there are already modules doing this) or maybe it is worth considering MIBS(-SNMP) as file formatJan Hákjan.hak@nic.czJan Hákjan.hak@nic.czhttps://gitlab.nic.cz/knot/knot-dns/-/issues/621Support IP2Location LITE Geolocation2020-11-10T14:22:30+01:00Ghost UserSupport IP2Location LITE GeolocationKnot DNS should consider to support the IP2Location LITE database because it is free and faster than other geolocation database.
Please visit https://lite.ip2location.com for the database and they have open-source library ready for inte...Knot DNS should consider to support the IP2Location LITE database because it is free and faster than other geolocation database.
Please visit https://lite.ip2location.com for the database and they have open-source library ready for integration.https://gitlab.nic.cz/knot/knot-dns/-/issues/475Support for CNAME at the zone root2022-03-31T23:28:20+02:00Ghost UserSupport for CNAME at the zone rootThe blog post [Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root](https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/) by CloudFlare describes a technique for having a CNAM...The blog post [Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root](https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/) by CloudFlare describes a technique for having a CNAME record on the root of a zone. This feature is very powerfull for cloud services providing service records on the root of their service zone. Having a feature like this in Knot would allow records like:
```
$ORIGIN myservice.net.
@ IN CNAME mycloudservice.net.
```
What do others think about this feature supported by Knot? Or a similar form to have the possibility for CNAMEs at the root, like ALIAS record type as DNSimple is doing it?