Hi Andreas,
The suggestions I captured in GitHub issues. Thanks for sharing.
Regarding whether notifies are still plain UDP. Yes, the config parser
doesn't accept additional arguments to "notify" and judging by the
xfrd
code anything to do with notify is using UDP, so no TLS yet.
I've added a GitHub issue for this too.
Thanks for the suggestions. They make for nice additions/improvements.
I'll try to get to them for the next release (>4.10.1).
Best regards,
Jeroen
On Thu, 2024-07-25 at 00:00 +0200, A. Schulze via nsd-users
wrote:>
>
> Am 23.07.24 um 17:28 schrieb Jeroen Koekkoek via nsd-users:
> > NSD 4.10.1rc2 pre-release is available:
>
> no compile time warnings while building on debian bookworm/x86_64
>
> > @bilias implemented mutual TLS authentication for zone transfers.
> > Please consult the nsd.conf manual for details on the newly
> > introduced
> > configuration options tls-auth-port and tls-auth-xfr-only.
>
> this is an nice feature that seem to work but have some nits.
>
> nsd serving as simple tls server is configured with
>
> server:
> username: nsd
> ???????? ip-address: ::@853
> ???????? tls-service-key: /path/to/key.pem
> ???????? tls-service-pem: /path/to/cert+intermediate.pem
> ???????? tls-port: 853
>
> ???????? # since 4.10.1rc2
> ???????? ip-address: ::@1853
> ???????? tls-auth-port: 1853
> ???????? tls-auth-xfr-only: yes
> ???????? tls-cert-bundle: /path/to/ca-certificates.crt
>
>
> in this mode, /path/to/*.pem may accessible for the root user only.
>
> Now, when adding a tls-auth for the purpose of client authentication
> I add
>
> tls-auth:
> ???????? name: primary.nsd.example
> ???????? auth-domain-name: primary.nsd.example
> ???????? client-cert: /path/to/cert+intermediate.pem
> ???????? client-key: /path/to/key.pem
>
> Here, the files /path/to/*.pem are used by a child process with
> limited privileges of the username 'nsd'
> It would be better, if nsd read all tls-auth client-[cert|key] data
> before dropping privileges.
> Then the files could be still limited to be readable by the root
> user.
>
> next question:
> now, the axfr request from secondary to primary is a mTLS connection.
> But what about notify messages
> from primary to secondary? the zone-statement 'notify' does not
> mention a tls-auth-name
> Are these notifies still plain, unencrypted, unauthenticated UDP
> packets?
>
> next note:
> I used an IPv6 network for my zone transfer tests and have the
> impression,
> the outgoing-interface statement at the secondary is not working if
> AXFR-over-tls is used.
>
> next note:
> while trying to get AXFR-over-tls working, I saw errors like "error:
> xfrd tls: TLS verify failed - (62) depth: 0 error: hostname mismatch"
> It would be helpful to see there "... hostname mismatch: expected
> 'foo', got 'bar'"
>
> funny side note:
> after "error: xfrd tls: TLS verify failed - (62) depth: 0 error:
> hostname mismatch" I also saw
> "error: xfrd: TLS handshake failed: Success"
>
> Andreas
> _______________________________________________
> nsd-users mailing list
> nsd-users at lists.nlnetlabs.nl
> https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users