GitLab

Description

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.

Feature Request

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
  • * XoT requires dot ALPN token to be negotiated (See: #2794 (closed))
  • * XoT requires TLSv1.3 or higher (See: #2795 (closed), and related #2796 (closed))
• * 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-only with a more generic option (#2992)
• * 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.

Related issues/bugs

• * #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 ephemeral in transport list, see bin/named/transportconf.c (?);
• on a similar note, there is doh mentioned in the transport list. It seems that it also does not do anything, and at the very last should be changed to http as 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