GitHub Pages: HTTPS provisioning stuck on InvalidDNSError for custom domain dvs-servis75.ru

[sapfirrrr]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

My custom domain dvs-servis75.ru for GitHub Pages works over HTTP, but HTTPS certificate provisioning has been stuck on InvalidDNSError for several days.

Repository: https://github.com/sapfirrrr/dvs-chita/

I have verified all DNS requirements per GitHub documentation:

• 4 A records for apex @: 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153
• CNAME for www → sapfirrrr.github.io. (no repository name)
• No AAAA, ALIAS, ANAME, or conflicting CNAME records
• No CAA records blocking letsencrypt.org
• Nameservers: ns1.reg.ru, ns2.reg.ru
• Domain length: 14 characters

I have tried removing and re-adding the custom domain multiple times, but provisioning still fails. The site works fine over HTTP, only HTTPS fails.

This is a real technical bug, not product feedback. Could a GitHub staff member please manually re-trigger Let's Encrypt certificate issuance for this domain?

Thank you.

[aimanfazal]

InvalidDNSError usually means GitHub's HTTPS certificate check is still detecting a DNS configuration it cannot validate, even if the site works over HTTP.

Your apex A records are the standard GitHub Pages addresses:

• 185.199.108.153
• 185.199.109.153
• 185.199.110.153
• 185.199.111.153

The www CNAME should point to sapfirrrrr.github.io, which also looks correct for this setup.

I would verify the DNS from multiple resolvers, especially checking for unexpected AAAA, ALIAS, ANAME, or duplicate records:

dig dvs-servis75.ru A +short
dig dvs-servis75.ru AAAA +short
dig www.dvs-servis75.ru CNAME +short

Also check that there is no wildcard DNS record such as *.dvs-servis75.ru.

If those results are clean, try this once:

1. Remove the custom domain from Settings → Pages.
2. Save the change and wait a few minutes.
3. Add dvs-servis75.ru again.
4. Save and allow GitHub time to restart certificate provisioning.

GitHub normally requests the Let's Encrypt certificate automatically once its DNS check succeeds, so a staff member generally shouldn't need to manually issue the certificate.

If it remains on InvalidDNSError after the DNS is confirmed correct and re-provisioning has been triggered, this is appropriate to escalate to GitHub Support with the repository URL, domain, and the exact error status. They can check the Pages certificate-provisioning state on GitHub's side.

If this answer was helpful, please mark it as answered.

[kostis4563]

The InvalidDNSError status usually means GitHub is still detecting a DNS/configuration issue, even if the records look correct.

I’d check these things first:

1. Check the actual DNS resolution with dig:

   dig dvs-servis75.ru A
   dig www.dvs-servis75.ru CNAME

   Make sure the results exactly match the GitHub Pages records.

2. Check DNS propagation. Since the nameservers are ns1.reg.ru and ns2.reg.ru, verify that both nameservers return the same records.

3. Check for hidden/extra records in REG.RU. Look especially for old AAAA, CNAME, redirects, or forwarding records.

4. In GitHub, go to Repository → Settings → Pages, remove the custom domain, wait a few minutes, then add dvs-servis75.ru again.

5. Make sure Enforce HTTPS is enabled only after GitHub finishes provisioning the certificate.

If all of that is correct and it has been stuck for several days, it is likely something GitHub needs to investigate on their side. At that point, opening a GitHub Support ticket with the repository and domain information is the right next step.

[Jyotir2004]

Execute a delayed hard reset: Removing and immediately re-adding the custom domain often fails because GitHub's backend caches the previous error state. Remove the custom domain from your repository settings entirely, wait at least 45 to 60 minutes to ensure the cache clears, and then add it back.

Add an explicit CAA record: You noted that you do not have CAA records blocking Let's Encrypt. However, explicitly adding one can sometimes force the validation to succeed, especially with certain registrars like reg.ru that might have unique default behaviors. Add a CAA record for dvs-servis75.ru with the value 0 issue "letsencrypt.org".

