DNS check unsuccessful, yet the domain resolves to github pages

[tjex]

Select Topic Area

Question

Body

Another person here struggling with DNS issues.

Here you can see the error.

It's complaining that the domain does not resolve to Github pages server, but it actually does.

output of dig.
i.e. Looking exactly as they should...

; <<>> DiG 9.10.6 <<>> tjex.net +nostats +nocomments +nocmd
;; global options: +cmd
;tjex.net.                      IN      A
tjex.net.               1383    IN      A       185.199.108.153
tjex.net.               1383    IN      A       185.199.111.153
tjex.net.               1383    IN      A       185.199.110.153
tjex.net.               1383    IN      A       185.199.109.153

; <<>> DiG 9.10.6 <<>> www.tjex.net +nostats +nocomments +nocmd
;; global options: +cmd
;www.tjex.net.                  IN      A
www.tjex.net.           1062    IN      CNAME   tjex.github.io.
tjex.github.io.         1062    IN      A       185.199.111.153
tjex.github.io.         1062    IN      A       185.199.108.153
tjex.github.io.         1062    IN      A       185.199.110.153
tjex.github.io.         1062    IN      A       185.199.109.153

What's even stranger is that I tried for the hell of it to set the custom domain to the www subdomain, which gave me the same DNS error, but actually generated a certificate and resolved to the live version of my website...

Makes no sense. Particularly considering these are my DNS records:

Would be really great if someone from Github could chime in. Seen many occurrences of a staff member tinkering somewhere in the backend of Github pages and resolving this very quickly... Would be ace.

Otherwise, I'm in a bind. Spoke to my DNS providers and on their end, everything looks fine.

it's been over 24 hours since any DNS changes.

[tjex]

The page is served now, but without certificate. Still getting "DNS check unsuccessful", which is leading to no certificate being issued.

[peterroth]

Just to be sure, did you add a DNS TXT record on your domain hosting service? That validates that the hostname is yours, this is what the custom domain section checks. You can read about it on the Verifying a domain for your user site page.

[tjex]

Thanks for the input Peter.

I'd seen this step, but considered it to be from outdated documentation, as
a) this button doesn't even exist in Github pages settings.
b) because the section in the sidebar is no longer titled "Code, automation and planning" (as referenced on the docs page), but just "Code and automation".

[peterroth]

Configuring a subdomain

[tjex]

ah I see. however further down the page, there is a section for setting up an apex domain and a www subdomain, which requires the A records and CNAME record (pointing www to the github.io page).

https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site#configuring-an-apex-domain-and-the-www-subdomain-variant

Or have I misunderstood something?..

[tjex]

or maybe you're meaning that I'm missing the CNAME altogether? In which case it's shown at the bottom of my DNS settings (screenshot in the original post)

[peterroth]

I just checked your page's source (tjex.net repository) and currently there is no CNAME file.
Plus, on the picture where you detail what DNS records you have at your DNS provider's page the CNAME points to tjex.github.io, however that doesn't exist, the repository you created is tjex.net, it surely leads to problems.

[tjex]

yes! That's it! Thanks so much @peterroth 🙏

[tjex]

Also, since the original post, my site was accessible at tjex.net (with https being crossed out).

But now after a few days I removed the domain from GitHub pages settings, and tried adding it again. Now tjex.net shows the GitHub Pages 404 again... 🤷‍♂️

(It wasn't a cache issue. I'd cleared my cache many times along the way)

I've also since set a CAA for letsencrypt.org over 72hours ago now (despite my registrar reportedly offering this by default). Didn't help.

[tjex]

...so. In the end, it was because my repository name did not match the <user>.github.io naming scheme 🤦‍♂️

Thanks Peter for pointing it out here

Explained here in the docs under step 3

Frustrating as I already had this repo from when hosting my website elsewhere, so I never looked at the documentation for creating the repo (i.e. from the start...).

There is also the case of the CNAME file within the repo.

Here under step 4, the docs refer to the CNAME file needing to be present when building from a branch.

It then states:

If you are publishing your site with a custom GitHub Actions workflow, no CNAME file is created.

This is not super clear whether a CNAME file is needed when building from a workflow (or whether the GitHub workflow creates it itself when building the site). My assumption is that the user still needs to add it manually, I've also seen another repo with a CNAME file in the /public folder.

Thing is that my site is now functioning and resolving correctly without the CNAME file. But it could be a case of errors down the track / unstable behaviour... So I'm going to add one anyway just in case.

Also here, there is the comment:

A CNAME file in your repository file does not automatically add or remove a custom domain. Instead, you must configure the custom
domain through your repository settings or through the API.

All in all, the documentation isn't super clear about whether a CNAME file is needed when building by workflow, but I suppose it can't hurt to include one.

[carlescufi]

As of 2024, this answer is not really correct. It is perfectly possible to have a project website (i.e. one whose repo is not called .github.io) using a custom domain with the DNS checks passing. @tjex are you sure you let 24h pass between the moment you changed your DNS settings in the Hosting provider and the moment you ran the DNS check on the GitHub repo?

[tjex]

well, I can't be sure just from memory as it was back last year, but throughout this process the only change to the respository name I made was from the original to tjex.github.io.

I wrote this:

I've also since set a CAA for letsencrypt.org over 72hours ago now (despite my registrar reportedly offering this by default). Didn't help.

Which would then mean that yes, 24 hours must have passed as this CAA attempt to fix was made after the initial setup didn't work.

Also, as pointed out, the official documentation does state the naming requirement for the repository name as <user>.github.io. I see this consistently enough around GitHub too. The repositories I see that don't follow this convention are hosting their websites elsewhere.

What would be best for your claim is if you have an example of a GitHub pages repository that doesn't follow this naming convention. Then it would be proven.

All I can say is that immediately after changing my repository name to the scheme stipualted in the documentation, the DNS resolved correctly.

[carlescufi]

Also, as pointed out, the official documentation does state the naming requirement for the repository name as .github.io. I see this consistently enough around GitHub too. The repositories I see that don't follow this convention are hosting their websites elsewhere.

It states that for user sites the repo name must be .github.io. This is not the case for project sites:
https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages#types-of-github-pages-sites

What would be best for your claim is if you have an example of a GitHub pages repository that doesn't follow this naming convention. Then it would be proven.

There are many out there, let me point you to one:
https://stackoverflow.com/questions/72488329/github-pages-project-site-is-at-the-domain-root-when-configuring-custom-domain

[tjex]

I am building a user site. That's what this issue is about, sorry if that wasn't clear. Well, the website posted in the stackoverflow thread (https://noymer.tk/) returns the exact same error I was having. Perhaps the page is down anyway since then, perhaps since then the setup requirements have changed on GitHub's side since the stackoverflow answer (June 2022), in any case, the page doesn't resolve, so it's not a good example unfortunately.