GitHub Pages DNS check fails with Dnsruby::ResolvTimeout #208881
🏷️ Discussion TypeBug BodyHello, I am experiencing a GitHub Pages custom domain DNS verification issue. Repository: Custom domain: GitHub Pages source: The Pages build is successful:
DNS has been independently verified using both Google Public DNS and Cloudflare DNS. For narrata.space, both resolvers return exactly the four GitHub Pages IP addresses: 185.199.108.153 For www.narrata.space: www.narrata.space → CNAME → dalniyx.github.io and dalniyx.github.io resolves to the same four GitHub Pages IP addresses. There are no AAAA records and no CAA records. Authoritative nameservers: ns1.reg.ru The CNAME file is present in the /docs publishing source and contains only: narrata.space I also removed and re-added the custom domain in GitHub Pages to restart the verification/provisioning process. However, GitHub's Pages health API repeatedly reports: dns_resolves: false The same result occurs for both narrata.space and www.narrata.space. I also triggered a fresh health check. The first request returned HTTP 202, and after the background check completed the subsequent request returned HTTP 200 with the same DNS error. The important part is that Google Public DNS and Cloudflare DNS both resolve the domain correctly, while GitHub's own Pages DNS health check cannot retrieve the DNS records. Could someone help determine why GitHub Pages' DNS checker is returning Dnsruby::ResolvTimeout for this domain? Thank you. Update: I performed additional independent DNS checks. Google Public DNS:
Cloudflare DNS:
However, GitHub Pages health still reports: narrata.space: www.narrata.space: The public DNS resolvers therefore return a normal negative CAA response, while GitHub's resolver reports SERVFAIL/timeout. Could this indicate a resolver compatibility issue between GitHub Pages' DNS checker (Dnsruby) and the authoritative DNS servers for the domain? |
Replies: 2 comments
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
|
Not a fix on GitHub's side, but a pattern and a workaround. At least three Pages threads this week have ns1/ns2.reg.ru as the authoritative nameservers and a check that times out or never leaves "new": this one, #209098 (malinaklubnika.ru) and #208719 (app.ostepanovva.ru). Public resolvers answering fine while Dnsruby gets ServFail/timeouts on CAA suggests GitHub's resolver can't reliably reach those nameservers. Your records, as you describe them, look fine. Things worth trying:
If you try 3, posting the result would help the other two threads too. |
Not a fix on GitHub's side, but a pattern and a workaround. At least three Pages threads this week have ns1/ns2.reg.ru as the authoritative nameservers and a check that times out or never leaves "new": this one, #209098 (malinaklubnika.ru) and #208719 (app.ostepanovva.ru). Public resolvers answering fine while Dnsruby gets ServFail/timeouts on CAA suggests GitHub's resolver can't reliably reach those nameservers. Your records, as you describe them, look fine.
Things worth trying:
dig @ns1.reg.ru narrata.space CAAand again with+tcp. A hang or SERVFAIL on either matches the error.