The sample results don't show the specific IP addresses probed when validating a host's TLS records.
But a multi-homed host (or logical name that maps to the IP addresses of multiple hosts) can at times present different certificate chains at different IP addresses. All the IP addresses should be checked and results reported separately for each IP address.
in other words, at the domain level for example, there'd be an overall status, then a separate JSON object for each host, and within each host's object a an overall status and a separate object for each IPv4 and IPv6 address.
The tests need to iterate over all the IP addresses.
The container configuration should also specify whether to check multiple server certificate types, RSA, ECDSA, ...
in which case the per IP address tests further split into per certificate algorithm tests.
The RSA and ECDSA cases each involve specifying an associated list of TLS-layer signature algorithm code points.
For other algorithms (as/when they become popular) the list may be just a single entry (ed25519, ed448, ML-DSA-65, ...).
Unfortunately, some of the observed DANE-survey failures are algorithm and/or IP-address specific, and testing just a single IP address, or a single certificate algorithm (perhaps whichever the server prefers by default when all are offered), is not sufficient.
One can go further and separately test support for multiple TLS protocol versions to make sure that DANE is working correctly for e.g. at least both TLS 1.2 and TLS 1.3 clients. MTA software upgrade cycles tends to lag those for browsers and the like, and it is not uncommon to see older TLS stacks in use by legitimate SMTP senders. So just testing TLS 1.3 may not be sufficient to ensure that all is well. Testing TLS 1.2 and TLS 1.3 separately might even be a sensible default, at this point all DANE-enabled servers SHOULD support both.
Absent an explicit set of expected certificate types to check, I'd separately check RSA and ECDSA, and handle errors as follows:
- If either RSA or ECDSA completes the handshake, but DANE certificate validation fails, that's a definite problem.
- If ECDSA fails to complete the handshake with something like:
$ danesmtp -s ecdsa dnssec-stats.ant.isi.edu
Connecting to 2001:1878:401::8009:1dfe
0073144EC17F0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:916:SSL alert number 40
$ danesmtp -s ecdsa sidn-nl.v-v1.mx.microsoft
Connecting to 52.101.68.29
00837D6B0C7F0000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:696:
then most likely no ECDSA certificate is deployed and all is well
- If on the other hand, RSA certificates similarly appear to not be deployed, then a warning may be appropriate, as there is perhaps still a non-trivial long-tail of senders that only support RSA. Though this should be a less common problem because e.g. ietf.org gets by with just ECDSA:
$ danesmtp -s rsa mail2.ietf.org
Connecting to 2602:f977:800:f7f6::1
00B37C93E97F0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:916:SSL alert number 40
$ danesmtp -s ecdsa mail2.ietf.org
Connecting to 2602:f977:800:f7f6::1
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=*.ietf.org
Hash used: SHA256
Signature type: ecdsa_secp256r1_sha256
Verification: OK
DANE TLSA 3 1 1 ...e86b88d9968abdf8656beb54 matched the EE certificate at depth 0
Peer Temp Key: X25519, 253 bits
250 CHUNKING
DONE
The sample results don't show the specific IP addresses probed when validating a host's TLS records.
But a multi-homed host (or logical name that maps to the IP addresses of multiple hosts) can at times present different certificate chains at different IP addresses. All the IP addresses should be checked and results reported separately for each IP address.
in other words, at the domain level for example, there'd be an overall status, then a separate JSON object for each host, and within each host's object a an overall status and a separate object for each IPv4 and IPv6 address.
The tests need to iterate over all the IP addresses.
The container configuration should also specify whether to check multiple server certificate types, RSA, ECDSA, ...
in which case the per IP address tests further split into per certificate algorithm tests.
The RSA and ECDSA cases each involve specifying an associated list of TLS-layer signature algorithm code points.
For other algorithms (as/when they become popular) the list may be just a single entry (ed25519, ed448, ML-DSA-65, ...).
Unfortunately, some of the observed DANE-survey failures are algorithm and/or IP-address specific, and testing just a single IP address, or a single certificate algorithm (perhaps whichever the server prefers by default when all are offered), is not sufficient.
One can go further and separately test support for multiple TLS protocol versions to make sure that DANE is working correctly for e.g. at least both TLS 1.2 and TLS 1.3 clients. MTA software upgrade cycles tends to lag those for browsers and the like, and it is not uncommon to see older TLS stacks in use by legitimate SMTP senders. So just testing TLS 1.3 may not be sufficient to ensure that all is well. Testing TLS 1.2 and TLS 1.3 separately might even be a sensible default, at this point all DANE-enabled servers SHOULD support both.
Absent an explicit set of expected certificate types to check, I'd separately check RSA and ECDSA, and handle errors as follows:
then most likely no ECDSA certificate is deployed and all is well