On 25/06/2024 22.53, Randy Bush wrote:
Seehttps://www.knot-dns.cz/download/
yes, that is source
No, there are packages built by cz.nic as well.
--
On 25/06/2024 22.17, Randy Bush wrote:
is there likely to be a debian package in a week or two? we're kida
back at 3.2.6-1.
See https://www.knot-dns.cz/download/
There won't be updates directly in stable Debian; IIRC their policies
don't allow it.
--Vladimir
--
On 17/05/2024 22.43, Peter Thomassen wrote:
I think the question is whether Knot Resolver follows the letter of
the RFC, like BIND, or whether it is less strict.
I'm not aware of RFCs saying that resolvers should fail in such
situations. My understanding is more like it's allowed not to work
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 corre
On 23/12/2021 11.14, Tuomo Soini wrote:
Maybe the problem goes away in a new version.
How about telling us version you are running? This has been working for
ages.
DNSViz complains about knotd not doing cookies *on TCP* connections,
which is so in the latest releases. And it's now planned to
On 23/07/2021 17.57, Schindler, Stefan wrote:
I tried switching to the ED25519 algorithm, but then home users could
no longer resolve anything in the zone because the resolvers are too
old/incomplete.
So, to stay resolvable I was hoping to work around that with two
algorithms.
You'll have to
Hello.
On 23/07/2021 16.13, Schindler, Stefan wrote:
Because for some reason a lot of ISP resolvers support RSA only while
I would like to future-proof my zone with ED25519 at the same time.
As the current DNSSEC standards go, I think it's normally not worth
using two algorithms at once on a
Ahoj.
Let's continue the thread on [knot-resolver-users]:
https://lists.nic.cz/pipermail/knot-resolver-users/2019/000130.html
--Vladimir
--
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
On 3/14/19 10:17 PM, Daniel Kahn Gillmor wrote:
> Would you mind identifying by fingerprint which OpenPGP certificate was
> revoked?
rsa4096/0xAC0E47584A7A714D
The information is also on https://www.knot-dns.cz/download/
signature.asc
Description: OpenPGP digital signature
--
https://lists.ni
Hello Knot DNS users.
Our deb package signing key may have been compromised and has been
revoked. Open Build Service repositories are not affected.
The affected systems (https://deb.knot-dns.cz/knot-latest and
https://deb.knot-dns.cz/knot) now contain a new Debian repository. The
packages were
On 3/6/19 12:30 AM, Daniel Kahn Gillmor wrote:
> oof, this is definitely a subtle ABI breakage -- it looks like the lua
> zs_scanner struct changed shape/size!
>
> Fortunately, the SONAMEs in Knot DNS changed, so knot-resolver shouldn't
> break based on a simple upgrade. right? Or are the lua bin
Hello, Knot * users!
Please note that Knot DNS 2.8.x breaks all Knot Resolver versions
released so far (<=3.2.1). The breakage is a bit subtle, and build
system won't detect it.
We plan to release an update soon. If you don't want to wait, you can
apply a simple patch:
https://gitlab.labs.nic.cz
On 2/25/19 11:00 AM, Ralf Weber wrote:
> bind is also setting the AD bit on the query and this actually
> triggers it, though the RFC where this is defined currently doesn’t
> come to my mind.
Yes, I don't remember which RFC, but it is standardized that if you
specify AD flag in query, the resolve
On 06/08/2018 04:34 PM, Anand Buddhdev wrote:
Perhaps open a bug report with the maintainer of the knot-dnsutils > package?
IIRC it's just not backported to some Debian < 10.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741645
--Vladimir
--
https://lists.nic.cz/cgi-bin/mailman/listinfo/
On 05/19/2018 11:50 PM, dptr...@arcor.de wrote:
> I am using ecdsap256sha256 as algorithm. Why does the KSK DNSKEY > (=257) use
> as digest type SHA1 (=1) and not SHA256 (=2)?
Technically, the DNSKEY algorithm is independent of the DS algorithm
used on it, I believe, though some combinations make
On 03/16/2018 12:38 PM, Petr Špaček wrote:
> I'm not an expert when it comes to auth servers, but I speculate that
> seemingly larger memory consumption might come from journal. Journal is
> in our case stored in LMDB, which is in fact memory-mapped file, so it
> looks like it consumes memory ...
Hi.
On 03/15/2018 04:14 PM, Anand Buddhdev wrote:
> # grep VmSize /proc/22365/status
> VmSize: 10958428 kB
Well, I personally wouldn't compare by the VmSize metric. In general
it's relatively often far away from what one wants to know, e.g. my
Firefox ATM shows roughly five times larger value th
Dear Knot Resolver users,
Knot Resolver 1.5.2 is a security release!
Security
- fix CVE-2018-102: insufficient DNSSEC validation, allowing
attackers to deny existence of some data by forging packets.
Some combinations pointed out in RFC 6840 sections 4.1 and 4.3
were not taken
On 12/13/2017 02:13 PM, Yoshihito Horigome wrote:
> ii libmemcached11:arm64 1.0.18-4.1
> arm64 C and C++ client library to the memcached server
Side note: are you trying to run it on 64-bit ARM? (i.e. aarch64) That
will most likely not work yet:
h
Dear Knot Resolver users,
Knot Resolver 1.5.1 is released, mainly with bugfixes and cleanups!
Incompatible changes
- script supervisor.py was removed, please migrate to a real process manager
- module ketcd was renamed to etcd for consistency
- module kmemcached was renamed t
Ještě co se týče zrychlení odpovědí:
- pokud ten server kde kresd poběží nemá funkční IPv6 směrem do
internetu, je dobré přidat do konfiguračního souboru
net.ipv6 = false
Tím se ušetří pokusy o spojení přes IPv6 pokud stejně nemůžou uspět.
- máme volitelný modul který se snaží odhadnout které
On 11/20/2017 12:37 PM, Petr Kubeš wrote:
> Je prosím někde dostupna nějaká jednoduchá "kuchařka" pro zprovoznění
> takovéhoto DNS resolveru?
V některých systémech už je přímo balíček se službou, případně máme PPA
obsahující novější verze. https://www.knot-resolver.cz/download/
Vyhnul bych se v
Dobrý den.
On 11/20/2017 10:18 AM, Petr Kubeš wrote:
> Dobrý den, prosím o radu.
> provozujeme malou síť a v současné době využíváme externí DNS
> poskytovatele (UPC).
> CHtěli by jsme na hraničním uzlu zprovoznit vlastní DNS , konkrétně
> KNOT v konfiguraci, kdy by majoritně fungoval jako DNS RES
Dear Knot Resolver users,
Knot Resolver 1.5.0 has been released!
Bugfixes
- fix loading modules on Darwin
Improvements
- new module ta_signal_query supporting Signaling Trust Anchor Knowledge
using Keytag Query (RFC 8145 section 5); it is enabled by default
- attempt vali
Dear Knot Resolver users,
Knot Resolver 1.99.1-alpha has been released!
This is an experimental release meant for testing aggressive caching.
It contains some regressions and might (theoretically) be even vulnerable.
The current focus is to minimize queries into the root zone.
Improvements
--
On 10/09/2017 05:08 PM, Daniel Kahn Gillmor wrote:
> On Sun 2017-10-08 05:33:47 -0400, Thomas Van Nuit wrote:
>>> FreeBind=true
>>> Should I also try 'After=network-online.target' instead of FreeBind?
>>> And if it helps, which of those two is a more proper way to handling
>>> this issue?
> I think
On 09/22/2017 04:31 PM, Yoshihito Horigome wrote:
> I hope Ubuntu PPA will also update.
> https://launchpad.net/~cz.nic-labs/+archive/ubuntu/knot-resolver
For reference, all PPAs were updated to 1.4.0 several days ago. I hope
there will be no problems with the packages.
--Vladimir
__
Hi.
On 10/04/2017 11:43 PM, Robert Edmonds wrote:
> I'm getting an HTTP 500 error from https://gitlab.labs.nic.cz/[...]
It works for me now. I'm not aware of anyone trying to fix it, though.
--Vladimir
___
knot-dns-users mailing list
knot-dns-users@l
On 10/01/2017 11:26 PM, Thomas Van Nuit wrote:
> What is the proper way of autostarting Knot Resolver 1.4.0 on systemd
> (Debian Stretch in my case) to be able to listen on interfaces other
> from localhost?
> [...]
> Oct 01 23:17:12 systemd[1]: kresd.socket: Failed to
> listen on sockets: Cannot
Hello.
On 10/01/2017 10:31 PM, Thomas Van Nuit wrote:
> I have a fresh install of Debian Stretch with all updates and Knot
> Resolver 1.4.0. installed from CZ.NIC repositories. I've set up a
> rather simple configuration allowing our users to use the resolver and
> everything works fine (systemd s
Dear Knot Resolver users,
Knot Resolver 1.4.0 has been released!
Incompatible changes
- lua: query flag-sets are no longer represented as plain integers.
kres.query.* no longer works, and kr_query_t lost trivial methods
'hasflag' and 'resolved'.
You can instead write co
Dear Knot Resolver users,
Knot Resolver 1.3.3 is a critical security release!
Security
- Fix a critical DNSSEC flaw. Signatures might be accepted as valid
even if the signed data was not in bailiwick of the DNSKEY used to
sign it, assuming the trust chain to that DNSKEY was valid.
Dear Knot Resolver users,
Knot Resolver 1.3.2 maintenance update has been released:
Security
- fix possible opportunities to use insecure data from cache as keys
for validation
Bugfixes
- daemon: check existence of config file even if rundir isn't specified
- policy.FORWARD a
On 07/21/2017 11:51 AM, Yoshihito Horigome wrote:
> Thank you for the information.
> Is fork still to be an experimental parameter?
>
> As it is commonly used, it is not mandatory as myself, so for the
> moment I think whether to deal with the parameter removed.
If you run kresd without (direct) s
Hello!
On 07/21/2017 11:31 AM, Yoshihito Horigome wrote:
> /usr/sbin/kresd -c /etc/knot-resolver/kresd.conf -v -f 4 -k
> /etc/knot-resolver/root.key /var/knot-resolver
I don't immediately see what happens in your case, but so far kresd does
not support running under systemd supervision with multi
On 06/26/2017 12:23 PM, Leo Vandewoestijne wrote:
> So before I continue in making a meta-port or the knot2 port, just for the
> sake of libknot,
> I'm wondering;
> wouldn't other OS'es packaging systems not benefit from having libknot
> seperate from knot?
The typical setup in (Linux) distros i
Dear Knot Resolver users,
Knot Resolver 1.3.1 has been released with a few bugfixes atop 1.3.0, notably:
- modules/http: fix finding the static files (bug from 1.3.0)
- policy.FORWARD: fix some cases of CNAMEs obstructing search for zone cuts
It is recommended to update from 1.3.0, and it's stro
On 05/13/2017 02:30 AM, Yoshihito Horigome wrote:
> I tried to enable HTTP/2 services by referring to the following
> document, it was not found.
> [...]
> In the following environments, but we have introduced from the
> repository, do you have, such as a separate package necessary?
The http modul
Hello!
On 05/12/2017 11:06 AM, Jerry Lundström wrote:
> [...] what I want is to redirect a zone to
> a local DNS server and I also want the resolver to follow any
> delegations it receives.
I'm afraid I can't see a simple way to do exactly that.
It's simple to forward some zones to other *resolv
On 04/18/2017 01:56 PM, Horigome Yoshihito wrote:
> As I advised, I added policy, but it seems that I can not reverse
> lookup it again.
Right, I made a mistake in the command :-) This time I tested it tries
to forward the query:
policy.add(policy.suffix(policy.FORWARD('192.168.122.223@10053',
'
On 04/18/2017 01:33 PM, Horigome Yoshihito wrote:
> As you say, adding policy.del(0) no longer gets blocked.
> However, it is as follows and ANSWER is not returned.
The config you sent did not forward any reverse address ranges. Adding
rule for that should do what you want, if I guess your intent
Hello.
On 04/14/2017 04:02 PM, Horigome Yoshihito wrote:
> I set it up as below and forward it to kometch.local of the internal
> domain which is the stub zone, but when reverse lookup it will be
> output as block. [...]
The problem there is that the policy module contains an implicit rule
that
Hello!
On 03/30/2017 12:58 AM, Daniel Kahn Gillmor wrote:
> I'm running kresd 1.2.4. If i start it with an empty/missing cache, and
> then receive a query for an A record for "www.ietf.org", there is a
> substantial delay in the response.
> [...]
> In particular, the delay appears to be related t
On 02/08/2017 02:47 PM, Horigome Yoshihito wrote:
> Do I need to do something?
No idea. When this happened, resolver seemed to continue to work,
right? (Even though prefetching probably stopped.)
___
knot-dns-users mailing list
knot-dns-users@lists.nic
On 02/08/2017 02:26 PM, Horigome Yoshihito wrote:
> Feb 06 20:19:43 dns02 kresd[24857]: error:
> /usr/lib/knot-resolver/predict.lua:34: 'struct rr_type' has no member
> named 'nil'
> [...]
>
> Is it related to setting reorder_RR (true)?
>
> Is this a configuration issue in this case? Or is it a kno
Hi,
I hope English will be understandable enough (to you).
On 11/23/2016 11:00 PM, Pavol wrote:
> I am trying to get knot 2.3.1 (from ports) working in a jail, but I am
> unable to connect to the udp port even when trying directly from jail.
> Using netcat from within jail and also from other mach
Hello John-Paul.
On 11/14/2016 07:36 PM, John-Paul Gignac wrote:
> I'm an engineer at Dyn and I work on the same team as Matthijs Mekking.
>
> I noticed that commit 3f950e1d
> (https://gitlab.labs.nic.cz/labs/knot/commit/3f950e1d3f323b0ebbd339de29f8c8b4568706ad)
> changes the handling of the CD bi
Thank you!
I filed a gitHub issue to track this:
https://github.com/CZ-NIC/knot-resolver/issues/34
(It should be easier for people to login/comment in there.)
--Vladimir
___
knot-dns-users mailing list
knot-dns-users@lists.nic.cz
https://lists.nic.cz
48 matches
Mail list logo
