cluster creation settings

[bboeckling]

Thank you @ShreyasZare for the awesome new release!

I'm struggling where to ask the following questions, as i think it could result in some code change, i use the issue section.

1. Initializing a cluster asks for a "Cluster Domain", with the tooltip beneath to provide a "fully qualified domain name". From my perspective, these are different information, as the fqdn also includes the hostname of the machine, while the domain name does not. May you clarify this in the tooltip what you expect the user to provide.

As i look into it i see that the same applies to Settings >> General >> DNS Server Domain, which seems to be only accessible when the node is not part of a cluster.

2. Creating a cluster also asks for a 'Primary Node IP Address'. This is prefilled by the ip of the primary network interface of the host i guess.
   My technitium lives in docker and this dropdown only shows me the docker bridge network internal IP. As i plan to host the second node on a second physical machine, this internal docker IP can never be resolved by other nodes.
   Can we provide the docker host IP via ENV or setting in the GUI, so we can use it for cluster creation?

I'll include my last one here, as it's somehow related to the first one:

3. My "homelab"-domain has to be a forwarding zone, as the domain itself is managed by public DNS servers. All my records in my homelab are under a subdomain, let's say: 'lan.foo.bar'. As i rely on this to be able to create Let's Encrypt certificates for my local subdomain. Creating a cluster won't let me use the 'lan.foo.bar' as cluster domain, because it needs to be a primary zone.
   Using 'lan.foo.bar' as cluster domain seems to me 'the way', as my node is accessible via 'ns01.lan.foo.bar'.

Using an other cluster domain does furhtermore crazy things to the server name in this scenario: Let's say my public domain is 'foo.bar' and my local used dns domain is 'lan.foo.bar'. The first node therefore is called 'ns01.lan.foo.bar', where 'lan.foo.bar' is a conditional forward zone.
Creating a cluster domain, let's say 'local.foo.bar' renames my node to: 'ns01.lan.foo.bar.local.foo.bar'.
If you plan to include these information in a blog post about the update, I'll just wait for the upcoming information.

[srt4fun]

@bboeckling

Using an other cluster domain does furhtermore crazy things to the server name in this scenario: Let's say my public domain is 'foo.bar' and my local used dns domain is 'lan.foo.bar'. The first node therefore is called 'ns01.lan.foo.bar', where 'lan.foo.bar' is a conditional forward zone.
Creating a cluster domain, let's say 'local.foo.bar' renames my node to: 'ns01.lan.foo.bar.local.foo.bar'.
If you plan to include these information in a blog post about the update, I'll just wait for the upcoming information.

I experienced the same naming malfunction. To mitigate this, I simply renamed the server (settings>general>"DNS Server Domain") to remove domain suffix prior to creating/joining the cluster. Before attempting the below procedure, I would recommend that you start fresh with your cluster config (delete cluster and delete any leftover cluster zones from your primary)

So for your environment:
-rename 'ns01.lan.foo.bar' to 'ns01'
-create cluster local.foo.bar
-ns01 is then renamed to 'ns01.local.foo.bar'
-rename 'ns02.lan.foo.bar' to 'ns02'
-join cluster
-ns02 automatically renames to 'ns02.local.foo.bar'

[ShreyasZare]

Thank you @ShreyasZare for the awesome new release!

Thanks for the compliments.

I'm struggling where to ask the following questions, as i think it could result in some code change, i use the issue section.

1. Initializing a cluster asks for a "Cluster Domain", with the tooltip beneath to provide a "fully qualified domain name". From my perspective, these are different information, as the fqdn also includes the hostname of the machine, while the domain name does not. May you clarify this in the tooltip what you expect the user to provide.

Yes, will be adding some more info in the GUI so that its clear.

As i look into it i see that the same applies to Settings >> General >> DNS Server Domain, which seems to be only accessible when the node is not part of a cluster.

