Question on how DANE-EE and PKI verification works for clustering

[stratself]

Disclaimer: I am not an expert so my understanding can be incomplete or wrong. This is just a technical question, not support, so not of very important priority.

---

I'm setting up clustering in my homelab (intranet only) with a cluster domain called example.dedyn.io. It has no public DNS records, but is DNSSEC-signed by my DDNS provider and has a valid Let's Encrypt cert for *.example.dedyn.io mounted into Technitium. As the cluster zone randomly-generates custom ZSK/KSK (I think), I believe this breaks DNSSEC. I see some interesting behavior with the Validate Certificate With PKI and DANE (Recommended) option:

• Using the primary node's IP address as the forwarder, I was not able to connect to the cluster (error msg: HttpClientNetworkHandler could not resolve DANE TLSA record for host: primary.example.dedyn.io). TLSA records were fetched, but I believe due to custom key signings it fails against upstream DNSSEC. This also produced an Attack detected! warning when querying from the secondary's DNS client.

• Using the default mode (recursive resolver) or a forwarder like Cloudflare, I was able to connect to the cluster. I believe because there is no publicly available DANE TLSA records (NxDomain), the DANE verification step fail-open and only verifies whether the primary node's cert is PKI-legitimate or not.

• Using the primary node's IP address as the forwarder and a subdomain of the above domain (e.g. primary.DNS.example.dedyn.io), I was able to connect to the cluster. I believe this means both TLSA and PKI were verified between nodes successfully, and no warnings were shown in the DNS client of the secondary.

Curious, I manually delete the TLSA record on the first node and retry the third way, and the connection also goes through. With these observations, I have the following questions:

• Is it true that the Validate Certificate With PKI and DANE (Recommended) option only needs one of DANE-EE or PKI verification to be successful? And that it accepts empty TLSA records?

• Could there be an option to require both checks to succeed and hard-fail otherwise? Would this make Technitium any more secure?

• Why does using a subdomain work with DANE in this case? I understand briefly that DNSSEC requires a chain of trust coming from all domain levels, so the auto-generated KSK should break that chain of trust, should it? I see no DS records for www.example.dedyn.io and primary.www.example.dedyn.io, which makes me confused as to how delegation of trust works in this case.

Thank you.

[stratself]

• Why does using a subdomain work with DANE in this case? I understand briefly that DNSSEC requires a chain of trust coming from all domain levels, so the auto-generated KSK should break that chain of trust, should it? I see no DS records for www.example.dedyn.io and primary.www.example.dedyn.io, which makes me confused as to how delegation of trust works in this case.

According to the blogpost

If the cluster primary zone is publicly resolvable and has a DS record at the parent zone then the joining process will use DANE-EE unless the Ignore Certificate Validation Errors option is selected.

So moving up one domain level understandably disables DANE-EE on initial joins, because that domain doesn't publicly exist outside of the homelab and hence have nothing in the parent DS records.

I'm not sure why the implementation is this way. Maybe this is to flexibly allow custom domains like cluster.invalid. I see why having a Let's Encrypt cert is still recommended, as it'd allow you to at least trust within the scope of Certificate Authorities. Anyhow, being made aware of the design now, I'll consider these questions answered

[ShreyasZare]

I'm not sure why the implementation is this way. Maybe this is to flexibly allow custom domains like cluster.invalid. I see why having a Let's Encrypt cert is still recommended, as it'd allow you to at least trust within the scope of Certificate Authorities. Anyhow, being made aware of the design now, I'll consider these questions answered

A valid cert is useful for joining nodes since it prevents any MiTM attacks during the joining process. Once a node joins, DANE-EE is always used and so the TLS certificate does not really matter anymore since DANE-EE binds to the certificate's public key to allow validating it. The domain name in the cert and even the expiry date does not matter when using DANE-EE.

[ShreyasZare]

The option you see in the Join Cluster dialog is used only for the joining process. Here the joining node will check for the TLS certificate validity and if your zone is DNSSEC signed then it will check and use DANE. For DANE to work, the domain has to be publicly resolvable and signed with DNSSEC such that the TLSA record can be validated as per the standard process. Once the node joins the cluster, it will always use DANE-EE when when the cluster zone is a private zone that does not resolve over Internet.

Is it true that the Validate Certificate With PKI and DANE (Recommended) option only needs one of DANE-EE or PKI verification to be successful? And that it accepts empty TLSA records?

If there is DANE configured for the domain name, the validation is done as per the DANE config. Otherwise the standard PKI validation is done.

Could there be an option to require both checks to succeed and hard-fail otherwise? Would this make Technitium any more secure?

The implementation works as per the DANE standard and its not possible to provide any option for user to decide how to proceed with the authentication of the server.

Why does using a subdomain work with DANE in this case? I understand briefly that DNSSEC requires a chain of trust coming from all domain levels, so the auto-generated KSK should break that chain of trust, should it? I see no DS records for www.example.dedyn.io and primary.www.example.dedyn.io, which makes me confused as to how delegation of trust works in this case.

Local zones that are DNSSEC signed are implicitly trusted by the DNS server which is why the DNSSEC validation works here.

[stratself]

Thanks for the response from the developer yourself. Now I understand that it works differently for private versus publicly resolvable zones. I'm interested in the joining procedure particularly, but it's nice to know the cluster works even after normal PKI expiries because it uses DANE TLSA verification.

[ShreyasZare]

You're welcome. Let me know if you have any more queries.