GitHub Pages DNS health check fails with SERVFAIL / ResolvTimeout despite valid DNS — HTTPS certificate stuck

[8myy4p2fgm-ux]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Hi everyone,

I'm having an issue with HTTPS certificate provisioning for my GitHub Pages custom domain, tuz19.ru.

Repository: https://github.com/8myy4p2fgm-ux/ib19
Custom domain: tuz19.ru
Hosting: GitHub Pages, deployed via GitHub Actions
DNS provider: REG.RU

Expected behavior

GitHub Pages should validate the custom domain, issue a TLS certificate, and allow me to enable Enforce HTTPS.

Actual behavior

The certificate provisioning process has been stuck for approximately three days.

GitHub Pages Settings shows:

• DNS Check: In Progress
• TLS certificate: 1 of 3 — Certificate Requested
• Enforce HTTPS: unavailable

Both https://tuz19.ru and https://www.tuz19.ru fail certificate verification because GitHub serves a certificate for *.github.io.

GitHub Pages Health API results

I ran the authenticated endpoint:

GET /repos/8myy4p2fgm-ux/ib19/pages/health

For tuz19.ru:

• dns_resolves: false
• is_pointed_to_github_pages_ip: false
• is_https_eligible: false
• reason: InvalidDNSError
• caa_error: Dnsruby::ServFail

For www.tuz19.ru:

• dns_resolves: false
• is_https_eligible: false
• reason: InvalidDNSError
• caa_error: Dnsruby::ResolvTimeout

DNS diagnostics

Independent DNS checks show:

• The apex domain has the four recommended GitHub Pages A records (185.199.108.153 through 185.199.111.153).
• www.tuz19.ru has a CNAME pointing to 8myy4p2fgm-ux.github.io.
• All 16 tested IPv4 addresses of the authoritative REG.RU nameservers returned valid DNS responses.
• UDP and TCP queries for A, AAAA, CNAME, CAA and SOA returned expected results.
• Google DNS (8.8.8.8) and Cloudflare DNS (1.1.1.1) returned consistent results.
• No restrictive CAA records or DNSSEC delegation issues were identified.

However, GitHub's own DNS health checker reports SERVFAIL and timeout errors.

Question

What could cause GitHub Pages DNS validation to fail when the authoritative nameservers and public resolvers return correct results?

Is there a way to retry DNS validation or TLS certificate provisioning without removing and re-adding the custom domain?

I'd appreciate any suggestions. Thank you!

[DYNOSuprovo]

The error keys in your health output — caa_error: Dnsruby::ServFail and caa_error: Dnsruby::ResolvTimeout — pinpoint the exact failure.

GitHub Pages uses the Ruby gem dnsruby to pre-flight validate Certification Authority Authorization (CAA, RFC 8659) before ordering a certificate from Let's Encrypt. Here is what is causing this and how to resolve it:

---

Why this happens with REG.RU nameservers

1. How CAA validation works:
   When a certificate authority (or GitHub's pre-flight validator) checks your domain, the authoritative nameservers (ns1.reg.ru and ns2.reg.ru) must respond to TYPE257 (CAA) queries with either:

   • A valid CAA record authorizing letsencrypt.org, OR
   • A standard NOERROR negative response (empty Answer section with the zone SOA in the Authority section).

2. The REG.RU nameserver quirk:
   When no explicit CAA record exists, querying ns1.reg.ru / ns2.reg.ru for CAA records over IPv6 / UDP returns an anomalous response (echoing A records without proper NODATA / SOA framing). GitHub's dnsruby validator interprets this unexpected response format as ServFail or times out waiting for compliant EDNS packet exchange. Because RFC 8659 strictly prohibits issuing certificates if a CAA check returns SERVFAIL or TIMEOUT, GitHub halts TLS provisioning at step 1 of 3.

---

Step 1: Add Explicit CAA Records in REG.RU

Giving the nameserver an explicit CAA record to return forces REG.RU to return a clean, RFC-compliant NOERROR answer instead of a synthesized negative response:

Log in to the REG.RU DNS Zone Editor for tuz19.ru and add the following two CAA records:

Subdomain	Record Type	Value
@	CAA	0 issue "letsencrypt.org"
@	CAA	0 issuewild "letsencrypt.org"

(If your provider uses split fields: Flag = 0, Tag = issue, Value = letsencrypt.org)

---

Step 2: Trigger GitHub Pages to Retry Without Removing the Domain

You do not need to delete and re-add your custom domain. Once the CAA records are added and propagated (5–15 minutes), trigger GitHub's background validator by re-saving the domain:

1. Via GitHub CLI / REST API:

   gh api -X PUT /repos/8myy4p2fgm-ux/ib19/pages -f cname="tuz19.ru"

2. Or via the Web UI:
   • In your repository, go to Settings $\to$ Pages.
   • Under Custom domain, temporarily click Save again, or clear the text box, click Save, re-enter tuz19.ru, and click Save.

This immediately schedules a fresh health check run on GitHub's background worker.

---

Step 3: Verification

Re-run your health check:

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.github.com/repos/8myy4p2fgm-ux/ib19/pages/health

Once caa_error clears from ServFail to null, is_https_eligible will transition to true, and GitHub Pages will complete steps 2 and 3 (ordering and binding the Let's Encrypt certificate) within 15–30 minutes.

(Note: If REG.RU nameservers continue dropping packets from GitHub's US datacenter IPs, switching DNS delegation to Cloudflare with DNS-only / grey-cloud mode will instantly resolve all Dnsruby timeouts).

---

If this resolves your certificate provisioning issue, please feel free to mark this as the accepted answer!