When clustering is enabled, the Settings are split in to cluster options and node specific options. You need to use the node selector drop down in there to switch to the required node to be able to change options specific to it.

2. Creating a cluster also asks for a 'Primary Node IP Address'. This is prefilled by the ip of the primary network interface of the host i guess.
   My technitium lives in docker and this dropdown only shows me the docker bridge network internal IP. As i plan to host the second node on a second physical machine, this internal docker IP can never be resolved by other nodes.
   Can we provide the docker host IP via ENV or setting in the GUI, so we can use it for cluster creation?

The static IP must be accessible on the host system so you need to setup docker to run in host networking mode so that the static IP on the host system can be used.

I'll include my last one here, as it's somehow related to the first one:

3. My "homelab"-domain has to be a forwarding zone, as the domain itself is managed by public DNS servers. All my records in my homelab are under a subdomain, let's say: 'lan.foo.bar'. As i rely on this to be able to create Let's Encrypt certificates for my local subdomain. Creating a cluster won't let me use the 'lan.foo.bar' as cluster domain, because it needs to be a primary zone.
   Using 'lan.foo.bar' as cluster domain seems to me 'the way', as my node is accessible via 'ns01.lan.foo.bar'.

The cluster requires having a primary zone to work so you will need to use a different domain name for the cluster zone and it will work. You can still have your existing local zone work the same way. The only thing is that the DNS server domain name has to be a subdomain of the cluster zone.

The DNS server domain name does not affect anything else and is just an identifier for the DNS server. You can still have your existing local zone and use a subdomain in it to access your DNS server.

Using an other cluster domain does furhtermore crazy things to the server name in this scenario: Let's say my public domain is 'foo.bar' and my local used dns domain is 'lan.foo.bar'. The first node therefore is called 'ns01.lan.foo.bar', where 'lan.foo.bar' is a conditional forward zone. Creating a cluster domain, let's say 'local.foo.bar' renames my node to: 'ns01.lan.foo.bar.local.foo.bar'. If you plan to include these information in a blog post about the update, I'll just wait for the upcoming information.

Yes, currently it just uses the existing DNS server domain name as the subdomain name of the cluster zone. You can change the DNS server domain name from Settings later by selecting the node from the node selector drop down at the top right corner on the section.

[bboeckling]

Great, thank you for all the input!

I'm struggling where to ask the following questions, as i think it could result in some code change, i use the issue section.

1. Initializing a cluster asks for a "Cluster Domain", with the tooltip beneath to provide a "fully qualified domain name". From my perspective, these are different information, as the fqdn also includes the hostname of the machine, while the domain name does not. May you clarify this in the tooltip what you expect the user to provide.

Yes, will be adding some more info in the GUI so that its clear.

Can you tell me which information technitium then expects in the two settings? Is it different if using cluster mode?

As i look into it i see that the same applies to Settings >> General >> DNS Server Domain, which seems to be only accessible when the node is not part of a cluster.

When clustering is enabled, the Settings are split in to cluster options and node specific options. You need to use the node selector drop down in there to switch to the required node to be able to change options specific to it.

Didn't see the option on first sight, thank you for claryfing that.

2. Creating a cluster also asks for a 'Primary Node IP Address'. This is prefilled by the ip of the primary network interface of the host i guess.
   My technitium lives in docker and this dropdown only shows me the docker bridge network internal IP. As i plan to host the second node on a second physical machine, this internal docker IP can never be resolved by other nodes.
   Can we provide the docker host IP via ENV or setting in the GUI, so we can use it for cluster creation?

The static IP must be accessible on the host system so you need to setup docker to run in host networking mode so that the static IP on the host system can be used.

Gotcha, that would work. However I don't set containers to host mode if there is no specific need to, as it stops me from controlling which ports are exposed by the container. As i use technitium only for DNS, but not for DHCP, i have no specific reason to do so. Are you planning to support this use case or is there some criteria, that using host mode in this scenario is the only way?

