GitHub Pages certificate stuck in new for malinaklubnika.ru despite valid DNS

[jimbokl]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

What I expected

GitHub Pages should complete its DNS check, provision a valid TLS certificate for malinaklubnika.ru and www.malinaklubnika.ru, and allow Enforce HTTPS.

What happened

The repository is jimbokl/MALINA, published via a successful GitHub Actions Pages workflow. HTTP serves the site, but the Pages UI remains at DNS Check in Progress / 1 of 3 Certificate Requested. The Pages API has returned https_certificate.state: "new" since about 2026-09-28 17:10 UTC, with description This domain was recently added. The certificate request process will begin shortly. and https_enforced: false. Normal HTTPS requests to both apex and www fail hostname verification. The Pages API health endpoint returns {}.

The domain was removed and re-added once on September 27. I clicked Check again around 17:10 UTC on September 28; the UI now does not offer that button.

DNS checks (September 29)

• Both authoritative ns1.reg.ru and ns2.reg.ru return exactly the four documented GitHub Pages apex A records: 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153.
• www is a CNAME to jimbokl.github.io. No conflicting A/AAAA records were found.
• Apex CAA is a valid NOERROR response with no records, so it does not restrict issuance. There is no DS at the .ru parent, so no active DNSSEC chain. The CNAME target CAA permits letsencrypt.org.
• The publishing source is GitHub Actions (actions/upload-pages-artifact@v3, actions/deploy-pages@v4); the deployment succeeds. A repository CNAME file is not needed for this source.

I found other recent community discussions about Pages TLS provisioning, but none explains this domain-specific state. Can someone from GitHub help determine whether an internal DNS/certificate job is stuck, or identify a specific DNS or repository setting I should correct? Please re-trigger provisioning if appropriate. I can provide additional diagnostics.

[bosmdavid-gif]

From what you describe, your DNS setup looks right (four A records, www CNAME, no CAA, no DS, Actions source without a CNAME file is fine). One thing stands out: your nameservers are ns1/ns2.reg.ru, and #208881 (narrata.space, same nameservers) got the Pages health API to return caa_error: Dnsruby::ResolvTimeout / ServFail, while Google and Cloudflare resolved everything normally. An empty {} from the health endpoint is often just the async check still running. Call it again a few minutes later and see if you get the same caa_error:

gh api repos/jimbokl/MALINA/pages/health --jq '.domain, .alt_domain'

Also try dig @ns1.reg.ru malinaklubnika.ru CAA +tcp. If that hangs, it's the same issue.

