GitHub Pages InvalidDNSError on two domains despite valid DNS — HTTPS provisioning stuck

[vedima1983-commits]

🏷️ Discussion Type

Bug

Body

Hello GitHub Community,

I need help diagnosing a persistent GitHub Pages custom domain validation issue affecting two separate websites.

GitHub account: vedima1983-commits

Affected domains:

pitomnik-kbr.ru

nova-e.ru

Repository: http://github.com/vedima1983-commits/2124124 (pitomnik-kbr.ru)

Problem

Both domains report InvalidDNSError in GitHub Pages settings.

HTTPS certificate provisioning remains stuck at step 1 of 3, even though GitHub Pages deployments complete successfully.

DNS configuration

The following records have been checked:

A records for the apex domains:

185.199.108.153

185.199.109.153

185.199.110.153

185.199.111.153

www CNAME:

vedima1983-commits.github.io

Additional checks:

The GitHub Pages domain verification TXT record is publicly resolvable through Google DNS.

No restrictive CAA records were found.

No DS records were found.

The repository CNAME file contains the correct custom domain.

DNS provider REG.RU independently confirmed the DNS configuration.

Troubleshooting already performed

Verified the required GitHub Pages DNS records.

Checked DNS resolution using Google DNS.

Checked CAA and DS records.

Removed and re-added the custom domain in GitHub Pages settings.

Confirmed successful Pages deployment.

The problem persists.

GitHub Support

I created support tickets #4842894 and #4842901, but both were automatically closed with a recommendation to use community resources.

Questions

Why might GitHub Pages report InvalidDNSError when the DNS records appear correct?

Could there be an issue with account-level domain verification or HTTPS certificate provisioning?

What additional DNS checks would help identify the root cause?

Is there a way to bring a suspected GitHub Pages infrastructure issue to the attention of the engineering team?

Any technical assistance would be greatly appreciated.

Thank you!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[vedima1983-commits]

Hello GitHub Support Team,

I am requesting technical assistance and escalation to the GitHub Pages engineering team regarding an ongoing DNS verification and HTTPS certificate provisioning issue affecting two separate domains.

GitHub account: vedima1983-commits

Affected domains:

pitomnik-kbr.ru

nova-e.ru

Both websites are hosted on GitHub Pages in separate repositories under the same GitHub account.

Current issues:

GitHub Pages reports "DNS Check Failed" and "InvalidDNSError" for both domains.

The error states: "Unable to retrieve domain's DNS record."

HTTPS certificate provisioning remains stuck at step 1 of 3.

The "Enforce HTTPS" option is unavailable.

GitHub account-level domain verification also fails for pitomnik-kbr.ru, despite its verification TXT record being publicly resolvable.

Both websites are successfully built and deployed from their respective main branches.

DNS configuration:

Both domains use REG.RU authoritative nameservers:

ns1.reg.ru

ns2.reg.ru

Both domains have the four official GitHub Pages A records:

185.199.108.153

185.199.109.153

185.199.110.153

185.199.111.153

Both www subdomains have the correct CNAME target:

vedima1983-commits.github.io

DNS verification results:

We performed extensive DNS diagnostics.

Both authoritative REG.RU nameservers return valid SOA records for both domains.

Both nameservers return the correct www CNAME records.

SOA serial numbers match between the authoritative nameservers for each domain.

Google DNS-over-HTTPS successfully resolves the expected SOA, A, and CNAME records.

The GitHub domain verification TXT record for pitomnik-kbr.ru is publicly resolvable.

No restrictive CAA records or DS records were found during our checks.

REG.RU support independently confirmed the DNS configuration.

Additional network diagnostics:

We observed unusual behavior when testing traditional DNS queries from our Windows computer:

UDP DNS queries returned empty responses on our home connection.

UDP DNS queries timed out on a mobile connection.

TCP DNS queries on our home connection successfully returned the correct records.

DNS-over-HTTPS queries succeeded on both connections.

We understand that local DNS transport behavior does not necessarily explain GitHub's server-side DNS validation failure.

Requested investigation:

Could you please:

Escalate this case to a GitHub Pages engineer?

Investigate why GitHub Pages reports InvalidDNSError despite the publicly resolvable DNS records?

Check the internal custom-domain validation status for both domains?

Investigate why HTTPS certificate provisioning remains stuck at step 1 of 3?

Check whether the internal domain verification and TLS certificate provisioning states require a reset?

Provide the specific DNS query, record type, or validation failure preventing successful verification?

This issue affects two independently registered domains configured under the same GitHub account.

We would appreciate a technical investigation rather than general DNS configuration instructions, as the standard configuration has already been verified extensively.

Thank you for your assistance.

Best regards,
GitHub user: vedima1983-commits

[MalikAhed]

The unusual part of the evidence is the DNS transport itself: GitHub Pages validates from GitHub’s own resolvers, so public DoH success does not prove that the authoritative nameservers answer ordinary UDP/53 queries reliably. If UDP queries to both ns1.reg.ru and ns2.reg.ru time out or return empty while TCP/DoH works, an intermittent resolver or firewall path can produce InvalidDNSError even with correct records.

