Knot DNS issueshttps://gitlab.nic.cz/knot/knot-dns/-/issues2024-02-28T22:22:32+01:00https://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/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/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?