If it is, the practical workaround is to leave reg.ru as registrar but host the DNS zone somewhere else (e.g. Cloudflare's free DNS, DNS-only records). Recreate the same records, change the nameservers at reg.ru, wait for dig NS to show them, then remove and re-add the custom domain once in Pages settings. Otherwise, a support ticket with the health output attached.

[jimbokl]

Thanks for the suggestion. We moved DNS hosting to Cloudflare today (30 September), keeping REG.RU only as the registrar.

Current observations at about 15:59–16:01 UTC:

• The zone is active, with nameservers dexter.ns.cloudflare.com and stella.ns.cloudflare.com. Google Public DNS and Cloudflare Public DNS both return the new nameservers.
• The four apex A records still point to 185.199.108.153 through 185.199.111.153; www is still a CNAME to jimbokl.github.io. Website records are DNS-only.
• Both public resolvers return NOERROR for apex CAA, with no CAA records and a Cloudflare SOA. Both also successfully resolve CAA for www through jimbokl.github.io, including 0 issue "letsencrypt.org".
• The Pages health endpoint nevertheless returns caa_error: Dnsruby::ServFail and InvalidDNSError for both apex and www. I cannot tell whether that result uses an older cached validation.
• Pages certificate state remains new; normal HTTPS still fails hostname verification for both names.

We used Check again after Cloudflare activation, and most recently at 13:46 UTC after public DNS returned the new nameservers. GitHub acknowledged: Certificate already exists for malinaklubnika.ru in state 'new'. Resuming the process. We have not removed/re-added the domain again after this DNS migration.

Is there another diagnostic that would show which resolver or cached delegation the Pages CAA check is using? The public CAA answers now succeed, but the Pages validation has not recovered yet.

[bosmdavid-gif]

The Cloudflare side looks right from here too. I see NS dexter/stella, the four 185.199.x.153 A records (not proxied), www → jimbokl.github.io, and apex CAA as NOERROR with the Cloudflare SOA via 8.8.8.8 and 1.1.1.1. HTTPS still presents the *.github.io cert.

As far as I know there's no public diagnostic that shows which resolver the Pages check uses. But two things are worth doing:

1. Let the old delegation expire. A resolver that cached the reg.ru NS before the switch will keep asking reg.ru until that TTL runs out, and that would explain the ServFail. You can see the parent TTL with dig +norec NS malinaklubnika.ru @a.dns.ripn.net (second column). Give it at least that long after the NS change.
2. Then remove and re-add the domain instead of "Check again". "Check again" only resumes the request that's been stuck in new since the 28th, as the "Resuming the process" message shows. In Settings → Pages, clear the custom domain, save, wait a minute or two, and add malinaklubnika.ru again. That starts a fresh certificate request against the new DNS. After the DNS check passes, it usually takes 15–60 minutes before Enforce HTTPS unlocks.

After that, re-run gh api repos/jimbokl/MALINA/pages/health. If it still shows caa_error: Dnsruby::ServFail after a fresh re-add, it's on GitHub's side, and a support ticket with that output plus your public dig results is the next step.

[jimbokl]

Update after a fresh custom-domain re-add today (30 September):

• At about 16:49 UTC we removed the custom domain through the Pages API. A subsequent GET confirmed both cname: null and https_certificate: null.
• After more than a minute, at about 16:51 UTC we restored malinaklubnika.ru. The API confirmed a new certificate request in state new, with the workflow publishing source preserved.
• The owner also used Check again at about 18:32 UTC after seeing DNS check unsuccessful.
• At 18:36 UTC the health endpoint returned HTTP 200 with the same result for both names: dns_resolves: false, is_valid: false, caa_error: Dnsruby::ServFail, and InvalidDNSError. It does not expose the internal validation timestamp, so I cannot rule out a cached result.

At the same time, a direct authoritative UDP CAA query to dexter.ns.cloudflare.com returned NOERROR, no CAA, and the Cloudflare SOA. Google Public DNS returned all four correct Pages A records, successful apex CAA, and no DS at the parent. Cloudflare Public DNS returned the new nameservers and successfully resolved www CAA through jimbokl.github.io, permitting letsencrypt.org. HTTP still serves the site; normal HTTPS still fails hostname validation.

We measured a current parent delegation TTL of 345600 seconds, so an old delegation cache remains possible. We are leaving the DNS records and domain binding stable now. Can a GitHub staff member help inspect the Pages CAA/provisioning failure, or suggest the appropriate escalation route when a technical support ticket is unavailable for a Free account?

[bosmdavid-gif]

Checked again this morning (1 Oct, ~08:20 UTC).

Public DNS still looks clean: NS are dexter.ns.cloudflare.com / stella.ns.cloudflare.com, apex has the four 185.199.x.153 A records, www → jimbokl.github.io, no CAA. HTTP returns 200 from GitHub. HTTPS still serves the *.github.io cert (CN=*.github.io, Let's Encrypt), so the custom cert has not issued.

The Pages API still shows https_certificate.state: "new" with the same "recently added" description — so the fresh re-add from yesterday did not move past the first step.

With a parent delegation TTL of 345600 seconds (~4 days), some of GitHub's resolvers may still be hitting the old reg.ru path until that cache expires. Leaving the Cloudflare records and domain binding alone (as you are doing) is right. There is nothing else on your side to fix until either:

1. That parent TTL ages out and a later health check stops returning ServFail, or
2. Staff clears the stuck request.

For Free accounts the practical path is still this Community thread plus https://support.github.com/contact — attach the health JSON, your dig of the Cloudflare NS/A/CAA, and the Pages API https_certificate object. Worth referencing #208857 and #209216 too; same InvalidDNSError / ServFail pattern on other .ru domains this week.