Using an other cluster domain does furhtermore crazy things to the server name in this scenario: Let's say my public domain is 'foo.bar' and my local used dns domain is 'lan.foo.bar'. The first node therefore is called 'ns01.lan.foo.bar', where 'lan.foo.bar' is a conditional forward zone. Creating a cluster domain, let's say 'local.foo.bar' renames my node to: 'ns01.lan.foo.bar.local.foo.bar'. If you plan to include these information in a blog post about the update, I'll just wait for the upcoming information.

Yes, currently it just uses the existing DNS server domain name as the subdomain name of the cluster zone. You can change the DNS server domain name from Settings later by selecting the node from the node selector drop down at the top right corner on the section.

So the intended way to configure this would be cutting the domain part from the 'DNS Server Domain' node setting and only filling the hostname, so that in cluster mode the cluster domain would be added tot the hostname and the device will be called 'ns01.local.foo.bar' furthermore?
I am really interested in your opinion and really like to hear your thoughts on that.

[ShreyasZare]

Great, thank you for all the input!

You're welcome!

Yes, will be adding some more info in the GUI so that its clear.

Can you tell me which information technitium then expects in the two settings? Is it different if using cluster mode?

The cluster domain name is the name of the zone that the cluster will use for its management. It is not the domain name of the DNS server. This can be a domain name of an existing zone that you have. It can be any domain name, a publicly resolvable one or a private zone in your local network.

The v14.0.1 adds some more text in the GUI to explain it a bit in more detail.

When clustering is enabled, the Settings are split in to cluster options and node specific options. You need to use the node selector drop down in there to switch to the required node to be able to change options specific to it.

Didn't see the option on first sight, thank you for claryfing that.

You're welcome.

The static IP must be accessible on the host system so you need to setup docker to run in host networking mode so that the static IP on the host system can be used.

Gotcha, that would work. However I don't set containers to host mode if there is no specific need to, as it stops me from controlling which ports are exposed by the container. As i use technitium only for DNS, but not for DHCP, i have no specific reason to do so. Are you planning to support this use case or is there some criteria, that using host mode in this scenario is the only way?

This requirement for a static IP on the system is deliberately made so as to avoid people using dynamic IP on the server which can cause the cluster to stop working later if the IP changes. The cluster feature thus expects that all nodes have a static IP address so that it can work consistently.

The other reason is that the cluster nodes must communicate with each other directly without any thing in the middle since the cluster API token must be kept secure to protect the cluster. It uses DANE-EE to ensure security such that its connecting to the end node directly.

Yes, currently it just uses the existing DNS server domain name as the subdomain name of the cluster zone. You can change the DNS server domain name from Settings later by selecting the node from the node selector drop down at the top right corner on the section.

So the intended way to configure this would be cutting the domain part from the 'DNS Server Domain' node setting and only filling the hostname, so that in cluster mode the cluster domain would be added tot the hostname and the device will be called 'ns01.local.foo.bar' furthermore? I am really interested in your opinion and really like to hear your thoughts on that.

The v14.0.1 now uses only the "hostname" part and sets the DNS Server Domain Name to "hostname.cluster-domain". This was done due to multiple feedback that I received.

You can edit the DNS Server Domain Name from the Settings later too but it must end with the cluster domain name (must be a subdomain name of the cluster domain).

[bboeckling]

Yes, will be adding some more info in the GUI so that its clear.

Can you tell me which information technitium then expects in the two settings? Is it different if using cluster mode?

The cluster domain name is the name of the zone that the cluster will use for its management. It is not the domain name of the DNS server. This can be a domain name of an existing zone that you have. It can be any domain name, a publicly resolvable one or a private zone in your local network.

Thanks for the clarification! Will look further into it and do some testing to get comfortable with it.

The v14.0.1 adds some more text in the GUI to explain it a bit in more detail.

