This release fixes a crash in dnstap. New features are XoT which
provides AXFR and IXFR over TLS, and DNS Cookies support and SVCB and
HTTPS RR type support.
For zone transfer TLS can be turned on by specifying the tls-auth-name
in the request-xfr config option, like
request-xfr: 192.0.2.1 NOKEY ns.example.com
With the tls-cert-bundle option, in the server section, the list of
certificates for authenticating the transfers over TLS can be configured.
The DNS cookies can be turned on or off with the answer-cookie option,
and instead of a randomly generated secret, for anycast or loadbalanced
deployment, the secret can be configured with cookie-secret or
cookie-secret-file and rollover of the cookie secret can be performed
with the nsd-control commands add_cookie_secret, activate_cookie_secret
and drop_cookie_secret, using the cookie-secret-file.
The SVCB and HTTPS RR type support mean that in zone files the syntax
for these RR types can be used and is written when a zone is downloaded.
In previous versions the unknown RR type support code provided a
fallback syntax in zone files and on the wire functionality for these types.
* Only the client side is mentioned here. Is the server side already implemented?
Otherwise XoT between two NSD instances is not possible yet.
Some clarification would be helpful.
The server side of DNS over TLS service is enabled like other DNS over
TLS service. NSD can then also service zone transfers over TLS, using
the configured options for that. The tls-service-key and tls-service-pem
options.
This release fixes a crash in dnstap. New features are XoT which
provides AXFR and IXFR over TLS, and DNS Cookies support and SVCB and
HTTPS RR type support.
For zone transfer TLS can be turned on by specifying the tls-auth-name
in the request-xfr config option, like
request-xfr: 192.0.2.1 NOKEY ns.example.com
With the tls-cert-bundle option, in the server section, the list of
certificates for authenticating the transfers over TLS can be configured.
The DNS cookies can be turned on or off with the answer-cookie option,
and instead of a randomly generated secret, for anycast or loadbalanced
deployment, the secret can be configured with cookie-secret or
cookie-secret-file and rollover of the cookie secret can be performed
with the nsd-control commands add_cookie_secret, activate_cookie_secret
and drop_cookie_secret, using the cookie-secret-file.
The SVCB and HTTPS RR type support mean that in zone files the syntax
for these RR types can be used and is written when a zone is downloaded.
In previous versions the unknown RR type support code provided a
fallback syntax in zone files and on the wire functionality for these types.
Compared to the pre-release version there are a couple small bugfixes in
the final release version, notably a fix for failure to compile without
ipv6.
thanks for XoT in NSD. Now AXFR over TLS is possible. I ask myself if it makes sense
to enforce TLS for zone transfer. This would require support to actively
deny AXFR on non-tls connections.
I see these options:
1) simply deny plaintext
For this it would be enough, if the 'provide-xfr' statement would
understand a new directive like 'require-tls', 'disable-plaintext' or simply 'tls'
2) require mutual TLS
as an enhancement to 1) 'provide-xfr' could understand a new directive
'tls-auth'. The NSD requesting a AXFR via TLS must send it's own
TLS certificate. The NSD providing AXFR must check the certificate
against it's tls-cert-bundle.
3) for some installations only point-to-point connections are configured
In this case <ip-spec> in 'provide-xfr' is a plain IP address, not a subnet.
Then it could be possible to also check the client's auth-name.