GitHub Pages custom domain validation fails with SERVFAIL / timeout despite successful external DNS checks

[HubbaBubbaPrepod]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Our GitHub Pages custom domain cannot complete DNS validation or obtain an HTTPS certificate.

• Repository: https://github.com/HubbaBubbaPrepod/pulse-website
• Custom domain: pulse.hubba-cloud.ru
• Publishing source: GitHub Actions
• Authoritative nameservers: nora.ns.cloudflare.com and rodrigo.ns.cloudflare.com
• DNS record: pulse.hubba-cloud.ru CNAME hubbabubbaprepod.github.io
• Cloudflare proxy: disabled — DNS only
  The Pages UI reports InvalidDNSError. The /pages/health API has returned both Dnsruby::ServFail and Dnsruby::ResolvTimeout under domain.caa_error. The certificate remains in state new.
  We have verified the following:

1. The custom domain is correctly configured in the repository’s Pages settings.
2. Both Cloudflare authoritative nameservers return NOERROR and the expected CNAME.
3. Public DNS resolvers return the expected GitHub Pages IPv4/IPv6 addresses.
4. CAA resolution through the CNAME chain permits letsencrypt.org.
5. No DS record is published for hubba-cloud.ru.
6. The latest deployment workflow completed successfully.
7. http://pulse.hubba-cloud.ru/ returns our website with HTTP 200.
8. https://hubbabubbaprepod.github.io/pulse-website/ redirects to the configured custom domain.
9. HTTPS on the custom domain fails certificate hostname validation.
   The issue originally occurred with REG.RU DNS and persists after migrating authoritative DNS to Cloudflare. We have not established which nameserver or resolver fails from GitHub’s validation infrastructure.
   One recent failing API response:
   Response Date: Sun, 18 Oct 2026 11:23:41 GMT
   HTTP status: 200
   domain.dns_resolves: false
   domain.caa_error: Dnsruby::ServFail
   The preceding request started the asynchronous check:
   Response Date: Sun, 18 Oct 2026 11:23:08 GMT
   HTTP status: 202
   X-GitHub-Request-Id: 8378:2F846F:154BC3B:218B68A:6AD4AC1C
   These are API response times, not confirmed timestamps of the internal DNS failure.
   Could you please inspect the Pages validation and certificate provisioning logs and identify:

• The actual DNS query name, type, destination nameserver and failure time.
• Whether resolution fails at our domain, along the CNAME chain, or within GitHub’s resolver infrastructure.
• Any remaining configuration issue we need to correct.
• Whether the existing certificate request needs intervention after DNS validation succeeds.
  We can provide raw DNS outputs and API response logs. Please note that the previously collected diagnostic archive predates the nameserver migration to Cloudflare.
  Thank you.

[kevinjosh10]

Hi @HubbaBubbaPrepod! Here is a technical breakdown of why you are seeing Dnsruby::ServFail / Dnsruby::ResolvTimeout under domain.caa_error and how to fix it:

---

Root Cause Analysis

1. How GitHub Pages & Let's Encrypt Perform CAA Validation (RFC 8659):
   When GitHub Pages validates a custom domain to issue an SSL certificate, its validation backend uses the Ruby DNS resolver library (Dnsruby). In accordance with RFC 8659 Section 3, the certificate authority MUST query CAA records along the entire domain tree:

   • pulse.hubba-cloud.ru
   • hubba-cloud.ru
   • .ru
   • AND following the CNAME alias target (hubbabubbaprepod.github.io → github.io).

2. Why Dnsruby::ServFail Occurs:

   • RFC 8659 dictates that if any nameserver along the chain returns SERVFAIL or times out, the CA must treat it as a hard failure and refuse certificate issuance.
   • For domains under the .ru TLD migrated to Cloudflare, the two most common causes of this error are:
     • Orphaned DNSSEC at Registrar (REG.RU): If DNSSEC was ever enabled under REG.RU before migrating nameservers to Cloudflare, the .ru parent zone may still hold old DS records. Because Cloudflare does not possess the matching private key, any DNSSEC-validating resolver (like Let's Encrypt / Dnsruby) returns SERVFAIL.
     • Empty CAA Responses & Resolver Egress: When no explicit CAA record is defined at the apex, resolvers query up to the root. If Cloudflare or the parent zone delays or drops UDP CAA queries from GitHub's validation subnets (AWS US-East), Dnsruby::ResolvTimeout is thrown.

---

Actionable Fixes

1. Add an Explicit CAA Record in Cloudflare DNS

Do not rely on implicit inheritance. Add an explicit CAA record at your apex domain in the Cloudflare dashboard:

• Type: CAA
• Name: @ (or hubba-cloud.ru)
• Tag: Only allow specific CAs to issue certs (issue)
• Value: letsencrypt.org
• TTL: Auto
  (Optional: add an issuewild tag set to letsencrypt.org or ;)

Having an explicit CAA record at the apex satisfies the CAA lookup immediately and prevents resolvers from walking further up the zone tree.

2. Check for Stale DNSSEC DS Records

1. Log into your REG.RU registrar dashboard.
2. Check the DNSSEC settings for hubba-cloud.ru.
3. If DNSSEC is enabled, either:
   • Disable DNSSEC completely at REG.RU (recommended until your certificate issues), or
   • Copy the exact DS record keys provided in Cloudflare's DNS → Settings → DNSSEC section into REG.RU.

3. Confirm Cloudflare Proxy is Disabled

Ensure the CNAME record for pulse.hubba-cloud.ru is set to DNS Only (Grey Cloud), not Proxied (Orange Cloud), so GitHub Pages can verify the certificate directly.

---

How to Force a Re-Check

Once the CAA record is saved:

1. In your GitHub repository, go to Settings → Pages.
2. Remove pulse.hubba-cloud.ru from the Custom Domain field and click Save.
3. Wait 2–3 minutes for the backend cache to flush.
4. Enter pulse.hubba-cloud.ru again and click Save.
   This resets the new certificate state and triggers a fresh validation handshake!