ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Merge branch '4156-docs-ephemeral-tls-recreation' into 'main'

Browse Source 
Improve documentation on ephemeral TLS configuration

Closes #4156

See merge request isc-projects/bind9!8771
This commit is contained in:
Artem Boldariev
2024-02-28 19:40:35 +00:00
parent 5b23c964e2 1ab0f6d918
commit 264a3a92b2
1 changed files with 19 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
doc/arm/reference.rst
View File

@@ -5967,6 +5967,25 @@ uses a temporary key and certificate created for the current :iscman:`named`
session only, and ``none``, which can be used when setting up an HTTP
listener with no encryption.
The main motivation behind having the ``ephemeral`` configuration is
to aid in testing, as trusted certificate authorities do not issue the
certificates associated with this configuration. Thus, these
certificates will never be trusted by any clients that verify TLS
certificates. They provide encryption of the traffic but no
authentification of the transmission channel. That might be enough in
the case of deployment in a controlled environment.
It should be noted that on reconfiguration, the ``ephemeral`` TLS key
and the certificate are recreated, and all TLS certificates and keys,
as well as associated data, are reloaded from the disk. In that case,
listening sockets associated with TLS remain intact.
Please keep in mind that doing reconfiguration can cause a short
interruption in BIND's ability to process inbound client packets. The
length of interruption is environment and configuration-specific. A
good example of when reconfiguration is necessary is when TLS keys and
certificates are updated on the disk.
BIND supports the following TLS authentication mechanisms described in
the RFC 9103, Section 9.3: Opportunistic TLS, Strict TLS, and Mutual
TLS.