Dear Knot Resolver users,
Knot Resolver 5.7.0 has been released!
Security
- avoid excessive TCP reconnections in a few more cases
Like before, the remote server had to behave nonsensically in order
to inflict this upon itself, but it might be abusable for DoS.
We thank Ivan Jedek from OryxLabs for reporting this.
Improvements
- forwarding mode: tweak dealing with failures from forwarders,
in particular prefer sending CD=0 upstream (!1392)
Bugfixes
- fix unusual timestamp format in debug dumps of records (!1386)
- adjust linker options; it should help less common platforms (!1384)
- hints module: fix names inside home.arpa. (!1406)
- EDNS padding (RFC 8467) compatibility with knot-dns 3.3 libs (!1422)
Full changelog:
https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.0.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v5.7.0/
--
Ales Mrazek
PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE
Hello,
could you please help me with knot resolver configuration in the case when I
need to redirect each variation for the domain to some address.
e.g.
www.example.com, m.example.com, domain.example.com ...
like wildcard record
*.example.com 10.0.0.50
In my configuration is it handeled by file with static records
-- load static records
hints.add_hosts('/etc/knot-resolver/static_records.txt')
which contains address to be redirected and the domain.
10.0.0.50 1xbet.com
10.0.0.50 thelotter.com
10.0.0.50 webmoneycasino.com
10.0.0.50 betworld.com
10.0.0.50 bosscasino.eu
10.0.0.50 sportingbull.com
But I´m not able to handle the correct syntax for a wildcard domain
redirection.
Best regards,
--
Smil Milan Jeskyňka Kazatel
Hoping someone can help...
Built Knot Resolver v5.6.0 from source.
It works and resolves correctly for "regular" TLDs.
However, I would like to point it to OpenNIC for resolution /forwarding
so that I can resolve the expanded /alternative TLDs.
Default configuration with:
policy.add(policy.all(
policy.FORWARD(
{'2001:19f0:b001:379:5400:3ff:fe68:1cc6',
'138.197.140.189',
'2600:3c04::f03c:93ff:febd:be27',
'45.61.49.203'})))
and it fails to find "grep.geek" using the standard root zone /hints:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22871
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;grep.geek. IN A
;; AUTHORITY SECTION:
. 86077 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2023050902 1800 900 604800 86400
So I checked the Documentation site and found "hints.root" which
theoretically will override any other root hints.
Using the OpenNIC root zone file (downloads as "db.root") I set:
hints.root ({
['ns13.opennic.glue.'] = { '2a01:4f8:192:43a5::2', '144.76.103.143' }
})
in kresd.conf.
Still no joy - "grep.geek" is NXDOMAIN from a.root-servers.net again.
Any thoughts? Things I might have missed along the way?
Hello,
it's me again :) I just want to make sure if behaviour of Knot
Resolver is correct.
I implemented DDR mechanism to discover DoH / DoT DNS servers. My
Macbook with Ventura successfully discovered DoH server and started to
use it.
But: Knot Resolver sends 10 seconds after establishing FIN,ACK packet
and connection is correctly closed. From this moment, Macbook starts
to use DNS over UDP again and will retry DoH connection after 10-30s
later. Then it uses DoH server again for 10 seconds ....
Is this behaviour correct? Should Macbook sends some keepalive
messages to prevent connection closing? Or should Macbook reopen DoH
connection more quickly?
Thanks,
Blažej
Hello,
is there any correct way how to do query policy based on destination
IP (IP which processed the query)? Like view:addr but on the dst
address.
I found that function view.addr(_, subnet, rules, dst) contains DST
parameter but I'm not sure how to use it.
I also found function view.rule_dst(action, subnet) but still get errors:
error: /usr/lib/knot-resolver/kres_modules/view.lua:103: attempt to
index local 'req' (a number value)
Thanks
Blažej
Hi there,
I'm trying to implement SVCB record "_dns.resolver.arpa" for DDR
mechanism for our AS50242 recursive resolvers.
When I look on Cloudflare or Google implementation, they answer with
"ADDITIONAL SECTION" also.
kdig _dns.resolver.arpa @8.8.8.8 type64
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 61402
;; Flags: qr aa rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 4
;; QUESTION SECTION:
;; _dns.resolver.arpa. IN SVCB
;; ANSWER SECTION:
_dns.resolver.arpa. 86400 IN SVCB 1 dns.google. alpn=dot
_dns.resolver.arpa. 86400 IN SVCB 2 dns.google. alpn=h2,h3
key7="/dns-query{?dns}"
;; ADDITIONAL SECTION:
dns.google. 86400 IN A 8.8.8.8
dns.google. 86400 IN A 8.8.4.4
dns.google. 86400 IN AAAA 2001:4860:4860::8888
dns.google. 86400 IN AAAA 2001:4860:4860::8844
In Knot Resolver documentation is an example how to answer for SVCB
request but without addition section.
policy.add(
policy.domains(
policy.ANSWER(
{ [kres.type.SVCB] = { rdata=kres.parse_rdata({
'SVCB 1 resolver.example. alpn=dot ipv4hint=192.0.2.1
ipv6hint=2001:db8::1',
'SVCB 2 resolver.example. mandatory=key65380 alpn=h2
key65380=/dns-query{?dns}',
}), ttl=5 } }
), { todname('_testing.domain') }))
Can anyone help me, how to add additional section to answer? Do we
need to use policy.custom_action(state, request)?
Thanks!
Blažej
Dear Knot Resolver users,
Knot Resolver 5.6.0 has been released!
Security
- avoid excessive TCP reconnections in some cases (!1380)
For example, a DNS server that just closes connections without answer
could cause lots of work for the resolver (and itself, too).
The number of connections could be up to around 100 per client's query.
We thank Xiang Li from NISL Lab, Tsinghua University,
and Xuesong Bai and Qifan Zhang from DSP Lab, UCI.
Improvements
- daemon: feed server selection with more kinds of bad-answer events (!1380)
- cache.max_ttl(): lower the default from six days to one day
and apply both limits to the first uncached answer already (!1323 #127)
- depend on jemalloc, preferably, to improve memory usage (!1353)
- no longer accept DNS messages with trailing data (!1365)
- policy.STUB: avoid applying aggressive DNSSEC denial proofs (!1364)
- policy.STUB: avoid copying +dnssec flag from client to upstream (!1364)
Bugfixes
- policy.DEBUG_IF: don't print client's packet unconditionally (!1366)
Full changelog:
https://gitlab.nic.cz/knot/knot-resolver/raw/v5.6.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.6.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.6.0.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v5.6.0/
--
Ales Mrazek
PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE
Hello everyone,
at AS50242 we experience problem with resolving connectivity.samsung.com.cn
We run two servers, each with 4 instances. Both servers have working
dual-stack (v4/v6).
knot-dnsutils/unknown,now 3.1.1-cznic.1 amd64 [installed]
knot-resolver-module-http/unknown,now 5.5.0-cznic.1 all [installed,automatic]
knot-resolver-release/unknown,now 1.9-1 all [installed]
knot-resolver/unknown,now 5.5.0-cznic.1 amd64 [installed]
Dnsviz shows problem reaching few IPv6 servers of .cn TLD via UDP. I
can not understand, why both of our servers response with SERVFAIL.
Any ideas how to troubleshoot more?
Thank you,
Blažej