Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2018-11-12T16:15:57+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/58dnssec bug: resolver fails to validate answers2018-11-12T16:15:57+01:00Ondřej Surýdnssec bug: resolver fails to validate answersThis is actually a validator bug, that's why it retries every time. We can discuss how much effort should resolver do when it's fixed:
```
[plan] plan 'www.cmu.edu.' type 'A'
[plan] plan 'cmu.edu.' type 'DNSKEY'
[iter] <= rco...This is actually a validator bug, that's why it retries every time. We can discuss how much effort should resolver do when it's fixed:
```
[plan] plan 'www.cmu.edu.' type 'A'
[plan] plan 'cmu.edu.' type 'DNSKEY'
[iter] <= rcode: NOERROR
[vldr] <= parent: updating DNSKEY
[vldr] <= answer valid, OK
[iter] <= rcode: NOERROR
[vldr] <= couldn't validate RRSIGs
```
One of the nameservers for cmu.edu is misconfigured and returns `REFUSED`:
```
$ dig IN A www.cmu.edu @ny-server-03.net.cmu.edu.
;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 61298
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; www.cmu.edu. IN A
;; Received 29 B
;; Time 2016-04-15 09:13:04 CEST
;; From 38.96.147.4@53(UDP) in 98.5 ms
```
kresd should try harder and not return `REFUSED`, but retry with different nameservers.
```
$ dig IN A www.cmu.edu @127.0.0.1
;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 60007
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; www.cmu.edu. IN A
;; Received 29 B
;; Time 2016-04-15 09:13:46 CEST
;; From 127.0.0.1@53(UDP) in 165.3 ms
```
Grigorii DemidovGrigorii Demidovhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/41Program received signal SIGSEGV, Segmentation fault. 0x00007ffff66b48ed in ??...2022-04-08T16:14:00+02:00Ondřej SurýProgram received signal SIGSEGV, Segmentation fault. 0x00007ffff66b48ed in ?? () from /lib/x86_64-linux-gnu/libc.so.6Version v1.0.0-beta1-96-gc7e8224
And it's something in the config as it doesn't crash when config is empty:
config:
```
modules = {
view = 'true',
stats = 'true',
cachectl = 'true',
dns64 = '2...Version v1.0.0-beta1-96-gc7e8224
And it's something in the config as it doesn't crash when config is empty:
config:
```
modules = {
view = 'true',
stats = 'true',
cachectl = 'true',
dns64 = '2001:1488:ffff:64:ffff:ffff::',
tinyweb = {
addr = '127.0.0.1:8053',
geoip = '/root'
}
}
```
```
#0 0x00007ffff66b48ed in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x00007ffff6d0bd92 in ?? () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
No symbol table info available.
#2 0x00007ffff6d0d0aa in ?? () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
No symbol table info available.
#3 0x00007ffff6cd7a88 in ?? () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
No symbol table info available.
#4 0x00007ffff6d1af60 in lua_pcall () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
No symbol table info available.
#5 0x000000000041049f in l_ffi_call (argc=2, L=0x40000378) at daemon/ffimodule.c:84
status = <optimized out>
#6 l_ffi_layer_begin (ctx=0x7fffffffe2e0, module_param=<optimized out>) at daemon/ffimodule.c:153
cb_slot = <optimized out>
L = 0x40000378
#7 0x0000000000414ab8 in resolve_query (packet=0x6a07a0, request=0x6a07a0) at lib/resolve.c:390
layer = {node = {next = 0x0, prev = 0x0}, state = 2, mm = 0x0, data = 0x6a07a0, api = 0x662640}
mod = <optimized out>
i = 4
rplan = 0x6a0800
qtype = <optimized out>
negative_anchors = 0x7fffffffea20
trust_anchors = 0x7fffffffea00
answer = <optimized out>
qname = <optimized out>
qclass = <optimized out>
qry = 0x6a2b90
#8 kr_resolve_consume (request=request@entry=0x6a07a0, src=src@entry=0x0, packet=packet@entry=0x6965b0) at lib/resolve.c:407
rplan = 0x6a0800
ctx = 0x7fffffffe9f0
qry = <optimized out>
tried_tcp = <optimized out>
#9 0x000000000040de58 in qr_task_step (task=0x6a07a0, packet_source=packet_source@entry=0x0, packet=0x6965b0) at daemon/worker.c:449
sock_type = -1
state = <optimized out>
choice = <optimized out>
#10 0x000000000040e5d8 in worker_resolve (worker=worker@entry=0x7ffff7f95010, query=<optimized out>, options=options@entry=0, on_complete=<optimized out>, baton=<optimized out>)
at daemon/worker.c:616
task = <optimized out>
#11 0x000000000040fc0c in wrk_resolve (L=0x40000378) at daemon/bindings.c:658
worker = 0x7ffff7f95010
pkt = 0x6965b0
dname = '\000' <repeats 80 times>, "\270\003\000@\000\000\000\000x\003\000@\000\000\000\000\220\344\377\377\377\177\000\000\b\032\003@\000\000\000\000\210\345\001@\000\000\000\000\310\324\000@\000\000\000\000HN\001@\000\000\000\000\200\345\001@\000\000\000\000\324\344\377\377\377\177\000\000_\317\320\366\377\177\000\000X\237\000@\000\000\000\000\330\344\377\377\377\177\000\000\210\344\377\377\377\177\000\000\204\344\377\377\377\177\000\000x\003\000@\001\000\000\000"...
rrtype = 2
rrclass = <optimized out>
ret = 0
options = 0
#12 0x00007ffff6cd7a88 in ?? () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
No symbol table info available.
#13 0x00007ffff6d1af60 in lua_pcall () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
No symbol table info available.
#14 0x000000000040c11c in engine_pcall (L=<optimized out>, argc=<optimized out>) at daemon/engine.c:469
No locals.
#15 0x000000000040fe03 in execute_callback (L=0x40000378, argc=1) at daemon/bindings.c:476
ret = <optimized out>
#16 0x000000000040d611 in qr_task_complete (handle=<optimized out>) at daemon/worker.c:280
task = 0x697750
worker = 0x7ffff7f95010
#17 0x00007ffff7787698 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#18 0x00000000004087c6 in run_worker (engine=0x7fffffffe9f0, loop=0x7ffff799f980) at daemon/main.c:193
sock_file = 0x62f250 "tty/29364"
pipe = {data = 0x7fffffffe9f0, loop = 0x7ffff799f980, type = UV_NAMED_PIPE, close_cb = 0x0, handle_queue = {0x697878, 0x662270}, u = {fd = 5, reserved = {0x5, 0x17, 0x7ffff7feacb8,
0x7ffff7de55ce}}, next_closing = 0x0, flags = 24576, write_queue_size = 0, alloc_cb = 0x0, read_cb = 0x0, connect_req = 0x0, shutdown_req = 0x0, io_watcher = {cb = 0x7ffff7790540,
pending_queue = {0x7fffffffe970, 0x7fffffffe970}, watcher_queue = {0x7fffffffe980, 0x7fffffffe980}, pevents = 1, events = 1, fd = 21}, write_queue = {0x7fffffffe9a0, 0x7fffffffe9a0},
write_completed_queue = {0x7fffffffe9b0, 0x7fffffffe9b0}, connection_cb = 0x411010 <tty_accept>, delayed_error = 0, accepted_fd = -1, queued_fds = 0x0, ipc = 0,
pipe_fname = 0x62f3f0 "tty/29364"}
#19 main (argc=<optimized out>, argv=<optimized out>) at daemon/main.c:350
forks = <optimized out>
addr_set = {at = 0x648470, len = 2, cap = <optimized out>}
keyfile = 0x6289c0 <keyfile_buf> "/usr/share/dns/root.key"
config = 0x0
keyfile_buf = "/usr/share/dns/root.key", '\000' <repeats 4073 times>
c = <optimized out>
li = 0
ret = 0
opts = {{name = 0x42000d "addr", has_arg = 1, flag = 0x0, val = 97}, {name = 0x41e96c "config", has_arg = 1, flag = 0x0, val = 99}, {name = 0x420422 "keyfile", has_arg = 1, flag = 0x0,
val = 107}, {name = 0x42042a "forks", has_arg = 1, flag = 0x0, val = 102}, {name = 0x41e9ae "verbose", has_arg = 0, flag = 0x0, val = 118}, {name = 0x420430 "version", has_arg = 0,
flag = 0x0, val = 86}, {name = 0x41e99b "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
loop = 0x7ffff799f980
sigint = {data = 0x7ffff7feacb8, loop = 0x7ffff799f980, type = UV_SIGNAL, close_cb = 0x97a26e6c, handle_queue = {0x7fffffffe760, 0x7ffff799fa50}, u = {fd = -134304584, reserved = {
0x7ffff7feacb8, 0x7ffff7de55ce, 0x7ffff7ff8160, 0x7fffffffe720}}, next_closing = 0x0, flags = 24576, signal_cb = 0x410fd0 <signal_handler>, signum = 2, tree_entry = {rbe_left = 0x0,
rbe_right = 0x7fffffffe740, rbe_parent = 0x0, rbe_color = 0}, caught_signals = 0, dispatched_signals = 0}
sigterm = {data = 0x7ffff5ec1438, loop = 0x7ffff799f980, type = UV_SIGNAL, close_cb = 0x1000000ab, handle_queue = {0x6616e0, 0x7fffffffe6c0}, u = {fd = -5952, reserved = {0x7fffffffe8c0,
0x7ffff7de4c5c, 0x7fffffffe8e8, 0xd82b830}}, next_closing = 0x0, flags = 24576, signal_cb = 0x410fd0 <signal_handler>, signum = 15, tree_entry = {rbe_left = 0x0, rbe_right = 0x0,
rbe_parent = 0x7fffffffe6a0, rbe_color = 1}, caught_signals = 0, dispatched_signals = 0}
pool = {ctx = 0x648530, alloc = 0x411830 <mp_alloc>, free = 0x0}
engine = {resolver = {options = 0, opt_rr = 0x6485a0, trust_anchors = {root = 0x634f30, malloc = 0x411e50 <malloc_std>, free = 0x411e40 <free_std>, baton = 0x0}, negative_anchors = {
root = 0x0, malloc = 0x411e50 <malloc_std>, free = 0x411e40 <free_std>, baton = 0x0}, root_hints = {name = 0x6485d8 "", nsset = {root = 0x6486a1, malloc = 0x7ffff7bcb7b0 <mm_alloc>,
free = 0x7ffff7bcb7d0 <mm_free>, baton = 0x7fffffffe680}, key = 0x0, trust_anchor = 0x0, parent = 0x0, pool = 0x7fffffffe680}, cache = {db = 0x648cb8, api = 0x7ffff7dda300,
stats = {hit = 26, miss = 2, insert = 2, delete = 0, txn_read = 1, txn_write = 3}}, cache_rtt = 0x649550, cache_rep = 0x659590, modules = 0x7fffffffeaf8, pool = 0x7fffffffe680},
net = {loop = 0x7ffff799f980, endpoints = {root = 0x62b911, malloc = 0x411e50 <malloc_std>, free = 0x411e40 <free_std>, baton = 0x0}}, modules = {at = 0x662750, len = 9, cap = 10},
storage_registry = {at = 0x661930, len = 1, cap = 5}, pool = 0x7fffffffe680, L = 0x40000378}
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/876manager: API: cache clearance implementation via HTTP API2024-02-15T13:38:42+01:00Aleš Mrázekmanager: API: cache clearance implementation via HTTP APIClearing the resolvers cache is possible by connecting to running `kresd` using its unix domain socket and calling [cache.clear()](https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-cache.html#cache.clear).
Starting with ver...Clearing the resolvers cache is possible by connecting to running `kresd` using its unix domain socket and calling [cache.clear()](https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-cache.html#cache.clear).
Starting with version 6, it would be nice to be able to clear the cache via the HTTP management API and the `kresctl` tool.
For example:
```bash
$ kresctl cache-clear # like 'cache.clear()', removes max. 100 records by default
$ kresctl cache-clear --name example.net. # and so on with other 'cache.clear()' parameters
```6.1.0https://gitlab.nic.cz/knot/knot-resolver/-/issues/742TLS: use GNUTLS_NO_TICKETS_TLS122022-05-20T09:39:49+02:00Vladimír Čunátvladimir.cunat@nic.czTLS: use GNUTLS_NO_TICKETS_TLS12It's a new [feature](https://gitlab.com/gnutls/gnutls/-/merge_requests/1475) that will be part of gnutls > 3.7.4. With TLS 1.2, session resumption weakens privacy guarantees too much ([explanation](https://gitlab.com/gnutls/gnutls/-/mer...It's a new [feature](https://gitlab.com/gnutls/gnutls/-/merge_requests/1475) that will be part of gnutls > 3.7.4. With TLS 1.2, session resumption weakens privacy guarantees too much ([explanation](https://gitlab.com/gnutls/gnutls/-/merge_requests/1475)), so it's better avoided – at least by default.https://gitlab.nic.cz/knot/knot-resolver/-/issues/617doh2: send cache-control header2020-11-27T12:49:25+01:00Tomas Krizekdoh2: send cache-control headerAs of version 5.2.0, DoH(2) doesn't send `cache-control` header with TTL.As of version 5.2.0, DoH(2) doesn't send `cache-control` header with TTL.https://gitlab.nic.cz/knot/knot-resolver/-/issues/616doh2: process input headers2021-05-25T14:44:37+02:00Tomas Krizekdoh2: process input headersAs of 5.2.0, the DoH(2) implementation ignores all headers (including some pseudoheaders).
At least some (pseudo)headers should be processed, e.g.:
- `content-type`
- `:path` (currently, any endpoint answers to DoH queries)
There could...As of 5.2.0, the DoH(2) implementation ignores all headers (including some pseudoheaders).
At least some (pseudo)headers should be processed, e.g.:
- `content-type`
- `:path` (currently, any endpoint answers to DoH queries)
There could also be a mechanism for modules to request certain headers that would be passed along with a request.Tomas KrizekTomas Krizekhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/527fine-grained logging2021-07-29T14:01:56+02:00Petr Špačekfine-grained loggingCurrent logging configuration is just one bit: verbosity on/off. This makes it hard to monitor and debug large instances.
Let's collect ideas for improvement in this ticket:
- [x] per-request logging - ability to run single request with...Current logging configuration is just one bit: verbosity on/off. This makes it hard to monitor and debug large instances.
Let's collect ideas for improvement in this ticket:
- [x] per-request logging - ability to run single request with verbose logging is very handy for debugging. We have a prototype in `/trace` endpoint in HTTP module but this module does not log everything for a given request, and also it should be much easier to use than full HTTP.
- [x] per-type logging - it might be handy to enable/disable certain types of logging, e.g. control socket log might be too noisy if there is enough API traffic etc.
- [x] fine grained log levels exposed to the logging system - external log collectors need to know if given message is debug/info/error etc.
- [ ] structured logging? log some rudimentary metadata in structured form - e.g. query name + type + rcode? This might be very handy for network operations centers etc.https://gitlab.nic.cz/knot/knot-resolver/-/issues/516Feature request to add a new option to meson.build2020-08-19T13:29:10+02:00Jan PavlinecFeature request to add a new option to meson.buildIt would be nice to have a meson option to change "knot-resolver" to something else.
see https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/meson.build#L46It would be nice to have a meson option to change "knot-resolver" to something else.
see https://gitlab.labs.nic.cz/knot/knot-resolver/blob/master/meson.build#L46https://gitlab.nic.cz/knot/knot-resolver/-/issues/510prometheus and graphite metrics are missing some cache stats2020-08-06T11:40:28+02:00Vladimír Čunátvladimir.cunat@nic.czprometheus and graphite metrics are missing some cache statsFrom cache it only exports [`cache.stats()`](https://knot-resolver.readthedocs.io/en/stable/daemon.html#c.cache.stats), but that only counts operations. Ideas:
- [x] `cache.count()` is quite an important number
- [x] utilized LMDB siz...From cache it only exports [`cache.stats()`](https://knot-resolver.readthedocs.io/en/stable/daemon.html#c.cache.stats), but that only counts operations. Ideas:
- [x] `cache.count()` is quite an important number
- [x] utilized LMDB size in bytes might be even more interesting (computed by GC anyway), and could be paired to `cache.current_size`
_Reported [on gitter](https://gitter.im/CZ-NIC/knot-resolver?at=5d7bd29d5d40aa0d7d2e7725)._https://gitlab.nic.cz/knot/knot-resolver/-/issues/442hints.ttl property for hosts files2019-01-29T15:48:13+01:00Ghost Userhints.ttl property for hosts filesIs there a possibility implementing hints.ttl like property, having TTL for hosts file records, like dnsmasq (local-ttl=) has?Is there a possibility implementing hints.ttl like property, having TTL for hosts file records, like dnsmasq (local-ttl=) has?https://gitlab.nic.cz/knot/knot-resolver/-/issues/435missing support for validUntil attr in root-anchors.xml2019-01-09T15:44:10+01:00Petr Špačekmissing support for validUntil attr in root-anchors.xmlWe should implement missing attributes from https://tools.ietf.org/html/rfc7958#section-2.1.1
Options at the moment seem to be add:
- XML parsing library
- CMS parsing library
- another hacky regex
None of these options is nice.
In an...We should implement missing attributes from https://tools.ietf.org/html/rfc7958#section-2.1.1
Options at the moment seem to be add:
- XML parsing library
- CMS parsing library
- another hacky regex
None of these options is nice.
In any case we have inherent problem with parsing date, because Lua `os` library does not provide an easy way to parse full ISO date format. We can either:
- find full fledged Lua library to parse such string
- call `strptime` in C (maybe easiest?)
- use a hack and hardcode UTC offset (and check that in regex)2019 Q12019-01-17https://gitlab.nic.cz/knot/knot-resolver/-/issues/432module API: add ability not to respond2022-02-28T11:58:55+01:00Petr Špačekmodule API: add ability not to respondIt would be useful for rate-limiting but we need to investigate how hard it would be, and if the difference is big enough when compared to an empty answer.It would be useful for rate-limiting but we need to investigate how hard it would be, and if the difference is big enough when compared to an empty answer.https://gitlab.nic.cz/knot/knot-resolver/-/issues/418extend C module API with engine access2022-01-12T13:52:53+01:00Petr Špačekextend C module API with engine accessRight now C modules have no way to access `struct engine->net` in their non-property methods. Engine can be accessed only from property methods, which is very inconvenient for modules without properties.
It can be worked around using tr...Right now C modules have no way to access `struct engine->net` in their non-property methods. Engine can be accessed only from property methods, which is very inconvenient for modules without properties.
It can be worked around using trick like this, but it's ugly:
```
dot_enable(void *env, struct kr_module *module, const char *args) {
module->data = env;
}
and calling this from config using:
modules.load('dot')
dot.enable()
```
I think we should extend the API in way which provides access to engine from all methods. Maybe we could add engine pointer to struct kr_module or something like that.https://gitlab.nic.cz/knot/knot-resolver/-/issues/408EDNS keepalive on server side2018-11-13T20:50:52+01:00Petr ŠpačekEDNS keepalive on server sideMinimalistic EDNS keepalive implementation - applicable only on TCP/TLS connections:
- [x] server side - If keepalive option is present in query, always reply with constant timeout value = max idle time
Client side needs way more experi...Minimalistic EDNS keepalive implementation - applicable only on TCP/TLS connections:
- [x] server side - If keepalive option is present in query, always reply with constant timeout value = max idle time
Client side needs way more experimentation to find out behavior which is reasoble with DNS over TLS and others so it is not in scope of this ticket.https://gitlab.nic.cz/knot/knot-resolver/-/issues/383limit maximum session resumption time2018-10-31T15:31:41+01:00Petr Špačeklimit maximum session resumption timeTLS session key which is reused for sessions resumption allows the TLS server to track the TLS client even if the client changes its IP address.
We need to think about ways how we can limit server's ability to track whole client DNS his...TLS session key which is reused for sessions resumption allows the TLS server to track the TLS client even if the client changes its IP address.
We need to think about ways how we can limit server's ability to track whole client DNS history.
The same logic applies to TCP Fast Open (once we support it on the client side).https://gitlab.nic.cz/knot/knot-resolver/-/issues/370support negative ACLs2024-02-28T12:06:31+01:00Petr Špačeksupport negative ACLsAn operator from CSNOG 1 asked for ability to use negative ACL, i.e. something like
```
view:notaddr('10.0.0.1', policy.suffix(policy.TC, {'\7example\3com'}))
```
to apply policy to all clients **not** having IP address `10.0.0.1`.
Ques...An operator from CSNOG 1 asked for ability to use negative ACL, i.e. something like
```
view:notaddr('10.0.0.1', policy.suffix(policy.TC, {'\7example\3com'}))
```
to apply policy to all clients **not** having IP address `10.0.0.1`.
Question here is how it should be configured and if we should extract
ACL logic to some other place. Related: #368https://gitlab.nic.cz/knot/knot-resolver/-/issues/368DNS64 for subnets2021-08-25T13:32:55+02:00Petr ŠpačekDNS64 for subnetsRIPE NCC and Ondřej Caletka expressed demand for ability to limit which subnets are covered by DNS64.
We need to think whether this should be generalized to some form of ACL like in BIND, or if another one-off for DNS64 is okay.
RIPE N...RIPE NCC and Ondřej Caletka expressed demand for ability to limit which subnets are covered by DNS64.
We need to think whether this should be generalized to some form of ACL like in BIND, or if another one-off for DNS64 is okay.
RIPE NCC wanted the equivalent of the Bind ACL options:
```
acl nat64-users {
2001:67c:64:49::/64;
};
options {
dns64 64:ff9b::/96 {
clients { nat64-users; };
};
};
```
Their own hack used this config:
```
-- RIPE NCC DNS64 config
ripencc.dns64_proxy('64:ff9b::')
ripencc.dns64_subnet('2001:67c:64:49::/64')
```Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/362EDNS-Client-Subnet (ECS) Support in Knot Resolver2024-02-26T19:32:26+01:00ImanEDNS-Client-Subnet (ECS) Support in Knot ResolverHi All,
Is EDNS-Client-Subnet (ECS) already supported in Knot Resolver? if yes how much this feature is configurable?
For example, could we configure in which queries to authoritative servers should knot resolver append ECS option?
Th...Hi All,
Is EDNS-Client-Subnet (ECS) already supported in Knot Resolver? if yes how much this feature is configurable?
For example, could we configure in which queries to authoritative servers should knot resolver append ECS option?
Thanks in advance.https://gitlab.nic.cz/knot/knot-resolver/-/issues/359CNAME breaks DS queries if CNAME is at apex (non-compliant auth side)2020-04-27T16:47:06+02:00Petr ŠpačekCNAME breaks DS queries if CNAME is at apex (non-compliant auth side)kresd replies incorrectly for `name.example. DS` queries if `name.example.` has CNAME at apex `name.example.`.
This seems to affect only non-compliant servers which allow CNAME at apex. **Such zones are illegal according to https://tool...kresd replies incorrectly for `name.example. DS` queries if `name.example.` has CNAME at apex `name.example.`.
This seems to affect only non-compliant servers which allow CNAME at apex. **Such zones are illegal according to https://tools.ietf.org/html/rfc1034#section-3.6.2.**
This bug is present in 2.3.0 and breaks validating forwarders which point to kresd. Related: #153
Affected domain: ucarecdn.com
DNSViz: http://dnsviz.net/d/ucarecdn.com/WvYPzQ/dnssec/
DNSViz mirror [dnsviz-ucarecdn.pdf](/uploads/78e3058f79b4f774bd852dc1221bdff2/dnsviz-ucarecdn.pdf)
Second affected domain (with wildcard): coder.show
DNSViz: http://dnsviz.net/d/coder.show/WwVyFQ/dnssec/
DNSViz mirror [dnsviz-coder-show.pdf](/uploads/a2fb42ca1098b9ed26ec9b762e57ded2/dnsviz-coder-show.pdf)
Steps to reproduce:
1. dig +dnssec coder.show A
2. dig +dnssec coder.show DS
https://gitlab.nic.cz/knot/knot-resolver/-/issues/331Resolver allows cache snooping by default2019-09-18T11:26:57+02:00Marek VavrusaResolver allows cache snooping by defaultBy default all requests without the RD bit are satisfied from cache or SERVFAIL.
This can be a privacy issue in smaller networks as it allows checking whether a certain name has been asked or not.
Unbound for example doesn't enable `allo...By default all requests without the RD bit are satisfied from cache or SERVFAIL.
This can be a privacy issue in smaller networks as it allows checking whether a certain name has been asked or not.
Unbound for example doesn't enable `allow_snoop` by default, so it'd be nice to do that (or at least have an option to turn it off) https://www.unbound.net/documentation/unbound.conf.html