InvalidDNSError on apex + www although DNS resolves correctly (figurancafepub.com)

[EfeErgezer]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Pages

Body

Hi,

My GitHub Pages site (efeergezer/figuran-cafe-pub-menu) shows:
"Both figurancafepub.com and its alternate name are improperly configured –
Domain's DNS record could not be retrieved (InvalidDNSError)",
so I can't enable "Enforce HTTPS".

DNS looks correct from public resolvers:

• NS (registry/whois): p3.hosting.com.tr, p4.hosting.com.tr
• figurancafepub.com A: 185.199.108.153, 185.199.109.153,
  185.199.110.153, 185.199.111.153 (answered by both nameservers)
• www.figurancafepub.com CNAME: efeergezer.github.io
• No AAAA, no CAA, no wildcard records
• CNAME file in repo root contains only "figurancafepub.com"
• The domain is not used by any other repo; my user site has no custom domain
• http://figurancafepub.com already serves the Pages site

Earlier today the domain's nameservers were misconfigured (REFUSED),
this was fixed around 15:30 (UTC+3). I removed and re-added the custom
domain after the fix, but the check still fails.

Could the old failed result be cached on GitHub's side? Is there anything
else I should check?

Thanks!

[sandeep-2607]

Your public DNS looks correct now. I checked through Google's public resolver (dns.google) and got:

• apex: the 4 GitHub A records, no AAAA, no CAA, no DS (so DNSSEC isn't involved)
• www: CNAME to efeergezer.github.io
• SOA negative-cache TTL of 300s, so a cached "REFUSED/not found" from this morning shouldn't last long in normal resolvers

Since the earlier problem was the nameservers returning REFUSED, I'd check each nameserver directly rather than through a public resolver. If even one of them still refuses some queries, GitHub's check can fail while public resolvers look fine:

for ns in p3.hosting.com.tr p4.hosting.com.tr; do
  echo "== $ns"
  dig @$ns figurancafepub.com A +norec +short
  dig @$ns www.figurancafepub.com CNAME +norec +short
  dig @$ns figurancafepub.com CAA +norec      # look at the "status:" line, it should be NOERROR
  dig @$ns figurancafepub.com A +norec +tcp +short
done

Every query should answer from both servers. That includes the CAA query (an empty NOERROR is fine) and the TCP query. If any of them shows REFUSED, SERVFAIL or a timeout, that's what your DNS host needs to fix.

If both servers answer cleanly:

1. In Settings → Pages, remove the custom domain, wait a few minutes, then add it back. The Pages docs say re-adding may be needed "to trigger the process of enabling HTTPS" after DNS changes: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/troubleshooting-custom-domains-and-github-pages#https-errors
2. Give it time. The same page says HTTPS can take up to an hour after the domain is configured. Your first re-add may have happened while the nameserver fix was still propagating.

If it still shows InvalidDNSError after the nameservers answer correctly and you've re-added once more, I'd send it to GitHub Support. At that point the DNS is right and the stale state is on their side.

[EfeErgezer]

Thanks a lot for the detailed reply, this was really helpful!

I ran the checks you suggested:

• p3.hosting.com.tr / p4.hosting.com.tr (current nameservers): both answer correctly over UDP and TCP — 4 GitHub A records for the apex, www CNAME to efeergezer.github.io, and the CAA query returns an empty NOERROR.
• ns1.hosting.com.tr / ns2.hosting.com.tr (the old nameservers before today's change): both still return status: REFUSED for figurancafepub.com.

Since the delegation changed from ns1/ns2 to p3/p4 only recently and .com NS records can be cached for up to 48 hours, my guess is that some resolvers (possibly the ones GitHub uses) are still asking the old servers and getting REFUSED.

I've asked my DNS host to also serve the zone on ns1/ns2 with the same records. Once that's in place (or the old delegation expires from caches), I'll remove and re-add the custom domain once and give it an hour.

I'll post an update here either way, and if it still fails after that, I'll take it to GitHub Support as you suggested.

Thanks again!

[sandeep-2607]

Nice debugging, that matches what I see:

• The .com registry (Verisign RDAP) already lists P3/P4.HOSTING.COM.TR for the domain, last changed 2026-10-28 07:59 UTC.
• The zone's own NS records on p3/p4 also point to p3/p4 (TTL 300), so once a resolver reaches the new servers it stays on them.

The NS records in the .com zone have a 2-day TTL (172800s). A resolver that cached the old ns1/ns2 delegation shortly before 07:59 UTC today could keep using it until about 07:59 UTC on Oct 30 at the latest. So you're right: having the host serve the same zone on ns1/ns2 is the fastest fix. If they can't, waiting until then and re-adding the domain once more should clear it.

You can see the registry's current delegation and its TTL with:

dig @a.gtld-servers.net figurancafepub.com NS +norec

(Check the TTL column in the AUTHORITY section.)

[EfeErgezer]

The problem was resolved as of this morning. Thank you for your ideas and for your help.

[sandeep-2607]

Glad it's working now! If the nameserver/TTL explanation was what solved it, marking that reply as the answer will help others who hit the same InvalidDNSError find it.