I've noticed the new Note in the modal, which pops up when initializing a cluster. This helps to understand the changes, which are made.
I guess the tooltip right beneath the form field "Cluster Domain", which says 'The fully qualified domain name to be used to identify the new Cluster.' is still confusing, isn't it? The fqdn includes the hostname of a device and is therefore the 'exact location in the tree hierarchy of the Domain Name System (DNS).' Source
This also applies to Settings > General > DNS Server Domain as well as Administration > Cluster > Options (which is reasonably read-only).

The static IP must be accessible on the host system so you need to setup docker to run in host networking mode so that the static IP on the host system can be used.

Gotcha, that would work. However I don't set containers to host mode if there is no specific need to, as it stops me from controlling which ports are exposed by the container. As i use technitium only for DNS, but not for DHCP, i have no specific reason to do so. Are you planning to support this use case or is there some criteria, that using host mode in this scenario is the only way?

This requirement for a static IP on the system is deliberately made so as to avoid people using dynamic IP on the server which can cause the cluster to stop working later if the IP changes. The cluster feature thus expects that all nodes have a static IP address so that it can work consistently.

I understand the reason for setting the static IP. Still thinking about a solution when using docker bridge network with exposed ports and not using network mode host. I guess it's not possible to grab the host IP from the container with no access to the docker socket, so you may add the option to set an IP manually?

The other reason is that the cluster nodes must communicate with each other directly without any thing in the middle since the cluster API token must be kept secure to protect the cluster. It uses DANE-EE to ensure security such that its connecting to the end node directly.

Reasonable.
Does 'without any thing in the middle' also include reverse proxy setups? I guess in the context of docker reverse proxies such as traefik, caddy or npm are widely used. For example my setup only exposes ports 53/ucp and 53/tcp to the host to be accessible in the network. The web ui is reverse proxied behind traefik, so neither 5380/tcp nor 53443/tcp need to be exposed. I work with Let's Encrypt certificates also in my local network.
Will this still work or does the secure connection persist on using the internal CA?

This also rises the question about the URL which is generated after initializing a cluster. In my case it's 'https://ns01.local.foo.bar:53443'. Since I use 443/tcp for web ui, can I manually change the URL for syncing purposes?

After trying to setup a cluster between two nodes ns01 and ns02, it forces me to use the docker internal IPs and forces me to use the URLs 'https://ns01.local.foo.bar:53443' and 'https://ns02.local.foo.bar:53443', resulting in a 'Unreachable' state, which is understandable because each node is neither accessible via the docker internal IP nor via Port 53443.

Is this considered a use case you plan to support with Technitium?

Yes, currently it just uses the existing DNS server domain name as the subdomain name of the cluster zone. You can change the DNS server domain name from Settings later by selecting the node from the node selector drop down at the top right corner on the section.

So the intended way to configure this would be cutting the domain part from the 'DNS Server Domain' node setting and only filling the hostname, so that in cluster mode the cluster domain would be added tot the hostname and the device will be called 'ns01.local.foo.bar' furthermore? I am really interested in your opinion and really like to hear your thoughts on that.

The v14.0.1 now uses only the "hostname" part and sets the DNS Server Domain Name to "hostname.cluster-domain". This was done due to multiple feedback that I received.

You can edit the DNS Server Domain Name from the Settings later too but it must end with the cluster domain name (must be a subdomain name of the cluster domain).

Great, this seems to be a more appropriate way to handle this.

[ShreyasZare]

I've noticed the new Note in the modal, which pops up when initializing a cluster. This helps to understand the changes, which are made.
I guess the tooltip right beneath the form field "Cluster Domain", which says 'The fully qualified domain name to be used to identify the new Cluster.' is still confusing, isn't it? The fqdn includes the hostname of a device and is therefore the 'exact location in the tree hierarchy of the Domain Name System (DNS).' Source
This also applies to Settings > General > DNS Server Domain as well as Administration > Cluster > Options (which is reasonably read-only).

