GitHub Pages custom domain stuck on "DNS Check in Progress" for ~36 hours — DNS health check cannot resolve valid DNS

[Sof-oss]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Hello,

I'm having an issue with a GitHub Pages custom domain that has been stuck on "DNS Check in Progress" for about 36 hours.

Repository: Sof-oss/helper
Custom domain: heart-of-the-zone.ru
Current site URL over HTTP: http://heart-of-the-zone.ru/

The Pages deployment itself is working and the site is accessible over HTTP.

DNS configuration

The domain uses REG.RU authoritative nameservers:

• ns1.reg.ru
• ns2.reg.ru

The apex domain returns exactly the four GitHub Pages A records:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

I checked the records using:

• the local resolver
• Google DNS
• Cloudflare DNS
• ns1.reg.ru
• ns2.reg.ru

The authoritative servers consistently return the same four GitHub Pages IP addresses.

There are no additional A records or AAAA records for the apex domain.

I also checked for a wildcard record using a random subdomain; no wildcard response was returned.

GitHub Pages health check

The GitHub Pages health endpoint reports:

"dns_resolves": false,
"is_valid_domain": true,
"is_apex_domain": true,
"should_be_a_record": true,
"is_pointed_to_github_pages_ip": false,
"is_valid": false,
"reason": "Domain's DNS record could not be retrieved. ... (InvalidDNSError)",
"responds_to_https": false,
"enforces_https": false,
"https_error": "peer_failed_verification",
"is_https_eligible": false,
"caa_error": "Dnsruby::ResolvTimeout"

This is confusing because the DNS records are publicly resolvable, and both authoritative REG.RU nameservers consistently return the correct GitHub Pages A records.

The Dnsruby::ResolvTimeout result is particularly interesting because normal DNS queries to the authoritative servers complete successfully.

HTTPS

HTTP works and returns 200 OK.

A normal HTTPS request fails certificate verification with:

SEC_E_WRONG_PRINCIPAL

Using curl -k (which disables certificate verification), HTTPS returns 200 OK.

This appears consistent with the custom domain not yet having a valid GitHub Pages certificate provisioned.

What I have already tried

1. Verified the four required GitHub Pages A records.
2. Checked the records using multiple public DNS resolvers.
3. Queried both REG.RU authoritative nameservers directly.
4. Checked for unexpected AAAA/CNAME records.
5. Checked for a wildcard DNS record.
6. Removed the custom domain from GitHub Pages, waited about 20 minutes, and added heart-of-the-zone.ru again.

The DNS configuration itself has not changed.

Questions

Could someone help determine why GitHub's Pages DNS health check cannot retrieve the DNS records even though both authoritative REG.RU nameservers consistently return the correct GitHub Pages A records?

In particular:

1. Does Dnsruby::ResolvTimeout indicate a problem with GitHub's DNS resolver reaching REG.RU, rather than an incorrect DNS configuration on my side?
2. Can REG.RU's authoritative DNS configuration cause GitHub's DNS checker to time out even when normal public DNS resolvers can resolve the domain?
3. Is there anything specific I should check on the REG.RU side, such as CAA or DNSSEC-related configuration?
4. Is there a way to manually restart or trigger the GitHub Pages DNS verification/certificate provisioning process without removing and re-adding the custom domain again?
5. Given that the issue has persisted for ~36 hours and GitHub's own health check reports Dnsruby::ResolvTimeout, is there anything that needs to be done on the GitHub Pages side?

Any help identifying what GitHub's DNS checker is actually timing out on would be appreciated.

Thanks!

[TeWei02]

Your apex A records are correct, and the health-check output already names the layer that is failing: caa_error: "Dnsruby::ResolvTimeout" together with is_pointed_to_github_pages_ip:false. A ResolvTimeout is not "no records" -- the resolver never received a usable answer. is_valid_domain and is_apex_domain are both true, so the name parses fine and the query dies on the wire.

The usual causes, in the order worth checking:

1. DNSSEC. A partial or broken chain makes validating resolvers time out instead of returning SERVFAIL, and GitHub's Pages checker validates. From a machine with dig:

