CAIA Center Dev Log 001
The Domain Sourcing Journey:
STRATO and GitHub Pages
When we first set out to register domains for CAIA Center, our plan was simple: source a cheap hosting account to serve as a launchpad for our website, pointing it to GitHub Pages. After some research, we chose STRATO, a service that offered a low-cost account with one IP address in “A” and more household configuration options in “C” (totally enough for our needs). All we needed was to get the domain pointing to GitHub Pages, set up SSL/TLS, and get the site up and running.
We registered the domain caia.center—all seemed perfect at first. We did the DNS configuration, updated the GitHub settings, and thought we were good to go.
The DNS and SSL Mishap:
The DNS Waiting Game
However, after a few hours, we started to notice something odd. The GitHub DNS check wasn’t clearing. GitHub Pages didn’t recognize the domain. Naturally, we thought it was an issue with STRATO—maybe something was wrong on their end. We even convinced ourselves that we were the victims of some bad customer service. We didn’t panic immediately, though, because we’ve dealt with DNS issues before. So, we decided to wait it out. Surely, the DNS would update within a day or so, right?
Fast forward 24 hours, and we were still waiting. At this point, our frustration was building. But, as any seasoned developer knows, DNS updates can sometimes take time, even though we were certain it shouldn’t take that long.
The Realization:
www. matters for GitHub Pages and SSL/TLS
The next morning, we decided to take matters into our own hands, finally, and investigate deeper. After a quick search, we discovered something that hit us like a ton of bricks: “The GitHub Pages Manual”
Although quite easy to digest, we thought we know it all.
Apparently GitHub Pages requires the domain to have the www prefix for TLS/SSL (https://) to work properly. The domain caia.center worked instandly although the GitHub DNS check did not resolve the Domain. www.caia.center on GitHub. It turns out, the DNS records were fine, but the domain configuration on GitHub Pages needed to specifically point to www.caia.center—not caia.center.
We had completely missed this detail when checking the GitHub Pages docs, both AI and Human, and assumed it was an issue with the DNS provider. But in reality, the DNS was updated instantly, and the problem was in the GitHub Pages configuration. After switching to www.caia.center, everything started to work within minutes.
Forcing SSL/TLS:
Redirecting to Port 443
Another crucial aspect everyone should tackle, is enforcing SSL/TLS across the site. To ensure all requests were directed securely to HTTPS, we configured GitHub Pages to force SSL/TLS. It is so simple, it’s ticking a box. This means that no matter how the user accessed the site (with or without the “www”), they would be automatically redirected to port 443 (the standard port for HTTPS).
However, the initial creation of an SSL/TLS cerificate via “let’s encrypt” is done withing githubs doors, and takes about 10-20 minutes.
But all in, it is a no hassle experience, tick the box - site is safe.
Tech Snack: How We Set It All Up
Here’s a quick rundown for anyone else who wants to get a GitHub Pages site running with a custom domain and SSL/TLS as of the date of this writing:
Domain Registration:
We registered caia.center (and added www.caia.center as the primary domain) via STRATO.
Make sure to check your registrar for DNS management settings. Unfortunately our setup does not allow for the redundancy of multiple target IP’s. Maybe a service request would, we don’t know, we did not ask - it works for now.
GitHub Pages Setup:
In the repository settings on GitHub, we added the custom domain under Settings > Pages >
Source: “Deploy from Branch”
Branch: “main”, “/(root)”
Custom domain: “www.yourdomain.com”
DNS Setting
(best after GitHub Pages Configuration)
We updated the DNS Setting record for www.caia.center in our DNS settings (in STRATO’s DNS configuration panel).
IPv6 Setup: GitHub Pages supports both IPv4 and IPv6. While we used just the IPv4 addresses in the A-RECORD setup, you may also want to configure IPv6 for future-proofing. You could add the following A-RECORD entries for GitHub Pages:
185.199.108.153 185.199.109.153 185.199.110.153 185.199.111.153
Using a CNAME Record for Subdomains: If you want to redirect a subdomain (like www.caia.center) to GitHub Pages, it’s important to set a CNAME record that points to your GitHub username’s domain (e.g.,
reference: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site
And Yes, If would have read the bove, we would not have had to wait 24 hours for a valid DNS ;)
GitHub Pages Configuration – SSL/TLS via GitHub Settings: When setting up GitHub Pages with a custom domain, after confirming your DNS settings, make sure you: Enable “Enforce HTTPS” under the Pages settings in your repository. This ensures that all traffic to your domain is securely redirected to HTTPS (port 443), which is vital for security and trust. GitHub makes this pretty easy, but it’s crucial to double-check.
DNS changes can take a while but remember:
if it’s working in the registrar’s DNS records, the problem might be in GitHub’s configuration or in the “www” domain setting.
Checking DNS Propagation:
A useful trick to check if your domain is resolving correctly after DNS setup is to use a tool like https://dnschecker.org/. You can enter your domain and check its propagation status across different servers worldwide. This can be a real time-saver.
Handling Redirects and SEO Considerations: It’s also good practice to configure 301 redirects if you’re moving from an old domain structure. For example, if you used caia.center as the initial domain and later switched to www.caia.center, ensuring that visitors are redirected smoothly to the new domain can avoid broken links and negative impacts on SEO.
GitHub Pages Cache and Caching Issues: Sometimes, especially during DNS changes or repository updates, GitHub Pages can be a bit slow to serve updated content. If you’re making changes and they don’t appear immediately, try clearing your browser cache or using a different browser to see if it’s a caching issue.
DNS changes can take a while but remember:
if it’s working in the registrar’s DNS records, the problem might be in GitHub’s configuration or in the “www” domain setting.
Expected Wait Time:
Expect up to 24 hours for DNS propagation, but remember—GitHub’s DNS check is fast. Once the CNAME is set, it should go live almost immediately.
Key Takeaways:
- www matters for GitHub Pages and SSL/TLS enforcement. Always make sure your domain is set up with www in the DNS and GitHub settings.
- DNS issues? Be patient, but also check for misconfigurations. The problem may not always be the registrar.
- SSL/TLS enforcement should be a priority. Ensuring every request goes through HTTPS improves security, trust, and SEO.
- Conclusion: A Learning Experience
Looking back, this whole process was fun, frustrating and enlightening. We learned the importance of paying attention to the small details in DNS settings and SSL/TLS. The lesson here: never underestimate the importance of the “www.” And when in doubt, dig deeper before assuming the problem is on the provider’s end. That’s for both, human and AI!
But, just like the CAIA Center project itself, this journey is all about learning and evolving. With each challenge, we gain new insights into both the technical and philosophical aspects of working with cutting-edge technologies—and we’re always ready to share that with you.
Stay tuned for more logs as we continue building, learning, and evolving in real-time.
sincerely
Seb & 4o
