Problem
The check appears to conflate "insecure" with "unsigned" when determining the DNSSEC status of a domain.
As a result, some domains for which DNSSEC is configured at the delegation, but which are treated as insecure by validating resolvers because of a deprecated or unsupported algorithm, may be reported as having no DNSSEC at all.
Background
Over time, several DNSSEC algorithms have been deprecated or have become unsuitable for DNSSEC validation. The current recommendations are maintained in the IANA DNSSEC algorithm registries, as described by RFC 9904.
For example, DSA (algorithm 3) is currently marked MUST NOT for both DNSSEC signing and validation.
This can result in an interesting edge case.
Consider a domain that was originally signed using an obsolete algorithm, such as DSA, and for which a corresponding DS record was added to the parent zone. At some later point, the zone is re-signed using a modern algorithm, such as ECDSA P-256 (algorithm 13), but the DS record in the parent zone is not updated.
A modern validating resolver cannot use the obsolete algorithm to establish a chain of trust. The delegation is therefore treated as insecure, rather than bogus.
Consequently:
- the domain continues to resolve normally;
- no
SERVFAIL is returned;
- the
AD (Authenticated Data) bit is not set;
- DNSSEC does not provide authentication for the domain.
This behaviour is intentional: when no acceptable DS record is available, validating resolvers treat the delegation as insecure.
Example
An example can be seen here:
zeven-sprong.nl – DNSViz
The domain appears to have originally been signed using algorithm 3 (DSA), with a corresponding DS record in the parent zone. The zone was subsequently signed using algorithm 13 (ECDSA P-256), while the old DS record remained in place.
Because algorithm 3 is no longer supported for DNSSEC validation, validating resolvers treat the delegation as insecure.
Why this matters
From the point of view of the domain holder, this is an important distinction.
The domain is not simply unsigned (as internet.nl suggests): there is a DS record in the parent zone and DNSSEC has been configured. However, the configuration is ineffective because the chain of trust cannot be established using a currently supported algorithm.
Expected behaviour
The DNSSEC detection logic should distinguish between at least:
- Unsigned — no DS record exists in the parent zone.
- Secure — a valid chain of trust can be established.
- Insecure due to DNSSEC configuration - DNSSEC-related delegation data exists, but the delegation cannot be validated because, for example, the DS record uses a deprecated or unsupported algorithm.
In particular, the presence of a DS record should not automatically be interpreted as proof that DNSSEC is successfully deployed, but neither should an insecure delegation be reported simply as "unsigned".
Question
Could the DNSSEC detection logic be extended to distinguish an actually unsigned domain from a domain that has DNSSEC configured at the delegation but is treated as insecure because its DNSSEC configuration cannot be validated using currently supported algorithms?
Problem
The check appears to conflate "insecure" with "unsigned" when determining the DNSSEC status of a domain.
As a result, some domains for which DNSSEC is configured at the delegation, but which are treated as insecure by validating resolvers because of a deprecated or unsupported algorithm, may be reported as having no DNSSEC at all.
Background
Over time, several DNSSEC algorithms have been deprecated or have become unsuitable for DNSSEC validation. The current recommendations are maintained in the IANA DNSSEC algorithm registries, as described by RFC 9904.
For example, DSA (algorithm 3) is currently marked
MUST NOTfor both DNSSEC signing and validation.This can result in an interesting edge case.
Consider a domain that was originally signed using an obsolete algorithm, such as DSA, and for which a corresponding DS record was added to the parent zone. At some later point, the zone is re-signed using a modern algorithm, such as ECDSA P-256 (algorithm 13), but the DS record in the parent zone is not updated.
A modern validating resolver cannot use the obsolete algorithm to establish a chain of trust. The delegation is therefore treated as insecure, rather than bogus.
Consequently:
SERVFAILis returned;AD(Authenticated Data) bit is not set;This behaviour is intentional: when no acceptable DS record is available, validating resolvers treat the delegation as insecure.
Example
An example can be seen here:
zeven-sprong.nl – DNSViz
The domain appears to have originally been signed using algorithm 3 (DSA), with a corresponding DS record in the parent zone. The zone was subsequently signed using algorithm 13 (ECDSA P-256), while the old DS record remained in place.
Because algorithm 3 is no longer supported for DNSSEC validation, validating resolvers treat the delegation as insecure.
Why this matters
From the point of view of the domain holder, this is an important distinction.
The domain is not simply unsigned (as internet.nl suggests): there is a DS record in the parent zone and DNSSEC has been configured. However, the configuration is ineffective because the chain of trust cannot be established using a currently supported algorithm.
Expected behaviour
The DNSSEC detection logic should distinguish between at least:
In particular, the presence of a DS record should not automatically be interpreted as proof that DNSSEC is successfully deployed, but neither should an insecure delegation be reported simply as "unsigned".
Question
Could the DNSSEC detection logic be extended to distinguish an actually unsigned domain from a domain that has DNSSEC configured at the delegation but is treated as insecure because its DNSSEC configuration cannot be validated using currently supported algorithms?