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
On 31/05/2024 19.00, oui.mages_0w(a)icloud.com wrote:
> we have different TLS domains/certificates for dns64 and non dns64
Oh, OK. Such a thing hasn't occurred to us, so it's not possible. In
that case I expect you'll need to stay on 5.x for now, with separate
processes for dns64 and non-dns64 (but they can share the cache).
Overall I don't think the current code can support multiple certificates.
On 31/05/2024 13.04, oui.mages_0w(a)icloud.com wrote:
> Unless the policy module allows to filter by listened IP, I will still
> need to use split instances: we don’t select on the server side which
> client is to use dns64 or not, but as an ISP, we leave the choice to
> the clients to decide which dns resolver they want to use (one of ours
> with or without dns64, or a third party).
That is possible, but with 5.x I probably wouldn't recommend it, as it's
been left out of documentation (by mistake) and overall I don't have
much trust in that part of 5.x policies.
But after you migrate to >= 6.x, I would recommend just having a single
shared configuration. And in views you can select dst-subnet paired
with dns64 options. Such deployments were taken into account when
designing 6.x views.
https://www.knot-resolver.cz/documentation/latest/config-views.html#config-…
In 6.x it would probably also be harder for you to run multiple
configurations at once on a single machine, so that's another reason to
unify this when you migrate.
--Vladimir
On 14/05/2024 08.10, Josef Karliak via knot-dns-users wrote:
>
> ISC bind is strict about CNAME of NS server:
>
> skipping nameserver 'aa.bb.cz' *because it is a CNAME*, while
> resolving '9.4/4.3.2.1.in-addr.arpa/PTR'.
>
> How about Knot resolver ?
>
Hello. I believe there is neither effort to disallow them nor to make
them work. Off the top of my head I'm not sure how it will be in
practice; you could just try. Either way, please don't use them.
(I replied to the correct mailing-list.)
--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.
Anyway, it would be better to continue this thread on
knot-resolver-users(a)lists.nic.cz
(I already have posted there about this a couple days ago.)
--Vladimir
