Resolving GitHub Pages HTTPS `InvalidDNSError` for Custom Domains: A Guide to Unblocking Development

The Persistent `InvalidDNSError` Challenge for GitHub Pages HTTPS

Setting up a custom domain with GitHub Pages is straightforward, but securing it with HTTPS can sometimes hit a roadblock: the dreaded InvalidDNSError. This community insight addresses a common scenario where a custom domain (e.g., dvs-servis75.ru) works over HTTP, yet HTTPS certificate provisioning remains stuck on this error despite seemingly correct DNS configurations. Such issues can significantly impact deployment workflows and, by extension, key software developer metrics related to site availability and security.

Initial DNS Verification & Common Pitfalls

Before advanced troubleshooting, confirm your DNS records align with GitHub Pages documentation. The original poster confirmed:

• Apex A Records: Four specific IP addresses for your root domain: 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153.
• WWW CNAME Record: A CNAME for www pointing to your GitHub Pages subdomain (e.g., sapfirrrr.github.io.).
• No Conflicting Records: Absence of AAAA (IPv6), ALIAS, ANAME, or other conflicting CNAME records.
• No Blocking CAA Records: Ensure no CAA records prevent Let's Encrypt from issuing certificates. If they exist, they must explicitly allow letsencrypt.org.

Even with these basics, InvalidDNSError often points to subtle issues. Community experts recommend these deeper checks:

Advanced DNS Troubleshooting Steps

Use dig commands to verify actual DNS resolution from various points, confirming registrar settings are propagating globally:

dig dvs-servis75.ru A +short
dig dvs-servis75.ru AAAA +short
dig www.dvs-servis75.ru CNAME +short

Also, check DNS propagation across all your nameservers (e.g., ns1.reg.ru, ns2.reg.ru) to ensure they return identical and correct records. Discrepancies can cause intermittent validation failures:

dig @ns1.reg.ru dvs-servis75.ru A +short
dig @ns2.reg.ru dvs-servis75.ru A +short

Further checks include:

• Hidden/Extra Records: Review your registrar's control panel (e.g., REG.RU) for old, forgotten, or automatically generated records like redirects, forwarding, or wildcard DNS (*.yourdomain.com).
• CNAME Trailing Dot: Ensure your www CNAME target is correctly formatted. Sometimes, registrars require a trailing dot (sapfirrrr.github.io.) or handle it automatically, leading to incorrect entries like sapfirrrr.github.io.dvs-servis75.ru.
• DNSSEC Configuration: A broken or improperly configured DNSSEC chain can impact certificate issuance. If not intentionally using DNSSEC, disabling it can be a troubleshooting step. If enabled, verify the DS record matches.

The "Delayed Hard Reset" Strategy

For persistent issues, perform a "delayed hard reset" of your custom domain settings on GitHub Pages:

1. Remove the custom domain entirely from your repository's Settings → Pages.
2. Save and wait at least 45 to 60 minutes to allow GitHub's backend caches to clear.
3. Add the custom domain (e.g., dvs-servis75.ru) back to your Pages settings and save.

Immediately re-adding the domain often fails due to cached error states.

When to Escalate to GitHub Support

If you've meticulously checked all DNS configurations, performed the delayed hard reset, and HTTPS provisioning remains stuck on InvalidDNSError for several days, it's time to contact GitHub Support. Community members cannot manually re-trigger certificate issuance. When submitting a ticket via support.github.com/contact (selecting "Pages"), provide:

• Your repository URL and custom domain.
• The exact InvalidDNSError status.
• Output from your dig commands.
• Explicitly request staff to check the Pages domain-validation and certificate state and, if necessary, manually clear the certificate state and trigger a re-issuance.

Efficiently resolving these technical blockers is crucial for maintaining smooth development workflows and positively impacting software developer metrics related to deployment reliability and secure content delivery.