I am new to working with AWS and route 53 so any help is appreciated.
I have created an organization on GitHub, and then created a simple repository for a static site to display with Github pages. this is working as expected and I can see the static site at the URL generated by Github (something like: https://<githubOrgName>.github.io/<repoName>/)
I got a domain from AWS and now I'm trying to set it up so the apex domain (e.g. "my-domain.com") points to the Github pages site.
I followed the instructions found at: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/about-custom-domains-and-github-pages ... but it doesn't seem to be working.
I am trying to make it so that the apex domain points to the repository Github page. something like:
https://my-domain.com -> https://<githubOrgName>.github.io/<repoName>/
... but this only shows a blank screen when I go to the root domain ("my-domain.com"). I have also tried to go to https://my-domain.com/<repoName>/... but this shows me a Github 404 page (so it seems to be correctly forwarding something to Github):
my AWS route 53 configuration is similar to the following (i have tried to remove sensitive details):
can anyone explain to me what I am doing wrong? I am new to working with domains so any help is appreciated.
Using Route53 alone won't help you there, because your target URL contains a URL path i.e. /<repoName>/.
DNS is a name resolution system and knows nothing about HTTP
Furthermore, the origin server (github.io) might be running a reverse proxy which might be parsing the request headers, among which is the Host header. You browser automatically sets this header to the url you feed it. Eventually, you send it the wrong header (i.e. https://my-domain.com/), which Github cannot process. You can explicitly set this header (e.g. via curl) to what Github is expecting, but I believe it's not what you and your users would like.
Instead, you could try using layer 7 redirects (301/302) with the help of Lambda#Edge (provided by AWS CloudFront). I have created a simple solution using the Serverless framework, which does the following redirects:
https://maslick.tech -> https://github.com/maslick
https://maslick.tech/cv -> https://www.linkedin.com/in/maslick/
https://maslick.tech/qa -> https://stackoverflow.com/users/2996867/maslick
https://maslick.tech/ig -> https://www.instagram.com/maslick/
But you can customize it by adjusting handler.js according to your needs. You might also need to create a free TLS certificate using AWS Certificate Manager in the us-east-1 region and attach it to your CloudFront distribution. But this is optional.
Lambda#Edge will give low latencies, since your redirects will be served from CloudFront's edge locations across the globe.
How I got it to work was:
Set a CNAME record from example.org to <USERNAME>/github.io. in the Route 53 console
Set Custom domain to example.org in the Github Pages settings for github.com/<USERNAME>/<REPO>
Note: You shouldn't be setting the CNAME record to <USERNAME>/github.io/<REPO>
Source: https://deanattali.com/blog/multiple-github-pages-domains/
Related
I am absolutely new to GitHub so this may come out as a silly question. I am trying to host my website using GitHub pages. The website got hosted properly, but when I added the custom domain, it stopped working and now I am getting a blank page. What I have done is, have created a subdomain in my AWS-hosted zones (subdomain.example.com) and pointed it to https://my_org.github.io/my_repo/
Then I added subdomain.example.com in github page custom domain and CNAME file in the repository.
The error I am getting is
DNS check unsuccessful
subdomain.example.com is improperly configured Domain's DNS record
could not be retrieved. For more information, see documentation
(InvalidDNSError).
I am not sure what I am missing exactly. Does anyone have any idea about this?
It might be that you need to verify your domain name through a TXT record:
https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/verifying-your-custom-domain-for-github-pages
NOTE: I'm providing details of my setup, but really this is a "how is this possible" question, not a "please debug my setup" question.
I have a "singe page application" (ie. an HTML file that uses the History API to simulate URLs). I'm serving this app on AWS S3, behind an AWS Cloudfront ... front.
I had successfully configured things so that if someone went to www.example.com/foo (let's pretend I own example.com), Cloudfront would serve an "error page" of my index.html. My index.html would then see the URL, and use its routing to show the user the correct page.
That all worked great ... until it didn't. Now for some reason when I go to www.example.com/foo, I get redirected to www.example.com. I'm trying to debug things, but what I can't understand is how I'm going from /foo to the main page.
When I look in the Network panel of my developer tools, I can see the request made to the original (/foo). Then I can see the chain of requests (for images, css files, etc.), and they all have a referrer of www.example.com/foo.
Then all of the sudden I see a request for React Developer tools (why it needs to make a request is beyond me) ... and it's from referrer www.example.com. After that I get one last image request from /foo, and then all subsequent requests come from www.example.com.
Can anyone explain how this could be working? I know that if a server returns a redirect (either type) that could change my URL ... but every request has a 200 status (ie. no server redirects).
I know Javascript could "push" a new URL to my browser ... but that would leave a history entry right? When I go "back" (either with my browser or history.back()) I go to the page before; I don't go "back" to /foo.
So somehow I'm not making a history entry, but I am switching my URL, and the URL I make requests from, and this all happens within milliseconds on page load ... without any redirects. How?
P.S. When I use my dev tools to add an beforeunload breakpoint, then try to navigate from example.com to example.com/foo I don't hit that break point (either for going to /foo, or when I'm "redirected" back to example.com).
When I check the box for any Load event, I do see some happen ... after my URL has already switched. In other words, I type example.com/foo, hit enter, and by the time any event fires I'm back on example.com. Whatever mechanism is doing the "redirection" here ... it doesn't trigger any load events.
I figured out my (AWS-specific) problem, thanks to a bit of Gatsby documentation. I'll include the details below in case it helps others, but I won't accept this answer, as I still don't understand how AWS did what it did (and I'd still welcome an answer for that).
What happened was that I had my Cloudfront "Origin Domain Name and Path" pointing to:
example.com.s3.amazonaws.com
However, as explained on https://www.gatsbyjs.com/docs/deploying-to-s3-cloudfront/:
There are two ways that you can connect CloudFront to an S3 origin. The most obvious way, which the AWS Console will suggest, is to type the bucket name in the Origin Domain Name field. This sets up an S3 origin, and allows you to configure CloudFront to use IAM to access your bucket. Unfortunately, it also makes it impossible to perform serverside (301/302) redirects, and it also means that directory indexes (having index.html be served when someone tries to access a directory) will only work in the root directory. You might not initially notice these issues, because Gatsby’s clientside JavaScript compensates for the latter and plugins such as gatsby-plugin-meta-redirect can compensate for the former. But just because you can’t see these issues, doesn’t mean they won’t affect search engines.
In order for all the features of your site to work correctly, you must instead use your S3 bucket’s Static Website Hosting Endpoint as the CloudFront origin. This does (sadly) mean that your bucket will have to be configured for public-read, because when CloudFront is using an S3 Static Website Hosting Endpoint address as the Origin, it’s incapable of authenticating via IAM.
Once I changed my Cloudfront "Origin Domain Name and Path" to the bucket's static hosting URL:
http://example.com.s3-website-us-west-1.amazonaws.com
Everything worked!
But again, I still don't understand how AWS did what it did when I mis-set my "Origin Domain Name and Path". It redirected me to my root domain, seemingly without either a redirect response OR a client-side redirect, and I'd love to hear how that was accomplished.
I am trying to create a GitHub page for a repository. But when I gave the custom domain name, it shows the following message "Domain's DNS record could not be retrieved. For more information"
As I am new to GitHub I am not getting the information what is documented in GitHub pages. Could anyone help me to resolve this problem?
If you've recently changed or removed your custom domain and can't access the new URL in your browser, you may need to clear your browser's cache to reach the new custom domain. For more information on clearing your cache, see your browser's help site.
In order to serve the Page, your DNS records must point to GitHub's server. To confirm that your custom domain points to GitHub's servers, use the dig command with your custom domain. The dig command shows you where your custom domain points. For example:
$ dig example.com +nostats +nocomments +nocmd
example.com. 3600 IN A 185.199.108.153
In the example above, example.com points to the IP address 185.199.108.153.
If you configured A records through your DNS provider, your A records must point your custom domain to the following IP addresses:
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
You may see a different IP address, since we serve Pages with a global Content Delivery Network. Use dig username.github.io to see the full resolution path. Note that DNS caching may cause a delay.
If you're using an A record that points to 192.30.252.153 or 192.30.252.154, you'll need to update your DNS settings for your site to be available over HTTPS or served with a Content Delivery Network. For more information, see "HTTPS errors."
If you're using an A record that points to 207.97.227.245 or 204.232.175.78, you'll need to update your DNS settings, as we no longer serve Pages directly from those servers.
Source: https://help.github.com/en/articles/troubleshooting-custom-domains
I'm confused why CNAME file is also needed in my github pages repository? Why CNAME needs to be done twice at my domain provider and github pages?
How the things works together?
When a http request comes in, saying the request is for mygithub.mypage.com, github has to know on whose behalf this request is for, so whose page it has to deliver.
This is what the setting at github is for.
To be exact, what github's server sees is a http request like
GET / HTTP/1.1
Hostname: mygithub.mypage.com
There is no notion about mypage.github.io. They could do a DNS query to find out where mygithub.mypage.com points to, but they chose to use this version.
I did some further thinking, I think glglgl's answer doesn't answer my question. Because In my domain provider: I've added a CNAME Record like this:
when the request comes to github, github should have enough information to know which user's github page to deliver, right ? It's obvious the request is to get the xxuser's github page.
Then why github page requires an additional CNAME file? The reason, I think, is that it gives the power to the owner of the repository to control what custom domain is allowed to link to the repository website. If a custom domain which is not in the CNAME file links to github page, there's going to be 404 error page shown from github. That means only the custom domain the owner put in the CNAME file can be linked, which obviously would be a domain owned by the owner of the repository.
I have my non-www domain.com with GoDaddy and my WordPress Blog is hosted in AWS EC2. I'm using Route 53 to handle DNS requests. The existing solution for my question, seen in many places(including SOF) is to create two S3 buckets in the name of non-www domain and www domain for redirection of static websites. This is not my case.
I've my WordPress installed in EC2 and not using S3 for holding my Data. I hope this is not a static website and cannot follow the general solutions available.
I tried the following solution around and did not work
I tried changing the C-NAME record to www.domain.com but it did not worked.
I tried domain forward feature available with GoDaddy.com and didn't work.
I tried modifying .htaccess file and that too didn't work.
This is what my record sets in Route 53 look like
Name Type Value TTL
------ ----- ----- ----
domain.com. A xx.xx.xxx.xxx (EIP) 300
domain.com. MX 1 ASPMX.L.GOOGLE.COM 3600
5 ALT1.ASPMX.L.GOOGLE.COM
5 ALT2.ASPMX.L.GOOGLE.COM
10 ALT3.ASPMX.L.GOOGLE.COM
10 ALT4.ASPMX.L.GOOGLE.COM
domain.com. NS ns-27.awsdns-03.com. 172800
ns-1190.awsdns-20.org.
ns-2028.awsdns-61.co.uk.
ns-855.awsdns-42.net.
domain.com. SOA xxxxxxxxx 900
How can I redirect my domain.com to www.domain.com?
I was hesitant to post my comment as an answer because there are a gazillion ways to setup and configure Wordpress it seems. Anyway, to keep in the spirit of keeping this question in the amazon-web-services tag I ran a test case deploying from the AWS Wordpress Cloudformation template. I'm not sure if this is how you actually installed Wordpress but here is one way to redirect:
Make sure that your Cloudformation template completes successfully.
Here is what my Hosted Zone looked like - I have not added A records yet.
Get the instance IP address. Note that in this example I did not setup an Elastic IP. Since I knew that I would not need to stop the instance temporarily I opted to just stick with the automatically assigned, random pubic IP.
Next I made an A record for the domain apex of that IP and then an A record for www. I also changed the TTL to 60 seconds.
Once DNS propagation completed I tried accessing my domain name. As you can see, the AWS Cloudformation Wordpress installation defaults to a different path and URL.
Using the URL, http://example.com/wordpress did the trick.
I didn't go through the steps but when you go to http://example.com/wordpress it starts a setup screen. Enter all the information like DB name and password, etc. and then login to the admin panel. Once you go through all of that you go to the General settings screen. This is where your configuration will probably be different but for mine, the URLs were listed as http://example.com/wordpress. I simply changed these URLs to http://www.example.com/wordpress. (As an aside, I also tried changing and saving the permalink section to generate an .htaccess file but one was not generated due to the inability to write to the file. I tried making my own but I kept running into "too many redirect" messages so this might not be a route you want to take depending on your install.)
You will need to make a change in the index.php file. For my installation it was located at /var/www/html/wordpress/index.php. Make sure to make a copy before changing it. I simply added /wordpress/ in front of wp-blog-header.php. Again, this install puts the Wordpress files in the directory /wordpress - your install will probably be different.
Next you need to copy that modified index.php file to /var/www/html/ and then restart the httpd service.
To test the change I cleared out my DNS cache and opened up the network section of developer tools in Chrome.
I then opened a new tab (have to open developer tools again) and then typed in the naked domain name.
As you can see, the URL redirected to www.example.com with a 301 permanent redirect.
I'll through another suggestion out here while I'm at it. You can use the free version of Cloudflare to just do the redirect for you. Cloudflare offers a bunch of other free and useful services like CDN so if you don't mind depending on a 3rd party service (a reputable one by the way) it might be easier with more value add. As I highlighted in the screenshot however, note that if you use forwarding you cannot use some of the other advanced rule sets.
Anyway, I hope this helps!