This article explains how to check DNS delegation before requesting an UltraDNS-managed certificate for HTTPS Web Forwarding and how to investigate a failed request when the validation TXT record exists in UltraDNS.
Symptoms
- An HTTPS Web Forwarding certificate shows a failed issuance status.
- The audit history shows that an
_dnsauthTXT record was added, but the certificate was not issued. - The domain exists in UltraDNS, but public DNS queries return another provider's nameservers.
Why DNS Delegation Matters
Domain Control Validation (DCV) verifies control of a domain before certificate issuance. UltraDNS can create DNS validation records as part of managed certificate provisioning. However, a record's presence in the UltraDNS portal does not establish that public DNS returns it.
DNS delegation determines which nameservers public queries reach. If the validation hostname is served by another provider, a TXT record created only in UltraDNS is not available through that provider unless it is also published there. Creating a zone or changing its records in UltraDNS does not update the domain's delegation.
Visible to CertCentral allows a designated domain to be managed through the CertCentral connection. It does not change nameservers at the registrar or copy records to another DNS provider.
A delegation mismatch identifies a configuration problem to investigate. It does not, by itself, establish the cause of a previous certificate failure. Check the failure details and the DNS configuration applicable when validation was attempted.
Check DNS Before Requesting the Certificate
- Confirm which DNS provider is intended to serve the domain.
- If UltraDNS is intended, open the account details in the UltraDNS portal and locate Assigned Name Servers. Use the nameservers assigned to that account.
- Check the current delegation with
dig +trace example.com NS. Replaceexample.comwith your domain. Review the nameservers returned by the parent zone, not only the final answer. - Compare the delegation with the assigned nameservers. If the domain uses a separately delegated subdomain, also check the delegation for the zone containing the validation hostname.
- Confirm that Certificate Management and the managed certificate option are available for the account. Contact UltraDNS Support if the option is missing.
A standard lookup such as dig example.com NS shows the answer returned by your DNS resolver. Use the trace to investigate the delegation path when that answer does not match the intended configuration.
If the Domain Should Use UltraDNS
- Verify that the UltraDNS zone contains all DNS records required for the domain's services before changing delegation.
- Update the domain's nameservers at the registrar to the assigned UltraDNS nameservers. For a separately delegated subdomain, have the parent zone administrator update its delegation.
- Run the trace again to verify the updated delegation. Changing NS records inside the UltraDNS zone alone does not update the registrar's delegation.
- Allow existing DNS caches to update, and verify public resolution before submitting a new managed certificate request. Registrar processing and cached DNS data can affect when the change becomes visible.
If a certificate request has already failed, complete the checks below and contact Support to confirm the appropriate retry action.
If the Domain Must Remain with Another DNS Provider
Keep the intended delegation in place. Contact UltraDNS Support to confirm the supported HTTPS forwarding and certificate arrangement before changing DNS.
Do not assume that enabling Visible to CertCentral publishes validation records at the external provider.
Investigate a Failed Certificate Request
- Record the exact certificate error, affected hostname, and failure time, including the time zone.
- Open Audit and review the affected domain around the original request time. Include TXT, CAA, Web Forwarding, and certificate events. Do not limit the initial review to one user, because relevant entries can appear under different users.
- Confirm whether the audit contains an ADD event for the validation TXT record. An ADD event establishes that the record was created in UltraDNS; it does not prove that validation succeeded. Account login events alone do not establish successful domain validation.
- Obtain the current validation hostname and expected TXT value for the failed request. If these are unavailable, ask Support to confirm them.
- Query each nameserver serving that validation hostname. For example, run
dig @ns1.example.net _dnsauth.example.com TXT +norecurse, replacing both example names with the actual names. Compare each response with the current expected value. - Provide Support with the account name and ID, certificate error, audit export, and DNS output. Ask Support to confirm the recovery or retry procedure for that request.
Confirm the Resolution
During validation, the current required TXT value must be publicly discoverable through the DNS configuration serving the validation hostname. After provisioning completes, verify that the managed certificate shows Valid in Certificate Management and that the source HTTPS URL redirects to the intended destination without a certificate warning.
An automated validation record may be removed after validation. Its absence later does not establish that it was never created. Review the audit history and certificate status together.
Important Notes
- Use this article for certificates managed by UltraDNS for HTTPS Web Forwarding. CertCentral automatic domain revalidation is a separate troubleshooting task.
- Do not use Reset or Unlink as a certificate restart step. Reset suspends the CertCentral connection and generates a new secret. Unlink disconnects the integration and stops its automated domain management.
- Do not assume that deleting and recreating a web forward, or waiting for a scheduled domain revalidation cycle, will restart a failed certificate request. Confirm the retry procedure with Support.