The FQDN really means that you provide a complete domain name and not a relative one. What you are saying is not something the source link says.

I understand the reason for setting the static IP. Still thinking about a solution when using docker bridge network with exposed ports and not using network mode host. I guess it's not possible to grab the host IP from the container with no access to the docker socket, so you may add the option to set an IP manually?

I am getting multiple feedback on this issue. So will be analyzing if the restriction for static IP can be relaxed without any issues.

Reasonable.
Does 'without any thing in the middle' also include reverse proxy setups? I guess in the context of docker reverse proxies such as traefik, caddy or npm are widely used. For example my setup only exposes ports 53/ucp and 53/tcp to the host to be accessible in the network. The web ui is reverse proxied behind traefik, so neither 5380/tcp nor 53443/tcp need to be exposed. I work with Let's Encrypt certificates also in my local network.
Will this still work or does the secure connection persist on using the internal CA?

Once a node joins the cluster, it will use DANE-EE so if you have reverse proxy in between, the cert it returns will fail validation. Its done so that the cluster nodes directly communicate with each other without leaking the API token used by the cluster and also to prevent leaking DNSSEC private keys that get transferred to all the nodes.

Making it work with reverse proxy means that the nodes are no longer talking with each other directly and there is a scope of leaking the secrets.

This also rises the question about the URL which is generated after initializing a cluster. In my case it's 'https://ns01.local.foo.bar:53443/'. Since I use 443/tcp for web ui, can I manually change the URL for syncing purposes?

The domain in the URL and the port does not matter once node joins cluster since DANE-EE only validates the TLS certificate that it receives. So you can use a TCP reverse proxy instead of HTTP reverse proxy technically (once the static IP check is removed).

After trying to setup a cluster between two nodes ns01 and ns02, it forces me to use the docker internal IPs and forces me to use the URLs 'https://ns01.local.foo.bar:53443/' and 'https://ns02.local.foo.bar:53443/', resulting in a 'Unreachable' state, which is understandable because each node is neither accessible via the docker internal IP nor via Port 53443.
Is this considered a use case you plan to support with Technitium?

The nodes need to be reachable by each other which is a requirement so such a setup wont work. The network setup needs to allow access to all nodes.

Based on the feedback that I am getting, some of these things may change a bit so that the cluster setup works for most common scenarios.

[bboeckling]

The FQDN really means that you provide a complete domain name and not a relative one. What you are saying is not something the source link says.

I don't understand why you think my definition differs from the source. The FQDN includes a hostname, do we agree? Given this circumstance, if we use the FQDN initializing the cluster, we need to type in: 'ns1.mycluster.tld' to stick with your syntax. If my current DNS Server Domain was 'ns1.mydomain.tld' the initialization would change it to: 'ns1.ns1.mycluster.tld'.

Thus, the form asks for the cluster domain or subdomain to use, which is then appended to the used hostname. This combined creates the FQDN.

I am getting multiple feedback on this issue. So will be analyzing if the restriction for static IP can be relaxed without any issues.

Great news!

Once a node joins the cluster, it will use DANE-EE so if you have reverse proxy in between, the cert it returns will fail validation. Its done so that the cluster nodes directly communicate with each other without leaking the API token used by the cluster and also to prevent leaking DNSSEC private keys that get transferred to all the nodes.

Making it work with reverse proxy means that the nodes are no longer talking with each other directly and there is a scope of leaking the secrets.

Don't really see the point where all these information could be leaked using a Let's Encrypt based TLS connection with a trusted chain and LE CA.
I mean it's definitely more user friendly how you implemented it right now and the other way would expect more user configuration to work.
Nevertheless, tested it 'my way' and not receiving an error.

The nodes need to be reachable by each other which is a requirement so such a setup wont work. The network setup needs to allow access to all nodes.

Based on the feedback that I am getting, some of these things may change a bit so that the cluster setup works for most common scenarios.

