Hello.
In case you're using our upstream repositories for Debian or Ubuntu, as
suggested on https://www.knot-resolver.cz/download/
you'll be running into their signing key expiring since today. As we
didn't update it in time, you'll have to update it manually by re-running:
wgethttps://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb
dpkg -i knot-resolver-release.deb
Ticket: https://gitlab.nic.cz/knot/knot-resolver/-/issues/747
We also forgot to add Ubuntu 22.04, so that is fixed now, too.
--Vladimir
Dear Knot Resolver users,
DNS Shotgun v20240219, our high-performance realistic benchmarking tool
for DNS resolvers, has been released.
This new release, amongst a variety of other improvements, brings
support for testing DNS-over-QUIC.
Incompatible changes:
- CMake is now being used to build dnssim instead of Autotools
- GnuTLS 3.7.5+ is now required
Improvements:
- pcap/extract-clients: always reset UDP port numbers to 53 (!56)
- pcap/extract-clients: ability to write to stdout (!62)
- pcap/filter-dnsq: skip 'special' queries for *.dotnxdomain.net (!58)
- pcap/split-clients: new tool to split larger PCAPs into smaller ones (!61)
- pcap/merge-chunks: allow disabling randomization (!67)
- tools/plot-latency: ability to diversify lines with linestyles (!69)
- tools/plot-response-rate: estimate worst-case drop caused by discarded
packets (!74)
- tools/plot-packet-rate: handle incomplete last sampling period (!71)
- tools/plot-response-rate: ability to ignore RCODEs with small response
rate (!73)
- pcap/filter-dnsq: ability to log malformed queries (!72)
- pcap/generate-const-qps: new tool to generate constant QPS (!33)
- tools: allow customizing plot charts with `SHOTGUN_MPLSTYLES` (!65)
- replay: `--preload` argument, mainly for dnssim debugging with
sanitizers (!76)
- tools/plot-latency: use fractional values for humans in charts (!78)
- pcap/extract-clients: warn if some input packets were skipped (!80)
- dnssim: replace Autotools with CMake (!77, !86)
- configs: DoH configs with exclusively GET/POST methods (!82)
- tools/plot-response-rate: avoid division by zero (!89)
- tools/plot-latency: denser labels to improve logarithmic scale
readability (!90)
- pcap/extract-clients: allow query rewriting - anonymization (!91)
- Support for DNS-over-QUIC (!75)
Bugfixes:
- tools/plot-response-rate: avoid white lines on white background (!55)
- tools/plot-client-distribution: properly handle file limit (!59)
- pcap: proper PCAP write error handling (!60)
- tools/plot-connections: set axis limits properly (!66)
- tools/plot-packet-rate: trim chart whitespace (!79)
- replay: do not exit silently when dnssim returns non-zero (!87)
Full changelog:
https://gitlab.nic.cz/knot/shotgun/-/releases/v20240219
Sources:
https://gitlab.nic.cz/knot/shotgun/-/archive/v20240219/shotgun-v20240219.ta…
Documentation:
https://dns-shotgun.readthedocs.io/en/v20240219/
Oto Šťáva
Knot Resolver
CZ.NIC z.s.p.o.
Hello,
I am trying to figure out why some domain names are not resolving on my
instance of Knot resolver over DoH with some clients. I was able to
reproduce this issue with [doh](https://github.com/curl/doh) client built
on libcurl. The problem never manifests with kdig (neither with DoH, nor
DoT nor Do53).
During this, I noticed something strange. For domain name github.com (which
sometimes returns no A record), I always receive an answer with TTL set to
60. It seems like this name does not get cached at all. See the test output
below.
Interestingly, if I delete cache files and restart the resolver, the TTL
starts decreasing as expected. Is this a sign that something was wrong with
the cache before? Or is this some sort of cache optimization for low TTL
records?
Here is the test output:
$ for i in `seq 1 5`; do ./doh github.comhttps://nscache.mtg.ripe.net/dns-query ; echo "----"; kdig +https +noadflag
+nocookie +noall +answer github.com A @nscache.mtg.ripe.net ; echo "====";
sleep 1; done
[github.com]
TTL: 60 seconds
AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7903
----
github.com. 60 IN A 140.82.121.3
====
[github.com]
TTL: 60 seconds
A: 140.82.121.3
AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7904
----
github.com. 60 IN A 140.82.121.4
====
[github.com]
TTL: 60 seconds
A: 140.82.121.4
AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7904
----
github.com. 60 IN A 140.82.121.4
====
[github.com]
TTL: 60 seconds
A: 140.82.121.4
AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7903
----
github.com. 60 IN A 140.82.121.4
====
[github.com]
TTL: 60 seconds
A: 140.82.121.3
AAAA: 0064:ff9b:0000:0000:0000:0000:8c52:7904
----
github.com. 60 IN A 140.82.121.3
====
--
Best regards,
Ondřej Caletka
Komentator -Liga Champions✔️✔️ Owen Hargreaves mengatakan bahwa “semua orang akan terpukul” oleh penampilan buruk Bayern Munich baru-baru ini, kali ini setelah kalah dari Lazio di leg pertama babak 16 besar Liga Champions.
Situs web: https://svipbola.com/liga/liga-champions
Pertandingan Liga Champions“Mereka perlu menemukan cara untuk mempercepat permainan dan menjadi sedikit lebih cepat. Mereka melewati fase ini di bawah asuhan Pep dan memainkan sepakbola terindah. Hari ini mereka bahkan tidak memainkan sepakbola indah.”
Jadwal Liga Champions - dengan meningkatnya perhatian media terhadap manajer dan pemain, mantan gelandang Manchester United dan pemenang Liga Champions Hargreaves tidak berharap tim tamu mendapat ulasan positif atas penampilan seperti itu.
Liga Champions 2023⭐“Ketika Anda bermain untuk tim papan atas, saya tahu orang-orang tidak ingin mendengarnya, namun ketika Anda bermain seperti itu, Anda akan dikritik. Saya pikir akan ada banyak rasa frustrasi di dalam dan di sekitar Bayern saat ini.”
Address: Jl Gondosuli 8 Yk Jawa Tengah Indonesia
#Liga Champions
#pertandingan liga champions
#jadwal liga champions
#klasemen liga champions
#liga champions uefa
#liga champions 2023
#hasil liga champions
#liga champions 2022
Dear Knot Resolver users,
Knot Resolver versions 5.7.1 (stable) and 6.0.6 (early-access) have been
released!
These releases include important security fixes, an update is strongly
advised!
Security:
- CVE-2023-50868: NSEC3 closest encloser proof can exhaust CPU
* validator: lower the NSEC3 iteration limit (150 -> 50)
* validator: similarly also limit excessive NSEC3 salt length
* cache: limit the amount of work on SHA1 in NSEC3 aggressive cache
* validator: limit the amount of work on SHA1 in NSEC3 proofs
* validator: refuse to validate answers with more than 8 NSEC3 records
- CVE-2023-50387 "KeyTrap": DNSSEC verification complexity
could be exploited to exhaust CPU resources and stall DNS resolvers.
Solution boils down mainly to limiting crypto-validations per packet.
We would like to thank Elias Heftrig, Haya Schulmann, Niklas Vogel
and Michael Waidner
from the German National Research Center for Applied Cybersecurity ATHENE
for bringing this vulnerability to our attention.
Improvements:
- update addresses of B.root-servers.net (!1478)
Bugfixes:
- fix potential SERVFAIL deadlocks if net.ipv6 = false (#880)
The update affects how some cached records are being treated, which may
trip up some sanity checking mechanisms in Knot Resolver if you have
advanced debugging options enabled (disabled by default),
"debugging.assertion_abort" for version 5 (Lua) and
"logging/debugging/assertation-abort" for version 6 (YAML). In case you
encounter any issues, please try clearing the cache first.
Full changelog:
https://gitlab.nic.cz/knot/knot-resolver/raw/v5.7.1/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.7.1.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v5.7.1/
--
Ales Mrazek
PGP: 3057 EE9A 448F 362D 7420 5A77 9AB1 20DA 0A76 F6DE
Dear Knot Resolver users,
last week a long-lasting bug in our mailing system has been discovered,
which, over the past two years, blocked quite a few e-mails from being
delivered to the list <knot-resolver-users(a)lists.nic.cz> and a few
others (namely the <knot-dns-users(a)lists.nic.cz>, whose subscriber Juha
Suhonen initially brought our attention to the issue - a thank you to
Juha is in order!).
This week the issue has been resolved and the blocked e-mails came
through. Some of these were our own, namely the Knot Resolver 5.5.0
release announcement, which is obviously outdated, as the current stable
version is Knot Resolver 5.7.0. We apologize for any confusion this
situation may have caused. Some others are still awaiting additional
approval, so after we manually identify, which are still relevant, and
which are spam, they will also come through during the following weeks.
Furthermore, later today we are planning to release new versions of the
stable Knot Resolver 5 and the early-access Knot Resolver 6. These
important updates will mitigate a few newfound DoS issues, the details
of which will soon be revealed globally. We are fully aware that this
unfortunate timing may cause further confusion, so we opted to inform
you, the subscribers, beforehand, that this next release e-mail is
indeed relevant.
We once again apologize for the confusion.
Best regards
Oto Šťáva
Knot Resolver team
CZ.NIC z.s.p.o.
On 2/12/24 01:34, Vladimír Čunát wrote:
> On 28/01/2024 02.52, Mike Wright wrote:
>> [system] error while loading config:
>> ...b/x86_64-linux-gnu/knot-resolver/kres_modules/policy.lua:378: bad
>> argument #1 to 'create' (table expected, got nil) (workdir
>> '/var/lib/knot-resolver')
>
> You don't define the `internalDomain` variable. That's correct in lua
> and evaluates as nil.
>
> (and as I already posted, please use the correct mailing-list next time)
OK, figured out my mistake.
internalDomains MUST APPEAR BEFORE any reference to it.
Thanks for your time,
Mike Wright
