InvalidDNSError for chistov.space: DNS records are correct, REG.RU free plan

[Chistov-pro]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

What are you trying to do?

I am trying to set up a custom domain (chistov.space) for my GitHub Pages site.

What did you expect to happen?

I expect the domain to be verified and the site to be accessible under chistov.space. All DNS records are configured correctly.

What happened instead?

GitHub Pages shows an InvalidDNSError: "Domain's DNS record could not be retrieved".

Details & Configuration

• Registrar: REG.RU (free plan, no premium DNS, DNSSEC is NOT enabled).
• Name Servers: ns1.reg.ru, ns2.reg.ru.
• DNS Records: 4 A records pointing to GitHub IPs (screenshots attached).
• Propagation: Checked via DNSChecker.org — all records show green checkmarks globally.

I have already tried removing and re-adding the domain in the GitHub Pages settings, but the error persists. It seems the GitHub internal DNS checker cannot retrieve the records from REG.RU name servers, even though they are publicly visible.

Attachments

• Screenshot of A records in REG.RU panel.
• Screenshot of DNSChecker results.

Can someone from the Pages team force a re-scan or check if there are any known issues with reg.ru name servers?

[TheVingance]

Hi @Chistov-pro,

The reason you are encountering InvalidDNSError: "Domain's DNS record could not be retrieved" even though public tools like DNSChecker show green checkmarks is due to a known communication issue between GitHub Pages' internal validator and REG.RU's authoritative nameservers (ns1.reg.ru / ns2.reg.ru).

---

Why this happens

1. Direct Authoritative Queries: GitHub Pages does not only query standard recursive DNS (like Google 8.8.8.8 or Cloudflare 1.1.1.1). Its backend uses direct lookups to your authoritative nameservers to verify ownership and query CAA/A records.
2. Timeouts on REG.RU: REG.RU's nameservers frequently rate-limit, drop, or time out on UDP/EDNS queries originating from GitHub/Azure IP ranges, resulting in an internal Dnsruby::ResolvTimeout. When GitHub's verification job times out, it displays InvalidDNSError.

---

How to resolve this (Recommended Solution)

You do not need to transfer the domain or pay anything extra. The most reliable fix (which has resolved this exact issue for other users with REG.RU domains) is to delegate DNS management to Cloudflare (Free):

1. Create a free Cloudflare account:
   • Add chistov.space.
   • Choose the Free plan.
2. Configure your DNS records in Cloudflare:
   • Add the 4 GitHub Pages A records:
     • 185.199.108.153
     • 185.199.109.153
     • 185.199.110.153
     • 185.199.111.153
   • (Optional but recommended) Add a CNAME for www pointing to <your-username>.github.io.
   • ⚠️ Important: Set the Proxy status of all these records to DNS Only (gray cloud icon), not Proxied (orange cloud). GitHub needs to see its own IPs directly during the DNS check.
3. Change Name Servers in REG.RU:
   • Go to your domain management dashboard in REG.RU.
   • Replace ns1.reg.ru and ns2.reg.ru with the two nameservers assigned to you by Cloudflare.
4. Trigger a fresh check in GitHub Pages:
   • Wait ~15–30 minutes for the nameserver delegation to propagate.
   • Go to your repository Settings → Pages.
   • Clear the custom domain field and click Save.
   • Re-type chistov.space and click Save again.

GitHub will immediately query Cloudflare's Anycast DNS without timeouts, the DNS check will pass with a green checkmark, and your TLS/HTTPS certificate will be provisioned automatically.

If this helps clarify the situation and outlines the best path forward, please consider marking this reply as Answered so others facing similar relocation cases can find it easily.

[Chistov-pro]

Thank you, the issue is resolved!

First, following the second developer’s advice, I ran a diagnostic check and confirmed there are no DS records in the .space zone — DNSSEC is clean and there are no “garbage” records in the parent zone.

Then I followed the first developer’s recommendation and moved DNS management to Cloudflare. This fixed the timeout issues, and now the site is working over HTTPS.

Thank you all!