Hello,

After simplifying to only one certificate for DoH and DoT (with an alt name for the dns64 domain), we were able to migrate to version 6.x with a single shared configuration, and it works quite well. It is a lot cleaner and clearer as well and the dst-subnet option in views is very useful :)

We experienced a little bug with subnets in views though.

With this type of configuration:

(…)
dns64: true
views:
  - subnets: ['0.0.0.0/0', '::/0']
    answer: refused
  - subnets: ['127.0.0.0/8', (more IPv4 subnets)]
    answer: allow
    options:
      dns64: false
  - subnets: ['::1/128', '2001:0db0::/31']
    dst-subnet: 2001:0123:53::1
    answer: allow
    options:
      dns64: false
  - subnets: ['::1/128', '2001:0db0::/31']
    dst-subnet: 2001:0123:53::64
    answer: allow
(…)

All queries received on a correct dst-subnet and sent from the subnet 2001:0db0::/31 were refused when they should have been allowed!

However, we got this to work by splitting the /31 into two /32 in the config file:

(…)
dns64: true
views:
  - subnets: ['0.0.0.0/0', '::/0']
    answer: refused
  - subnets: ['127.0.0.0/8', (more IPv4 subnets)]
    answer: allow
    options:
      dns64: false
  - subnets: ['::1/128', '2001:0db0::/32’, '2001:0db1::/32']
    dst-subnet: 2001:0123:53::1
    answer: allow
    options:
      dns64: false
  - subnets: ['::1/128', '2001:0db0::/32’, '2001:0db1::/32']
    dst-subnet: 2001:0123:53::64
    answer: allow
(…)

Regards,

--Bolemo


Le 7 juin 2024 à 13:05, gabriel@brigadoon.fr a écrit :

Thank you for all your insight.

I have tested with one certificate that includes the separate dns64 domain as an alternative name, and it works fine.
It is simpler and just requires a unique certificate for dns64 and non dns64 for DoT and DoH.

So I will set that change in production first, and then I will be able to test version 6.x

--Bolemo

Le 31 mai 2024 à 20:36, Vladimír Čunát via knot-resolver-users <knot-resolver-users@lists.nic.cz> a écrit :

On 31/05/2024 19.00, oui.mages_0w@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.


--