Looking forward to the manual IP fix, because this would enable my nodes to sync correctly.
Keep up the good work!

[ShreyasZare]

I don't understand why you think my definition differs from the source. The FQDN includes a hostname, do we agree? Given this circumstance, if we use the FQDN initializing the cluster, we need to type in: 'ns1.mycluster.tld' to stick with your syntax. If my current DNS Server Domain was 'ns1.mydomain.tld' the initialization would change it to: 'ns1.ns1.mycluster.tld'.

Thus, the form asks for the cluster domain or subdomain to use, which is then appended to the used hostname. This combined creates the FQDN.

The FQDN really just means a full domain name and not a relative one. It does not say anything about hostnames. The first label in a domain name usually is considered as a hostname since its what resolves to a host. But this is not always true since you can have a domain name that does not resolve to any host and thus not have any hostname part.

I will update the tool tip in there so that this confusion can be avoided.

Don't really see the point where all these information could be leaked using a Let's Encrypt based TLS connection with a trusted chain and LE CA.

Its not an issue with the LE TLS cert itself. The issue is that the TLS encryption terminates at the reverse proxy and data may get transferred in clear text later. Ensuring that the TLS encryption terminates at the cluster node secures the data in transit.

[stratself]

Its not an issue with the LE TLS cert itself. The issue is that the TLS encryption terminates at the reverse proxy and data may get transferred in clear text later. Ensuring that the TLS encryption terminates at the cluster node secures the data in transit.

Hi, I just wanna ask: if the reverse proxy serves the same certificate as Technitium, then it could also pass DANE-EE verification right? And do the nodes look up each others' records via plain UDP/TCP on :53?

