Resolving GitHub Pages DNS and HTTPS Challenges: A GitHub Overview for Custom Domains

The Persistent Puzzle of GitHub Pages DNS Verification

Setting up a custom domain for your GitHub Pages site should be straightforward, but as many developers discover, DNS configuration can be a labyrinth of subtle errors. A common and frustrating issue is encountering an InvalidDNSError in GitHub Pages settings, coupled with stalled HTTPS certificate provisioning, even when public DNS checkers report everything is correct. This devactivity.com insight provides a practical github overview of how to diagnose and resolve these elusive problems, drawing from a recent community discussion.

The core of the problem, as highlighted by a user attempting to set up priyut-drakona.ru, is GitHub's internal verification process failing despite external validation. The user had correctly configured A records, a www CNAME, and a GitHub domain ownership TXT record, yet GitHub Pages reported an error and refused to provision an HTTPS certificate.

Common Culprits and Solutions for GitHub Pages DNS Issues

When GitHub Pages reports an InvalidDNSError, the solution often lies in scrutinizing DNS records beyond the obvious. Here are the key areas to investigate, particularly with registrars like REG.RU:

1. Hidden or Leftover DNS Records at the Apex

Public DNS checkers often focus on the records you've explicitly configured, but leftover or default records from your registrar (e.g., parking pages, old hosting) can interfere. GitHub Pages requires only its four specific A records for the apex domain (e.g., priyut-drakona.ru) and no AAAA records unless they are GitHub's own. Any additional A records or non-GitHub AAAA records will trigger an InvalidDNSError and prevent HTTPS.

To check for extraneous records, use dig:

dig priyut-drakona.ru A +short
dig priyut-drakona.ru AAAA +short
dig www.priyut-drakona.ru +short

Ensure that only the GitHub A records (185.199.108.153 through 185.199.111.153) are present for the apex, and ideally, no AAAA records unless they are GitHub's IPv6 addresses.

2. CAA Records Blocking Let's Encrypt

HTTPS certificates for GitHub Pages are provisioned by Let's Encrypt. If your domain has Certificate Authority Authorization (CAA) records, they must explicitly permit Let's Encrypt to issue certificates for your domain. If not, certificate provisioning will remain stuck.

Check your CAA records:

dig priyut-drakona.ru CAA +short

If CAA records exist, ensure you have one that includes 0 issue "letsencrypt.org". If you don't need CAA records, removing them entirely is also an option.

3. TXT Record Naming Pitfalls

Many DNS management panels automatically append the domain name to host entries. If you enter the full verification record name (e.g., _github-pages-challenge-salev27-art.priyut-drakona.ru) into a field that auto-appends, the actual record created might be something like _github-pages-challenge-salev27-art.priyut-drakona.ru.priyut-drakona.ru, making it invisible to GitHub's verification process.

When adding the TXT record, often you only need to input the subdomain part:

_github-pages-challenge-salev27-art

Verify the correct TXT record exists:

dig TXT _github-pages-challenge-salev27-art.priyut-drakona.ru +short

4. Forcing a Re-check and Re-verification

After making any DNS changes and waiting for the DNS record's Time To Live (TTL) to expire, GitHub Pages might still need a nudge. Go to your repository's Settings → Pages, remove the custom domain, save, and then add it back. This action often triggers a fresh DNS check and certificate request. Additionally, click the Verify button in your account settings (Settings → Pages → Verified domains) if applicable.

Conclusion

While GitHub Pages offers a fantastic way to host static sites, ensuring a smooth experience with custom domains requires meticulous attention to DNS details. By systematically checking for hidden records, correct CAA configurations, and proper TXT record naming, developers can overcome common InvalidDNSError and enable HTTPS. If these steps don't resolve the issue, it may indicate a deeper problem on GitHub's side, and referencing similar community discussions in a new support ticket can be beneficial.