Knot Resolver issueshttps://gitlab.nic.cz/knot/knot-resolver/-/issues2019-07-09T17:12:25+02:00https://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/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/210RFC 4035 sec 5.2: downgrade to insecure when only unknown algorithms are used...2019-07-09T17:12:39+02:00Vladimír Čunátvladimir.cunat@nic.czRFC 4035 sec 5.2: downgrade to insecure when only unknown algorithms are used (provably)Currently these lead to SERVFAIL, as detected by https://rootcanary.org/test.html
This will probably be about handling the `DNSSEC_INVALID_DS_ALGORITHM` return code from libdnssec.
https://tools.ietf.org/html/rfc4035#section-5.2
...Currently these lead to SERVFAIL, as detected by https://rootcanary.org/test.html
This will probably be about handling the `DNSSEC_INVALID_DS_ALGORITHM` return code from libdnssec.
https://tools.ietf.org/html/rfc4035#section-5.2
> If the validator does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.