I would run the same authoritative checks from several external networks, querying each nameserver directly (not only a recursive resolver): dig @ns1.reg.ru pitomnik-kbr.ru SOA +time=5 +tries=2, the equivalent A, CNAME, and TXT queries, and repeat with +tcp and +dnssec. Compare the flags, NOERROR/SERVFAIL, response size, and SOA serial from both servers. Check that the apex has only the four Pages A records, www has only the expected CNAME, there is no conflicting wildcard/AAAA record, and any CAA record permits the certificate authority; then wait for the lower of the published TTLs after correcting anything.

Because two domains under one account fail together while deployments succeed, the strongest escalation evidence is a timestamped matrix showing direct UDP and TCP results for both authoritative servers plus the exact Pages error. Ask Support to inspect or reset the account’s custom-domain validation state using that matrix; repeated remove/re-add operations will not fix a validator that cannot reliably query the authoritative DNS. If this helps, please click Mark as answer.

[MalikAhed]

The unusual part of the evidence is the DNS transport itself: GitHub Pages validates from GitHub’s own resolvers, so public DoH success does not prove that the authoritative nameservers answer ordinary UDP/53 queries reliably. If UDP queries to both ns1.reg.ru and ns2.reg.ru time out or return empty while TCP/DoH works, an intermittent resolver or firewall path can produce InvalidDNSError even with correct records.

I would run the same authoritative checks from several external networks, querying each nameserver directly (not only a recursive resolver): dig @ns1.reg.ru pitomnik-kbr.ru SOA +time=5 +tries=2, the equivalent A, CNAME, and TXT queries, and repeat with +tcp and +dnssec. Compare the flags, NOERROR/SERVFAIL, response size, and SOA serial from both servers. Check that the apex has only the four Pages A records, www has only the expected CNAME, there is no conflicting wildcard/AAAA record, and any CAA record permits the certificate authority; then wait for the lower of the published TTLs after correcting anything.

Because two domains under one account fail together while deployments succeed, the strongest escalation evidence is a timestamped matrix showing direct UDP and TCP results for both authoritative servers plus the exact Pages error. Ask Support to inspect or reset the account’s custom-domain validation state using that matrix; repeated remove/re-add operations will not fix a validator that cannot reliably query the authoritative DNS. If this helps, please click Mark as answer.

[Sagargupta16]

The timestamped UDP/TCP matrix against both authoritative servers that MalikAhed suggests already exists, see below. Your records are correct, and the test that isolates the cause is one only you can run: gh api repos/vedima1983-commits/-/pages/health (owner token). On every reg.ru domain reported here since 2026-09-26 it returns caa_error: Dnsruby::ServFail or Dnsruby::ResolvTimeout with nameservers: default. That is GitHub's own resolver failing to get the CAA answer from ns1/ns2.reg.ru, which is why the UI says "Unable to retrieve domain's DNS record" while every public resolver, and REG.RU support, see the records fine.

From India just now I queried all 16 IPv4 addresses behind ns1.reg.ru and ns2.reg.ru for both domains: apex A, www CNAME, CAA, AAAA, DS, over UDP and TCP, plus 640 repeated CAA queries. 1019 of 1024 answered correctly (5 timeouts, 0 SERVFAIL). The four Pages A records, the empty CAA set and the www CNAME to vedima1983-commits.github.io are identical on every server. The challenge TXT for pitomnik-kbr.ru resolves on all 16 (ae279bf2...); nova-e.ru has no challenge TXT published, which is fine, account verification is optional. Both sites already serve Server: GitHub.com over HTTP with the *.github.io fallback certificate, and the Pages API shows https_certificate.state: new for both. One detail: repo 2124124 carries nova-e.ru, repo - carries pitomnik-kbr.ru.

Where this ends is measured, not guessed. Of the reg.ru Pages domains with your exact symptom in the last two weeks, every one that moved DNS hosting got its certificate within a day or two: heart-of-the-zone.ru (#208857), chistov.space (#209534), geo-upgrade.ru, b2china.ru (Yandex Cloud DNS), narrata.space, malinaklubnika.ru, dvs-servis75.ru. The one that stayed on reg.ru, app.ostepanovva.ru, still has the fallback cert. In #208857 GitHub Support told the author the configuration was correct and the issuance problem was on their side.

So: keep REG.RU as registrar, move only DNS hosting (Cloudflare free with grey-cloud DNS-only records, or Yandex Cloud DNS), copy the records exactly. Then remove and re-add each domain once, not repeatedly; every re-add restarts the certificate queue. The .ru NS delegation TTL is 4 days, so allow 1-2 days before judging. Watch the edge, not the UI:

openssl s_client -servername pitomnik-kbr.ru -connect pitomnik-kbr.ru:443 </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

When subject changes from CN=*.github.io to your domain, turn on Enforce HTTPS. If you want to stay on reg.ru, the Dnsruby::ServFail line from pages/health is the one piece of evidence support can act on.