RFC9103: DNS Zone Transfer over TLS (XoT)
The RFC9103 describes the use of TLS to encrypt zones transfers in order to provide confidentiality, known as XFR-over-TLS (XoT). The standard has been adopted by the DPRIVE WG.
The feature request is for BIND to support XFR-over-TLS as described in the above RFC. This will obviously be dependent on DoT (RFC7858) being implemented in BIND. The specific aspects of the XoT implementation that are desired are:
- * Support for both AXFR and IXFR
- * Support for XFR-over-TLS both when BIND is acting as a primary and a secondary
* XFR-over-TLS (XoT): Primaries need to be able to restrict XFR to just TLS (#2776 (closed))
* Related: Replace
tcp-onlywith a more generic option (#2992)
- * Related: Replace
* Support for authentication of TLS connections via X.509 certificates (Strict TLS)
- Related MR: !5600 (merged)
- * A TLS contexts cache needs to be implemented for contexts reuse and fast retrieval of the data associated with contexts (like CA intermediates chain): #3067 (closed), !5672 (merged)
- * Add remote TLS certificate verification support, implement Strict and Mutual TLS authentication (#3163 (closed))
- * Optimisation of TCP/TLS connections such that persistent connections can be re-used for multiple IXFRs for the same zone, and also IXFRs for different zones.
* #2450 - Follow-up from "Draft: Resolve "XoT xfrin""
- See !5602 (merged) which addresses the most important points from the issue
- * #2884 (closed) - Sometimes dig aborts on an AXFR query over TLS
- * #2986 (closed) - TLS not working on the client-side (dig/named)
- * #3004 (closed) - dig and named crash when receiving XFR over TLS
Things to be aware of
There are some TLS/XoT related options that are for now nothing more than a stub - that is, they do not do anything. If we do not end up using them before the 9.18 gets cut out of the
main, we should remove them from the configuration parsing code, even though we might reintroduce them later as soon as the features where they are needed are actually implemented. The idea is that it is fine to add a new option even into the stable release, but it is absolutely impossible to remove one quickly after the release, so we might need to be extra cautious here, considering that we might not even be sure that configuration options are needed until features that require them are fully implemented.
The list of such options (might be not complete):
tls ephemeralin transport list, see
- on a similar note, there is
dohmentioned in the transport list. It seems that it also does not do anything, and at the very last should be changed to
httpas it is named everywhere else. I am not convinced that we should have any extra DoH options apart from the ones we already implemented.
See RT #16298