Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2022-02-06T18:46:56+01:00https://gitlab.nic.cz/knot/knot-resolver/-/issues/720Control sockets on relative paths fails2022-02-06T18:46:56+01:00Vaclav SraierControl sockets on relative paths failsWith this config:
```
local path = '/tmp/control/1'
local ok, err = pcall(net.listen, path, nil, { kind = 'control' })
if not ok then
log_warn(ffi.C.LOG_GRP_NETWORK, 'bind to '..path..' failed '..err)
end
```
everything works perfectl...With this config:
```
local path = '/tmp/control/1'
local ok, err = pcall(net.listen, path, nil, { kind = 'control' })
if not ok then
log_warn(ffi.C.LOG_GRP_NETWORK, 'bind to '..path..' failed '..err)
end
```
everything works perfectly.
This config though:
```
local path = './control/1'
local ok, err = pcall(net.listen, path, nil, { kind = 'control' })
if not ok then
log_warn(ffi.C.LOG_GRP_NETWORK, 'bind to '..path..' failed '..err)
end
```
Fails with this error message:
```
Feb 05 23:03:41 dingo kresd[169462]: [net ] bind to './control/1@53' (TCP): Invalid argument
Feb 05 23:03:41 dingo kresd[169462]: [net ] bind to ./control/1 failed error occurred here (config filename:lineno is at the bottom, if config is involved):
Feb 05 23:03:41 dingo kresd[169462]: stack traceback:
Feb 05 23:03:41 dingo kresd[169462]: [C]: at 0x556c94d0eae0
Feb 05 23:03:41 dingo kresd[169462]: [C]: in function 'pcall'
Feb 05 23:03:41 dingo kresd[169462]: kresd_1.conf:144: in main chunk
Feb 05 23:03:41 dingo kresd[169462]: ERROR: net.listen() failed to bind
```
It looks like the `kind` argument is completely ignored and defaults are assumed (UDP + TCP on port 53).
EDIT: Tested on `a2c339a57b8a6fb1c6bbaa83ed4bfdbe742a5fd0` (HEAD of `manager` branch)https://gitlab.nic.cz/knot/knot-resolver/-/issues/687serve_stale module doesn't provide stale answers when auths are unresponsive2022-03-09T11:16:31+01:00Tomas Krizekserve_stale module doesn't provide stale answers when auths are unresponsiveAs of version 5.4.2, `serve_stale` module doesn't work when auth servers are unresponsive (which is the typical case with network issues). The server selection algorithm tries very hard to resolve the request by re-trying different auth ...As of version 5.4.2, `serve_stale` module doesn't work when auth servers are unresponsive (which is the typical case with network issues). The server selection algorithm tries very hard to resolve the request by re-trying different auth servers and increasing their allowed timeouts, until the request ultimately times out and returns SERVFAIL instead of a stale answer.
If the auth servers are reachable but REFUSE to respond, the serve_stale module works as expected (that was our former test case with deckard).
Some notes about possible resolution:
- to be useful for clients, the stale answer should be provided quickly enough ([RFC 8767.5](https://datatracker.ietf.org/doc/html/rfc8767#section-5) suggests sending stale answer after 1.8s). The timeout used for serve_stale should ideally be configurable.
- the request resolution should keep going even after the stale answer is sent to the client to refresh data from slower auth severs (possible option: spawn a new duplicate internal request after providing the stale answer?)
- server selection should have a configurable time limit that is respected and allows serve_stale to activate in time
- the server selection time limit shouldn't be used unless serve_stale module is loaded _and_ there is a possible stale answer in the cachehttps://gitlab.nic.cz/knot/knot-resolver/-/issues/684ANSWER section not empty on SERVFAIL2021-11-04T10:58:48+01:00Tomas KrizekANSWER section not empty on SERVFAILIn some cases, the ANSWER section contains (unvalidated) data while the request ends with SERVFAIL.
In my specific conditions, the issue seems reproducible when:
- cache is clear
- IPv6 isn't available, but isn't turned off with net.ipv...In some cases, the ANSWER section contains (unvalidated) data while the request ends with SERVFAIL.
In my specific conditions, the issue seems reproducible when:
- cache is clear
- IPv6 isn't available, but isn't turned off with net.ipv6
- server selection chooses specific servers (and typically chooses the non-functioning IPv6 ones)
```
$ kdig @::1 -p 5553 +timeout=16 +edns signotincepted.bad-dnssec.wb.sidnlabs.nl
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 6998
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; QUESTION SECTION:
;; signotincepted.bad-dnssec.wb.sidnlabs.nl. IN A
;; ANSWER SECTION:
signotincepted.bad-dnssec.wb.sidnlabs.nl. 3600 IN A 94.198.159.39
;; Received 85 B
;; Time 2021-11-04 10:45:32 CET
;; From ::1@5553(UDP) in 10027.7 ms
```
See attached [log.txt](/uploads/8d1aa54458e26860a5d0f4e36d105cad/log.txt)https://gitlab.nic.cz/knot/knot-resolver/-/issues/679DNSSEC failure on insecure subzone2021-10-23T10:08:30+02:00Tomas KrizekDNSSEC failure on insecure subzoneReported on [knot-resolver-users](https://lists.nic.cz/pipermail/knot-resolver-users/2021/000396.html) by Matthew Richardson
Attempting to resolve `213-133-203-34.newtel.in-addr.itconsult.net. PTR` ends up with a DNSSEC failure, even to...Reported on [knot-resolver-users](https://lists.nic.cz/pipermail/knot-resolver-users/2021/000396.html) by Matthew Richardson
Attempting to resolve `213-133-203-34.newtel.in-addr.itconsult.net. PTR` ends up with a DNSSEC failure, even tough the record itself is in an insecure subzone.
> The zone cut is between itconsult.net & newtel.in-addr.itconsult.net.
> Also whilst itconsult.net is DNSSEC signed, newtel.in-addr.itconsult.net is
> not. Thus, in-addr.itconsult.net is an empty non-terminal.
>
> If one asks for NS for newtel.in-addr.itconsult.net, thereafter resolution
> of the PTR then succeeds
```
[plan ][00000.00] plan '213-133-203-34.newtel.in-addr.itconsult.net.' type 'PTR' uid [51359.00]
[iterat][51359.00] '213-133-203-34.newtel.in-addr.itconsult.net.' type 'PTR' new uid was assigned .01, parent uid .00
[cache ][51359.01] => skipping exact RR: rank 027 (min. 030), new TTL 43131
[cache ][51359.01] => trying zone: itconsult.net., NSEC3, hash c75d4f37
[cache ][51359.01] => NSEC3 depth 3: hash uabfrhboj2pe1qnmfscd0adr77hqoirb
[cache ][51359.01] => NSEC3 encloser error for 213-133-203-34.newtel.in-addr.itconsult.net.: range search miss (!covers)
[cache ][51359.01] => NSEC3 depth 2: hash 7kdfmdhll7ee02vprj1oivl33lg5r7vu
[cache ][51359.01] => NSEC3 encloser error for newtel.in-addr.itconsult.net.: range search miss (!covers)
[cache ][51359.01] => NSEC3 depth 1: hash 4je672clu0jh2pbkm6mdj2n4ps7e9t2h
[cache ][51359.01] => NSEC3 encloser: only found existence of an ancestor
[cache ][51359.01] => skipping zone: itconsult.net., NSEC, hash 0;new TTL -123456789, ret -2
[zoncut][51359.01] found cut: itconsult.net. (rank 002 return codes: DS 0, DNSKEY 0)
[select][51359.01] => id: '47786' choosing: 'd.itconsult-dns.co.uk.'@'2001:67c:10b8::100#00053' with timeout 400 ms zone cut: 'itconsult.net.'
[resolv][51359.01] => id: '47786' querying: 'd.itconsult-dns.co.uk.'@'2001:67c:10b8::100#00053' zone cut: 'itconsult.net.' qname: 'iN-ADDR.iTConSult.neT.' qtype: 'NS' proto: 'udp'
[select][51359.01] NO6: timeouted, appended, timeouts 5/6
[select][51359.01] => id: '47786' noting selection error: 'd.itconsult-dns.co.uk.'@'2001:67c:10b8::100#00053' zone cut: 'itconsult.net.' error: 1 QUERY_TIMEOUT
[iterat][51359.01] '213-133-203-34.newtel.in-addr.itconsult.net.' type 'PTR' new uid was assigned .02, parent uid .00
[select][51359.02] => id: '56910' choosing: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' with timeout 38 ms zone cut: 'itconsult.net.'
[resolv][51359.02] => id: '56910' querying: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' zone cut: 'itconsult.net.' qname: 'in-aDdR.itCONsuLt.neT.' qtype: 'NS' proto: 'udp'
[select][51359.02] => id: '56910' updating: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' zone cut: 'itconsult.net.' with rtt 18 to srtt: 18 and variance: 4
[iterat][51359.02] <= rcode: NOERROR
[iterat][51359.02] <= retrying with non-minimized name
[iterat][51359.02] '213-133-203-34.newtel.in-addr.itconsult.net.' type 'PTR' new uid was assigned .03, parent uid .00
[select][51359.03] => id: '18773' choosing: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' with timeout 38 ms zone cut: 'itconsult.net.'
[resolv][51359.03] => id: '18773' querying: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' zone cut: 'itconsult.net.' qname: '213-133-203-34.nEWtEL.IN-AdDr.ITcONsuLt.NEt.' qtype: 'PTR' proto: 'udp'
[select][51359.03] => id: '18773' updating: 'd.itconsult-dns.co.uk.'@'176.97.158.100#00053' zone cut: 'itconsult.net.' with rtt 16 to srtt: 18 and variance: 4
[iterat][51359.03] <= rcode: NOERROR
[valdtr][51359.03] >< cut changed, needs revalidation
[resolv][51359.03] => resuming yielded answer
[valdtr][51359.03] >< no valid RRSIGs found: 213-133-203-34.newtel.in-addr.itconsult.net. PTR (0 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 0 invalid key, 0 invalid crypto, 0 invalid NSEC)
[plan ][51359.03] plan 'in-addr.itconsult.net.' type 'DS' uid [51359.04]
[iterat][51359.04] 'in-addr.itconsult.net.' type 'DS' new uid was assigned .05, parent uid .03
[cache ][51359.05] => trying zone: itconsult.net., NSEC3, hash c75d4f37
[cache ][51359.05] => NSEC3 depth 1: hash 4je672clu0jh2pbkm6mdj2n4ps7e9t2h
[cache ][51359.05] => NSEC3 sname: match proved NODATA, new TTL 43131
[iterat][51359.05] <= rcode: NOERROR
[valdtr][51359.05] <= parent: updating DS
[valdtr][51359.05] <= answer valid, OK
[resolv][51359.03] => resuming yielded answer
[valdtr][51359.03] >< no valid RRSIGs found: 213-133-203-34.newtel.in-addr.itconsult.net. PTR (0 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 0 invalid key, 0 invalid crypto, 0 invalid NSEC)
[plan ][51359.03] plan 'in-addr.itconsult.net.' type 'DS' uid [51359.06]
[iterat][51359.06] 'in-addr.itconsult.net.' type 'DS' new uid was assigned .07, parent uid .03
[cache ][51359.07] => trying zone: itconsult.net., NSEC3, hash c75d4f37
[cache ][51359.07] => NSEC3 depth 1: hash 4je672clu0jh2pbkm6mdj2n4ps7e9t2h
[cache ][51359.07] => NSEC3 sname: match proved NODATA, new TTL 43131
[iterat][51359.07] <= rcode: NOERROR
[valdtr][51359.07] <= parent: updating DS
[valdtr][51359.07] <= answer valid, OK
[resolv][51359.03] => resuming yielded answer
[valdtr][51359.03] >< no valid RRSIGs found: 213-133-203-34.newtel.in-addr.itconsult.net. PTR (0 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 0 invalid key, 0 invalid crypto, 0 invalid NSEC)
[valdtr][51359.03] <= continuous revalidation, fails
[cache ][51359.03] => not overwriting PTR 213-133-203-34.newtel.in-addr.itconsult.net.
[cache ][51359.03] => not overwriting PTR 213-133-203-34.newtel.in-addr.itconsult.net.
[dnssec] validation failure: 213-133-203-34.newtel.in-addr.itconsult.net. PTR
[resolv][51359.00] request failed, answering with empty SERVFAIL
[resolv][51359.03] finished in state: 8, queries: 2, mempool: 32800 B
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/654insufficient caching of some uncommon wildcards2020-12-11T09:46:52+01:00Vladimír Čunátvladimir.cunat@nic.czinsufficient caching of some uncommon wildcardsIn an NSEC3-signed zone, if a wildcard is nested deeper than directly under the apex, positive expansions from it may not be cached properly (but they succeed). Testing example: `foo.t.cunat.cz AAAA`.
The issue is that aggressive cache...In an NSEC3-signed zone, if a wildcard is nested deeper than directly under the apex, positive expansions from it may not be cached properly (but they succeed). Testing example: `foo.t.cunat.cz AAAA`.
The issue is that aggressive cache thinks it needs to additionally provide an NSEC3 record matching the closest (provable) encloser, but that's not true in this case (because the wildcard record proves encloser's existence). This NSEC3 record must exist but resolver probably hasn't obtained it, so synthesis from cache (usually) fails.
Fortunately, typical wildcard usage I see is directly under the apex `*.example.com`. We may also be "saved" by queries for non-existing types on the same name (e.g. AAAA), as those need this NSEC3 record and thus the only downside would be its "unneeded" addition into the corresponding positive wildcard expansions.Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/632control protocol redesign2020-10-27T17:39:35+01:00Petr Špačekcontrol protocol redesignVersion affected: 5.2.0
Current control protocol has several deficiencies:
- Input commands are read as text, individual commands are delimited with `\n` byte. This prevents user from sending multi-line commands or their parameters beca...Version affected: 5.2.0
Current control protocol has several deficiencies:
- Input commands are read as text, individual commands are delimited with `\n` byte. This prevents user from sending multi-line commands or their parameters because the embedded `\n` breaks implicit command boundaries.
- Output is always string from `table_print()`. Consequently:
- control protocol cannot represent e.g. Lua errors - these lead to empty output.
- sending structured data to another instance is PITA as it has to be serialized into string before it is returned to `table_print()`, and this serialized string is then (again) decorated by `table_print()` with string delimiters `'`
I don't know what's best approach to address this but I think it is worth exploring existing solutions (protobuf? something else?) before inventing our own serialization format and control protocol.https://gitlab.nic.cz/knot/knot-resolver/-/issues/626Can't validate `k.root-servers.net A` with minimization off and cold cache.2020-12-20T18:15:44+01:00Štěpán BalážikCan't validate `k.root-servers.net A` with minimization off and cold cache.Reproducer:
```lua
option('NO_MINIMIZE', true)
-- maybe wait a bit for priming to end
cache.clear()
verbose(true)
-- dig +dnssec @resolver k.root-servers.net A
```
```
[00000.00][plan] plan 'k.root-servers.net.' type 'A' uid [35628.00]...Reproducer:
```lua
option('NO_MINIMIZE', true)
-- maybe wait a bit for priming to end
cache.clear()
verbose(true)
-- dig +dnssec @resolver k.root-servers.net A
```
```
[00000.00][plan] plan 'k.root-servers.net.' type 'A' uid [35628.00]
[35628.00][iter] 'k.root-servers.net.' type 'A' new uid was assigned .01, parent uid .00
[35628.01][resl] => using root hints
[35628.01][iter] 'k.root-servers.net.' type 'A' new uid was assigned .02, parent uid .00
[35628.02][resl] >< TA: '.'
[35628.02][plan] plan '.' type 'DNSKEY' uid [35628.03]
[35628.03][iter] '.' type 'DNSKEY' new uid was assigned .04, parent uid .02
[35628.04][resl] => id: '54250' querying: '2001:500:a8::e#00053' score: 10 zone cut: '.' qname: '.' qtype: 'DNSKEY' proto: 'udp'
[35628.04][resl] => id: '54250' querying: '192.203.230.10#00053' score: 10 zone cut: '.' qname: '.' qtype: 'DNSKEY' proto: 'udp'
[35628.04][iter] <= rcode: NOERROR
[35628.04][vldr] <= parent: updating DNSKEY
[35628.04][vldr] <= answer valid, OK
[35628.04][cach] => stashed . DNSKEY, rank 060, 824 B total, incl. 1 RRSIGs
[ta_signal_query] signalling query trigered: _ta-4f66.
[35628.04][resl] <= server: '2001:500:a8::e' rtt: >= 229 ms
[35628.04][resl] <= server: '192.203.230.10' rtt: 29 ms
[35628.02][iter] 'k.root-servers.net.' type 'A' new uid was assigned .05, parent uid .00
[35628.05][resl] => id: '03562' querying: '192.203.230.10#00053' score: 29 zone cut: '.' qname: 'K.roOt-seRVers.NEt.' qtype: 'A' proto: 'udp'
[00000.00][plan] plan '_ta-4f66.' type 'NULL' uid [65566.00]
[65566.00][iter] '_ta-4f66.' type 'NULL' new uid was assigned .01, parent uid .00
[65566.01][resl] => using root hints
[65566.01][iter] '_ta-4f66.' type 'NULL' new uid was assigned .02, parent uid .00
[65566.02][resl] >< TA: '.'
[65566.02][plan] plan '.' type 'DNSKEY' uid [65566.03]
[65566.03][iter] '.' type 'DNSKEY' new uid was assigned .04, parent uid .02
[65566.04][cach] => satisfied by exact RRset: rank 060, new TTL 172800
[65566.04][iter] <= rcode: NOERROR
[65566.04][vldr] <= parent: updating DNSKEY
[65566.04][vldr] <= answer valid, OK
[65566.02][iter] '_ta-4f66.' type 'NULL' new uid was assigned .05, parent uid .00
[65566.05][resl] => id: '37696' querying: '2001:500:2f::f#00053' score: 10 zone cut: '.' qname: '_ta-4F66.' qtype: 'NULL' proto: 'udp'
[35628.05][iter] <= rcode: NOERROR
[35628.05][vldr] >< cut changed, needs revalidation
[35628.05][resl] <= server: '192.203.230.10' rtt: 21 ms
[35628.05][resl] => resuming yielded answer
[35628.05][vldr] >< no valid RRSIGs found: k.root-servers.net. A (0 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 0 invalid key, 0 invalid crypto, 0 invalid NSEC)
[35628.05][plan] plan 'net.' type 'DS' uid [35628.06]
[35628.06][iter] 'net.' type 'DS' new uid was assigned .07, parent uid .05
[35628.07][resl] => id: '15869' querying: '2001:500:1::53#00053' score: 10 zone cut: '.' qname: 'NEt.' qtype: 'DS' proto: 'udp'
[65566.05][resl] => id: '37696' querying: '192.5.5.241#00053' score: 10 zone cut: '.' qname: '_ta-4F66.' qtype: 'NULL' proto: 'udp'
[35628.07][resl] => id: '15869' querying: '198.97.190.53#00053' score: 10 zone cut: '.' qname: 'NEt.' qtype: 'DS' proto: 'udp'
[65566.05][iter] <= rcode: NXDOMAIN
[65566.05][vldr] <= answer valid, OK
[65566.05][cach] => stashed . NSEC, rank 060, 308 B total, incl. 1 RRSIGs
[65566.05][cach] => stashed . SOA, rank 060, 358 B total, incl. 1 RRSIGs
[65566.05][cach] => nsec_p stashed for . (new, hash: 0)
[65566.05][resl] <= server: '2001:500:2f::f' rtt: >= 225 ms
[65566.05][resl] <= server: '192.5.5.241' rtt: 25 ms
[65566.05][resl] AD: request classified as SECURE
[65566.05][resl] finished: 4, queries: 2, mempool: 98352 B
[35628.07][iter] <= rcode: NOERROR
[35628.07][vldr] <= DS: OK
[35628.07][vldr] <= parent: updating DS
[35628.07][vldr] <= answer valid, OK
[35628.07][cach] => stashed net. DS, rank 060, 330 B total, incl. 1 RRSIGs
[35628.07][resl] <= server: '2001:500:1::53' rtt: >= 250 ms
[35628.07][resl] <= server: '198.97.190.53' rtt: 50 ms
[35628.05][resl] >< TA: '.'
[35628.05][resl] => resuming yielded answer
[35628.05][vldr] >< no valid RRSIGs found: k.root-servers.net. A (0 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 0 invalid key, 0 invalid crypto, 0 invalid NSEC)
[35628.05][plan] plan 'net.' type 'DS' uid [35628.08]
[35628.08][iter] 'net.' type 'DS' new uid was assigned .09, parent uid .05
[35628.09][cach] => satisfied by exact RRset: rank 060, new TTL 86400
[35628.09][iter] <= rcode: NOERROR
[35628.09][vldr] <= DS: OK
[35628.09][vldr] <= parent: updating DS
[35628.09][vldr] <= answer valid, OK
[35628.05][resl] >< TA: '.'
[35628.05][resl] => resuming yielded answer
[35628.05][vldr] >< no valid RRSIGs found: k.root-servers.net. A (0 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 0 invalid key, 0 invalid crypto, 0 invalid NSEC)
[35628.05][vldr] <= continuous revalidation, fails
[35628.05][cach] => stashed k.root-servers.net. A, rank 027, 20 B total, incl. 0 RRSIGs
[35628.05][cach] => not overwriting A k.root-servers.net.
[35628.00][resl] request failed, answering with empty SERVFAIL
[35628.05][resl] finished: 8, queries: 3, mempool: 49200 B
```
And we get an empty SERVFAIL as an answer. :(https://gitlab.nic.cz/knot/knot-resolver/-/issues/602cache size exposed in Lua API can get out of sync2020-11-04T11:53:33+01:00Petr Špačekcache size exposed in Lua API can get out of syncThis is minor nit.
Lua call `cache.current_size` does not read the cache size from file/LMDB environment so the value reported in Lua can be out-of-sync if another process changed cache size.
The following discussion from !1042 should ...This is minor nit.
Lua call `cache.current_size` does not read the cache size from file/LMDB environment so the value reported in Lua can be out-of-sync if another process changed cache size.
The following discussion from !1042 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1042#note_168309): (+1 comment)
> I wonder if `cache.current_size` returns correct size if some rounding took place inside the backend.https://gitlab.nic.cz/knot/knot-resolver/-/issues/588control socket drops long outputs2020-09-17T13:22:45+02:00Petr Špačekcontrol socket drops long outputsControl socket randomly cuts long outputs. It seems to be caused by incorrect use of fprintf inside daemon/io.c fuction `io_tty_process_input()`.
Version: 5.1.2
Steps to reproduce:
```
$ echo -e "string.rep('a', 1024*1024*10)\n" | soca...Control socket randomly cuts long outputs. It seems to be caused by incorrect use of fprintf inside daemon/io.c fuction `io_tty_process_input()`.
Version: 5.1.2
Steps to reproduce:
```
$ echo -e "string.rep('a', 1024*1024*10)\n" | socat - unix-connect:$(ls control/*) | wc -c
223362
```
I.e. the output is truncated after 223362 bytes. This value is not a constant, it varies. Expected output should be 1024*1024*10 bytes `a` + 2x2 bytes of prompt `> `.
Strace:
```
read(23, "__binary\nstring.rep('a', 1024*10"..., 65536) = 40
dup(23) = 24
fcntl(24, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fstat(24, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
write(24, "\0\240\0\1aaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 4096) = 4096
write(24, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 10481664) = 219264
write(24, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 10262400) = 109632
write(24, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 10152768) = 219264
write(24, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 9933504) = -1 EAGAIN (Resource temporarily unavailable)
close(24) = 0
```
The whole `io_tty_process_input()` function is a mess and should be refactored into smaller pieces, and most importantly rewritten to use libuv for writes as well.https://gitlab.nic.cz/knot/knot-resolver/-/issues/488can't reliably fetch stats when using SO_REUSEPORT2020-06-15T09:35:13+02:00Jean-Danielcan't reliably fetch stats when using SO_REUSEPORTI'm using knot resolver with systemd, and want to use the stats module + http module to fetch stats in prometheus format.
My problem is that if I start more that one instance (kresd@1, kresd@2, …), stats fetching requests are distribute...I'm using knot resolver with systemd, and want to use the stats module + http module to fetch stats in prometheus format.
My problem is that if I start more that one instance (kresd@1, kresd@2, …), stats fetching requests are distributed among the instances and returns only the stats from the answering instance.
I can't get a reliable way to fetch the stats in such configuration.
Workaround:
I can fetch and aggregate individual workers stats from the controls sockets, but the control socket is very unreliable (it is not able to properly parse 2 successives queries properly and often try to interpret them as a single query).https://gitlab.nic.cz/knot/knot-resolver/-/issues/483DNS64 does not synthesise if AAAA query fails but A query works2019-12-18T19:56:41+01:00Petr ŠpačekDNS64 does not synthesise if AAAA query fails but A query worksQuery for `internetbanken.privat.nordea.se. AAAA` ends up with SERVFAIL because it is broken on the authoritative side, but query `internetbanken.privat.nordea.se. A` succeeds.
https://tools.ietf.org/html/rfc6147#section-5.1.2 seems to ...Query for `internetbanken.privat.nordea.se. AAAA` ends up with SERVFAIL because it is broken on the authoritative side, but query `internetbanken.privat.nordea.se. A` succeeds.
https://tools.ietf.org/html/rfc6147#section-5.1.2 seems to specify (using pretty convoluted language), that any failure in AAAA resolving should trigger A subquery and DNS64 synthesis.
This was reported during RIPE 78 meeting because some people were not able to reach their bank website.
I can see two problems with current DNS64 module (as in Knot Resolver 4.0.0):
- Failed AAAA query does not trigger synthesis, e.g. if we get SERVFAIL. This should be easy to fix.
- AAAA query which fails because of all NS servers do not respond for AAAA query will not call `consume()` layer in module, and thus DNS64 module does not get a chance to do A query and synthesis. This will be harder to fix.https://gitlab.nic.cz/knot/knot-resolver/-/issues/479NOERROR from pre-RFC 2308 servers is treated as lame2019-05-23T16:40:41+02:00Petr ŠpačekNOERROR from pre-RFC 2308 servers is treated as lameKnot Resolver 4.0.0 does not accept NOERROR answers from pre-RFC 2308 auths, i.e. auths which do not send SOA RR in AUTHORITY section of NOERROR answer.
Example from live Internet:
```
resolve('blogs.cisco.com', kres.type.AAAA, kres.c...Knot Resolver 4.0.0 does not accept NOERROR answers from pre-RFC 2308 auths, i.e. auths which do not send SOA RR in AUTHORITY section of NOERROR answer.
Example from live Internet:
```
resolve('blogs.cisco.com', kres.type.AAAA, kres.class.IN, {}, function(pkt) print(pkt) end)
```
...
```
[65537.22][iter] 'blogs.glb-ext.cisco.com.' type 'AAAA' new uid was assigned .25, parent uid .00
[65537.25][resl] => id: '43849' querying: '72.163.5.22#00053' score: 10 zone cut: 'glb-ext.cisco.com.' qname: 'BLogS.glb-eXT.CiscO.Com.' qtype: 'AAAA' proto: 'udp'
[65537.25][iter] <= answer received:
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 43849
;; Flags: qr cd QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1280 B; ext-rcode: Unused
;; QUESTION SECTION
blogs.glb-ext.cisco.com. AAAA
[65537.25][iter] <= rcode: NOERROR
[65537.25][iter] <= lame response: non-auth sent negative response
```
This seems to be caused by `is_authoritative()` in lib/layer/iterate.c.https://gitlab.nic.cz/knot/knot-resolver/-/issues/473validate: NSEC proofs can confuse NXDOMAIN with NODATA2019-04-30T12:39:49+02:00Vladimír Čunátvladimir.cunat@nic.czvalidate: NSEC proofs can confuse NXDOMAIN with NODATA[Real-life example](https://gitlab.labs.nic.cz/knot/knot-resolver/issues/462#note_104852).
The records get into aggressive cache that doesn't suffer from this bug, so only the first answer can be wrong. So far I can see no security imp...[Real-life example](https://gitlab.labs.nic.cz/knot/knot-resolver/issues/462#note_104852).
The records get into aggressive cache that doesn't suffer from this bug, so only the first answer can be wrong. So far I can see no security implications of exchanging NODATA with NXDOMAIN.https://gitlab.nic.cz/knot/knot-resolver/-/issues/404incorrect handling of EDNS version 1+2019-07-09T17:12:25+02:00Petr Špačekincorrect handling of EDNS version 1+Apparently we do not return BADVERS as we should:
```
$ dig +nocookie +rec +noad +edns=1 +noednsneg +ednsopt=100 soa isc.org. @1.1.1.1
; <<>> DiG 9.13.0-dev <<>> +nocookie +rec +noad +edns=1 +noednsneg +ednsopt=100 soa isc.org. @1.1.1....Apparently we do not return BADVERS as we should:
```
$ dig +nocookie +rec +noad +edns=1 +noednsneg +ednsopt=100 soa isc.org. @1.1.1.1
; <<>> DiG 9.13.0-dev <<>> +nocookie +rec +noad +edns=1 +noednsneg +ednsopt=100 soa isc.org. @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;isc.org. IN SOA
;; ANSWER SECTION:
isc.org. 6914 IN SOA ns-int.isc.org. hostmaster.isc.org. 2018092500 7200 3600 24796800 3600
;; Query time: 16 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Oct 01 13:40:13 CEST 2018
;; MSG SIZE rcvd: 90
```
Test suite:
https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing
run `genreport -R` with input like:
`nic.cz. resolver.test. 1.1.1.1`
Output at the moment:
```
nic.cz. @1.1.1.1 (resolver.test.): dns=ok edns=ok edns1=noerror,badversion,soa edns@512=ok ednsopt=ok edns1opt=noerror,badversion,soa do=ok ednsflags=ok optlist=ok signed=ok,yes ednstcp=ok
```https://gitlab.nic.cz/knot/knot-resolver/-/issues/347knot-resolver fails to build from source on hurd due to missing MAXPATHLEN2018-05-03T12:48:02+02:00Daniel Kahn Gillmorknot-resolver fails to build from source on hurd due to missing MAXPATHLENthe [debian hurd build daemon](https://buildd.debian.org/status/fetch.php?pkg=knot-resolver&arch=hurd-i386&ver=2.3.0-2&stamp=1524785893&raw=0) shows:
```
daemon/engine.c: In function 'engine_set_moduledir':
daemon/engine.c:231:15: error...the [debian hurd build daemon](https://buildd.debian.org/status/fetch.php?pkg=knot-resolver&arch=hurd-i386&ver=2.3.0-2&stamp=1524785893&raw=0) shows:
```
daemon/engine.c: In function 'engine_set_moduledir':
daemon/engine.c:231:15: error: 'MAXPATHLEN' undeclared (first use in this function); did you mean 'MAXNAMLEN'?
char l_paths[MAXPATHLEN] = { 0 };
^~~~~~~~~~
MAXNAMLEN
```
See [Justus Winter's thoughts on MAXPATHLEN](https://lists.debian.org/debian-hurd/2012/01/msg00166.html) about why this might not be something worth relying on.https://gitlab.nic.cz/knot/knot-resolver/-/issues/346www.nrl.navy.mil. validation broken without query minimization2018-09-04T16:29:06+02:00Filip Sirokywww.nrl.navy.mil. validation broken without query minimizationValidation is broken without query minimization for www.nrl.navy.mil. after it was fixed with it in merge !543.
Kresd log:
[server.log](/uploads/199eaec49170e46882d23c12e6db646b/server.log)
Deckard scenario:
[gen_navy.rpl](/uploads/aaa4...Validation is broken without query minimization for www.nrl.navy.mil. after it was fixed with it in merge !543.
Kresd log:
[server.log](/uploads/199eaec49170e46882d23c12e6db646b/server.log)
Deckard scenario:
[gen_navy.rpl](/uploads/aaa46e764a232e811ee9d32813953325/gen_navy.rpl)https://gitlab.nic.cz/knot/knot-resolver/-/issues/318map_set is used incorrectly on some places2018-05-03T17:06:32+02:00Vladimír Čunátvladimir.cunat@nic.czmap_set is used incorrectly on some placesProbably due to misleading API docs; when it returns 1, it's replaced the value, but sometimes we free the value afterwards assuming ENOMEM. Some `set_add` call sites might also be affected.Probably due to misleading API docs; when it returns 1, it's replaced the value, but sometimes we free the value afterwards assuming ENOMEM. Some `set_add` call sites might also be affected.https://gitlab.nic.cz/knot/knot-resolver/-/issues/292tls forwarding: there are high likelyhood of msg-id duplication for active qu...2018-02-16T11:04:58+01:00Grigorii Demidovtls forwarding: there are high likelyhood of msg-id duplication for active query under heavy loadhttps://gitlab.nic.cz/knot/knot-resolver/-/issues/225opcode IQUERY returns SERVFAIL instead of NOTIMP2019-07-09T17:14:22+02:00Štěpán Kotekopcode IQUERY returns SERVFAIL instead of NOTIMPUnsupported opcode must lead to `RCODE=NOTIMP`. This will get back and bite us when the session signalling draft comes by.
Clarification: Response to unknown OPCODE must contain only the DNS message header and nothing else, not even EDN...Unsupported opcode must lead to `RCODE=NOTIMP`. This will get back and bite us when the session signalling draft comes by.
Clarification: Response to unknown OPCODE must contain only the DNS message header and nothing else, not even EDNS. The reason is that different OPCODEs might potentially use very different message format so it is risky to return anything beyond the DNS header.
test failing: `sets/resolver/iter_opcode_notimp.rpl ` in deckard, branch `unknown-opcode`
blocks deckard#112019 Q1https://gitlab.nic.cz/knot/knot-resolver/-/issues/224validate: support mixing NSEC and NSEC3 in a single packet2017-10-10T10:08:11+02:00Vladimír Čunátvladimir.cunat@nic.czvalidate: support mixing NSEC and NSEC3 in a single packet