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
Hi Andreas, Good to hear compilation works as expected. I'll start looking into the notes/issues tomorrow. 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
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