Verify DNSSEC configuration: Check your reg.ru control panel to ensure DNSSEC is either fully disabled or perfectly configured. A broken DNSSEC chain will cause Let's Encrypt's DNS lookups to fail, resulting in a persistent InvalidDNSError on GitHub's end even if standard HTTP traffic resolves correctly.

Submit a specialized support ticket: To get a human GitHub staff member to manually intervene, you must submit a ticket through the GitHub Support portal. Go to support.github.com/contact/pages (or the general contact form if that direct link redirects) and select "Pages" as the category. Explicitly state that your DNS is fully propagated, you are stuck in an InvalidDNSError loop, and you need staff to manually clear the certificate state and trigger a re-issuance.

[Jyotir2004]

Execute a delayed hard reset: Removing and immediately re-adding the custom domain often fails because GitHub's backend caches the previous error state. Remove the custom domain from your repository settings entirely, wait at least 45 to 60 minutes to ensure the cache clears, and then add it back.

Add an explicit CAA record: You noted that you do not have CAA records blocking Let's Encrypt. However, explicitly adding one can sometimes force the validation to succeed, especially with certain registrars like reg.ru that might have unique default behaviors. Add a CAA record for dvs-servis75.ru with the value 0 issue "letsencrypt.org."

Verify DNSSEC configuration: Check your reg.ru control panel to ensure DNSSEC is either fully disabled or perfectly configured. A broken DNSSEC chain will cause Let's Encrypt's DNS lookups to fail, resulting in a persistent InvalidDNSError on GitHub's end even if standard HTTP traffic resolves correctly.

Submit a specialised support ticket: To get a human GitHub staff member to manually intervene, you must submit a ticket through the GitHub Support portal. Go to support.github.com/contact/pages (or the general contact form if that direct link redirects) and select "Pages" as the category. Explicitly state that your DNS is fully propagated, you are stuck in an InvalidDNSError loop, and you need staff to manually clear the certificate state and trigger a re-issuance.

[beenish-majeed]

Hi,

Community members can't manually re-trigger certificate issuance. If the DNS checks are clean and HTTPS is still stuck on InvalidDNSError, the next step is GitHub Support: https://support.github.com/contact

Before opening a ticket, I'd check these:

1. Check the www CNAME:

dig www.dvs-servis75.ru CNAME +short

It should return sapfirrrr.github.io.. If it returns something like sapfirrrr.github.io.dvs-servis75.ru., the CNAME is being published incorrectly. In the reg.ru panel, try entering the target without the trailing dot, then run the dig command again.

2. Check the apex records from both nameservers:

dig @ns1.reg.ru dvs-servis75.ru A +short
dig @ns2.reg.ru dvs-servis75.ru A +short

For the setup you've described, both should return the four GitHub Pages IPs: 185.199.108.153, 185.199.109.153, 185.199.110.153, and 185.199.111.153. If the two nameservers return different results, fix the DNS configuration at reg.ru first.

3. Check DNSSEC at reg.ru. If it's enabled, make sure the DS record at the registrar matches the DNSSEC configuration actually being served. A broken DNSSEC chain can cause DNS validation problems. If you're not intentionally using DNSSEC and aren't sure it's configured correctly, disabling it is a reasonable troubleshooting step.

4. Remove and re-add the custom domain once more after any DNS fix. This can restart the check, but since you've already tried it several times, I wouldn't keep repeating it.

I also wouldn't add a CAA record just to "force" validation. If you have no CAA records, there's nothing you need to add for Let's Encrypt. If CAA records do exist, make sure they allow letsencrypt.org.

HTTPS normally shouldn't stay stuck for several days, so if all of the checks above are clean, I'd open a Support ticket. Include the repo URL, dvs-servis75.ru, the InvalidDNSError status, and the dig output, and ask them to check the Pages domain-validation and certificate state on their side.