Many reverse proxies allow terminating TLS and then forward to a TLS-supporting backend, so I think this particular scenario could play well with Technitium. An admin would generate certs (usually via Let's Encrypt ACME), and mount it to both TDNS and something like Caddy.

[bboeckling]

The FQDN really just means a full domain name and not a relative one. It does not say anything about hostnames. The first label in a domain name usually is considered as a hostname since its what resolves to a host. But this is not always true since you can have a domain name that does not resolve to any host and thus not have any hostname part.

Well, i guess we're talking the same but still dont have the exact same interpretation of an fqdn. May a little explanation helps avoiding any misunderstandings.

Its not an issue with the LE TLS cert itself. The issue is that the TLS encryption terminates at the reverse proxy and data may get transferred in clear text later. Ensuring that the TLS encryption terminates at the cluster node secures the data in transit.

This is the common case for every reverse proxy connecting to an http backend, isn't it? Users must be aware of this when using reverse proxies. I don't know whether it's the task of technitium to address this.

What @stratself is suggesting is using the https port of technitium 53443/tcp instead of 5380/tcp with insecure_skip_verify in the reverse proxy. Then the reverse proxy connects to the https backend using the internal certificates, but not validating them.
From my understanding from the following answer this would also not work:

Once a node joins the cluster, it will use DANE-EE so if you have reverse proxy in between, the cert it returns will fail validation. Its done so that the cluster nodes directly communicate with each other without leaking the API token used by the cluster and also to prevent leaking DNSSEC private keys that get transferred to all the nodes.

Only workaround could be using a tcp-reverse proxy instead of http-reverse proxy.

[stratself]

@bboeckling: Sensitive applications have opted to only receive TLS traffic as a matter of increasing on-the-wire encryption. Another example of enforced TLS I know of is the auth provider kanidm who explained their rationale here. As clustering data are highly sensitive I'd understand Technitium's decision.

Furthermore besides insecure_skip_verify, many reverse proxies allow you to specify a server name to verify backend's certificate against. This includes serverName for Traefik, and tls_server_name for Caddy. So validation is in fact possible to that extent.

I'll wait for Shreya's knowledge on the DANE-EE part. I believe from his blogpost and the RFC, if the certs match, there should not be a problem. My rationale would be that if the certs are the same, both the reverse proxy and the Technitium are trusted as the same end entity.

[bboeckling]

@stratself: Don't get me wrong, I really appreciate the thought on securing all connections with TLS to avoid sensitive data from being transferred in clear text in any point of the connection. That's the reason I use Let's Encrypt certificates for every single application, I'm hosting for myself.

However, your example of kanidm doesn't match the discussion we're having about technitium. As in this issue explained, kanidm allows the proxy to terminate the tls connection and re-encrypt it for the connection to the backend. This allows the usage of reverse proxies with every certificate you desire and connect to the backend using a different certificate. We don't have to talk about the lack of backend authenticity validation if using sef-signed certificates in the backend connection.

Technitium in fact does not allow this, as the current implementation expects the whole TLS connection to be terminated at the cluster node, as being said here:

The issue is that the TLS encryption terminates at the reverse proxy and data may get transferred in clear text later. Ensuring that the TLS encryption terminates at the cluster node secures the data in transit.

To achieve this, technitium makes use of the http-stream tls connection, which is handled by the private and public key technitium knows to securely transfer data. If a node presents any other certificate, the validation will fail:

Once a node joins the cluster, it will use DANE-EE so if you have reverse proxy in between, the cert it returns will fail validation.

So it's pretty similar, but not exactly the same discussion.

Furthermore besides insecure_skip_verify, many reverse proxies allow you to specify a server name to verify backend's certificate against. This includes serverName for Traefik, and tls_server_name for Caddy. So validation is in fact possible to that extent.

This won't help with validating the authenticity of the server if self-signed certificates are being used, which is the case if you don't create your custom CA, public and private keys and configure technitium to use them.

I'll wait for Shreya's knowledge on the DANE-EE part. I believe from his blogpost and the RFC, if the certs match, there should not be a problem. My rationale would be that if the certs are the same, both the reverse proxy and the Technitium are trusted as the same end entity.

I understand your point, but it doesn't make sense if you look more closely.
Using the same pair of cryptographic keys both for the reverse proxy and technitium would result in a possible way to intercept the transmission if an attacker is in control of the reverse proxy. That would undermine Technitium's end-to-end encryption concept. Futhermore the reverse proxy then is not needed, because the tls connection can simply be terminated at the outer part of the connection, the cluster nodes.
You could still configure the reverse proxy to simply transfer the connection to the backend without terminating the tls stream, which is basically the concept of a tcp proxy.
Strictly speaking, Technitium should not allow any HTTP connections at all, not even in single node mode, because the administration access data is at least as sensitive, but that's a side thought.

The more I think about this, the more I get the feeling that using the tls encryption of the https stream is not the right way to achieve end-to-end encryption in the cluster sync. This can be mitigated by setting up a custom tls connection between the nodes by generating a cryptographic key pair for each node and use an encryption on the application layer.
I don't like the restrictions on certificates that come with the new cluster feature.

[ShreyasZare]

Its not an issue with the LE TLS cert itself. The issue is that the TLS encryption terminates at the reverse proxy and data may get transferred in clear text later. Ensuring that the TLS encryption terminates at the cluster node secures the data in transit.

Hi, I just wanna ask: if the reverse proxy serves the same certificate as Technitium, then it could also pass DANE-EE verification right? And do the nodes look up each others' records via plain UDP/TCP on :53?

Yes, in that case it will work since DANE-EE just matches the certificate with the hash it has.

Many reverse proxies allow terminating TLS and then forward to a TLS-supporting backend, so I think this particular scenario could play well with Technitium. An admin would generate certs (usually via Let's Encrypt ACME), and mount it to both TDNS and something like Caddy.

In that case, just having a TCP reverse proxy will be much better and wont require complex ops to maintain same certs in both places. Also it will provide node-to-node encryption.

[ShreyasZare]

Technitium DNS Server v14.1 is now available that resolves this issue. Do update and let me know your feedback.