IBM Cloud Internet Services ALIAS records with DNSSEC: certificate validation behavior
0 reputation · 16 Apr 2021, 19:22 UTC
0 reputation · 16 Apr 2021, 19:22 UTC
The goal is to clarify the documented interaction between IBM Cloud Internet Services DNS resolution and IBM Cloud Certificate Manager SSL/TLS certificate validation when a zone uses DNSSEC and contains ALIAS records that resolve to external domains.
CIS supports authoritative DNS with A, AAAA, CNAME, ALIAS and DNSSEC. Certificate Manager validates hostnames, chains and revocation status for imported or issued certificates. The product documentation does not clearly state whether DNSSEC validation is automatically adjusted or disabled for zones that contain ALIAS records pointing externally, and the described behavior is noted as varying by region. That uncertainty creates inconsistent expectations for certificate validation outcomes for external targets.
Does CIS automatically change DNSSEC validation handling for zones with ALIAS records that point to external domains? Is any adjustment applied consistently across regions? How should validation expectations be set for certificates when ALIAS resolution involves external endpoints?
34775 reputation · 16 Apr 2021, 23:21 UTC
No. IBM Cloud Internet Services (CIS) does not document an automatic DNSSEC adjustment for a zone simply because it contains ALIAS records that point to external domains. ALIAS flattening and DNSSEC signing are separate DNS functions, and Certificate Manager evaluates TLS material independently of the ALIAS target's DNSSEC status.
When CIS resolves an ALIAS record, it flattens the external target into address records at the CIS edge. The external target's zone and DNSSEC chain remain outside your CIS zone, so CIS cannot repair, bypass, or disable validation for that external chain. A validating resolver may still return SERVFAIL if the external zone is misconfigured or unsigned, but that is a DNS-layer failure, not a certificate-layer failure.
Certificate Manager validation is judged on the TLS material presented for the exact client-facing hostname. That includes SAN coverage, a complete chain to a trusted root, validity period, and revocation status. ALIAS flattening can hide the final CNAME target from clients, so hostname checks must use the original hostname, not the target hostname.
Regional or POP-specific DNS behavior is an operational detail and should not change the validation rule. Set expectations per hostname and per TLS endpoint. For external targets, assume DNSSEC is validated only where the external zone is signed and the client resolver validates DNSSEC; otherwise DNSSEC has no effect on Certificate Manager outcomes.
If behavior differs across regions, provide the precise validation error text and whether it occurs during DNS resolution or during TLS/certificate checks. That distinction determines whether the issue is a DNSSEC chain problem or a Certificate Manager hostname/chain/revocation problem.
Note: DNSSEC and ALIAS interactions are implementation-sensitive. Verify current IBM CIS behavior in your specific regions before relying on this guidance.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.