dig DS heart-of-the-zone.ru @8.8.8.8
dig DNSKEY heart-of-the-zone.ru @ns1.reg.ru
dig +dnssec A heart-of-the-zone.ru @8.8.8.8

If dig DS returns a DS record but the DNSKEY lookup fails or the algorithms do not line up, disable DNSSEC at REG.RU. Plain A queries still succeed during a partial DNSSEC failure, which is exactly the asymmetry you are describing.

2. EDNS and buffer handling on the authoritative side. dnsruby sends larger queries than a default stub resolver; some edge nodes silently drop those while answering small ones:

dig +bufsize=512 +noedns A heart-of-the-zone.ru @ns1.reg.ru
dig +bufsize=4096 A heart-of-the-zone.ru @ns1.reg.ru

If the second hangs and the first returns instantly, that is the failure mode, and it is worth a ticket with REG.RU rather than a change on your side.

3. CAA. caa_error is populated as well, so check for a malformed or restrictive CAA record:

dig CAA heart-of-the-zone.ru @8.8.8.8

Pages needs 0 issue "letsencrypt.org" and 0 issue "digicert.com", or no CAA record at all. A CAA record with a syntax error causes a timeout on some resolvers rather than a clean refusal.

After any change, the health check is cached. Remove the custom domain under Settings -> Pages, save, then re-add it and save again to force a fresh check instead of waiting the cache out. Propagation alone will not re-trigger it.

To verify from a resolver that is independent of your ISP:

curl -s "https://dns.google/resolve?name=heart-of-the-zone.ru&type=A" | head -c 300

If clearing DNSSEC or fixing the CAA record unblocks the check, marking this as the answer will save the next person hitting the same Dnsruby::ResolvTimeout the same 36 hours.

[Sof-oss]

All possible checks showed no problems with the configuration. A support ticket was submitted to technical support, which confirmed that everything was configured correctly and also confirmed that there was an issue with certificate issuance. They promised to look into it and keep me updated. Meanwhile, the "DNS Check in Progress" message has been there for more than 6 days.
I see that similar issues have been occurring quite frequently over the last few days, so I will keep updating this thread. Perhaps the solution to my problem (when it is finally resolved) will help someone else as well

[bosmdavid-gif]

I re-checked heart-of-the-zone.ru this morning (~08:20 UTC).

Public resolvers still return the four GitHub Pages A records and HTTP serves Server: GitHub.com with 200. The Pages API still has https_certificate.state: "new".

What stands out from here: a direct CAA query to the authoritative nameserver times out:

dig @ns1.reg.ru heart-of-the-zone.ru CAA +tcp
# → communications error … timed out (repeated)

That matches the caa_error: Dnsruby::ResolvTimeout in your health output. A records can look fine on Google/Cloudflare while GitHub's checker fails on the CAA lookup against reg.ru.

You already have a support ticket, which is the right call. While that is open, the workaround that got another .ru Pages domain (#209098) past the same reg.ru CAA timeout this week was: leave REG.RU as registrar, move DNS hosting to Cloudflare (free, records DNS-only — not proxied), recreate the four A records + www CNAME, wait until dig NS shows the Cloudflare nameservers, then remove and re-add the custom domain once. It did not instantly issue the cert for them either (parent TTL can still cache the old NS), but it cleared the "unresolvable from GitHub" side.

Happy to dig again if you try that path.

[Sof-oss]

I followed your advice and moved DNS to Cloudflare. This was 18 hours ago. So far no changes — the certificate issue persists.

Current state:

NS: bryce.ns.cloudflare.com, mimi.ns.cloudflare.com (confirmed via Google DNS)

A records (apex): the four GitHub Pages IPs

CNAME (www): sof-oss.github.io

HTTP: 200 OK

HTTPS: still fails certificate verification — GitHub serves the fallback CN=*.github.io certificate

/pages API: https_certificate.state: "new" — unchanged

The DNS layer is now fully correct and verified from multiple public resolvers, but the certificate provisioning workflow on GitHub's side still appears to be stuck. I'll keep this thread updated.

[Sof-oss]

Upd: I don't know whether your advice helped in the end or whether tech support processed the request, but this is the situation now. Either way, thank you!