Issue:
I have a naked url which works, but "www." + the naked url yields a 404 error. I'd like to point the www version to the naked version.
Context:
I have a serverless website, deployed on google cloud run.
I have a domain name registered through google domains, let's call it foo.bar.
Google cloud run provides two types of resource types for me to provide to google domains: A and AAAA, which are ipv4 and ipv6 addresses respectively.
I have added these A and AAAA records as custom records to google domains. With google domains, the hostname field is left blank, which is equivalent to #. From my understanding, this means that when someone types foo.bar, they get directed to these ipv4/ipv6 addresses. This works as intended.
But if I type www.foo.bar, I get a 404 error. As far as I know, www.foo.bar and foo.bar are not equivalent, and so there is no expectation that these two things should work unless explicitly instructed to. So I have tried two approaches to link these, as follows:
Added the A and AAAA resources, but specified www as the hostname, rather than blank. I would expect this to point www.foo.bar to the ipv4/ipv6 addresses too.
Added a CNAME resource, which specifies www.foo.bar as the hostname, and foo.bar as the data. I would expect this to redirect www.foo.bar to foo.bar, which points towards the ipv4/ipv6 addresses.
I would expect both of these to work equivalently, yet neither of them work. I feel like I am misunderstanding what is going on when managing these records, or that google domains is more opaque about what it is doing than I'd like.
Is my understanding of what should happen incorrect? And how can I properly set up the www extension?
You must create Cloud Run custom domains for each hostname. One for example.com and another for www.example.com. You must also create the DNS resource records, which you mentioned that you did complete.
Related
I have two subdomains in amazon route53: *.bar.example.com and
foo.bar.example.com and in the backend the two microservices they
were hitting was different which we defined in ingress resource rules.
When we hit foo.bar.example.com will it redirected to foo.bar service
or will it redirect to wildcard service and viceversa?
The wildcard is only the default value if nothing matches.
See https://en.wikipedia.org/wiki/Wildcard_DNS_record
This wildcard DNS record will cause DNS lookups on domain names ending in example.com that do not exist
(emphasis mine)
PS: there is no "redirection" in the DNS; this is a term existing at the HTTP layer.
Let's say I have requests coming into my IIS site on two different ports. Can I direct one port to serve www.website.com and another to www.website.com/subfolder?
I'm trying to do some georouting without having more than one webserver or site. I have AWS Route-53 set up to send traffic based on region to different load balancers that will take traffic from one region and send to port 2000, and from a different region to port 2001. www.website.com has content geared for the first region, but www.website.com/subfolder is our content for the other region. Since AWS can split up the traffic for me based on location and send to different ports of my choosing, is there anyway to use that to route or redirect requests to different folders on the same site?
EDIT: I think the way to do this is with a URL redirect rule, with a condition for {SERVER_PORT} specifying the port like so:
Match URL: Matches Pattern: .*
Condition: {SERVER_PORT} Matches Pattern 2001
Action Type: Redirect URL: subfolder/{R:0} Type: Permanent (301)
This should route everything coming in on port 2001 to my subfolder but not the traffic on other ports, correct? The site CMS already arranges everything so that www.website.com/(anything) and www.website.com/subfolder/(anything) will display the same content, with changes appropriate to the region.
So this works with the Redirect rule I assigned above. Since it broke a few includes, like stylesheets and whatnot, I also added some exclusions with {PATH_INFO} tag, and there needed to be a rule to exclude URLs that already had subfolder/ in them, using the {HTTP_URL} condition, to prevent the redirect from looping forever and giving you www.website.com/subfolder/subfolder/subfolder.... etc.
i am very confused about the whole domain vs hostname thing. I tried googling, but the answers are too confusing for me, so i wanted to create a question using a specific example known to most people.
So lets take as an example atlassian's products. The url is atlassian.net.
If i wanted to create my project on atlassian, url would look like myproject.atlassian.net. My customer potentially wants a similar system for his website, so i need to know how to validate names of subprojects.
So, is myproject a subdomain or a host?
What are naming rules, e.g. can i use underscores/dots in that part of url?
How does routing work for such urls? Dns resolves the top url atlassian.net and then server logic serves pages for specific subproject?
Thanks.
In most common case Hostname (e.g. localhost) is usually parameter used for internal program reference and domain name is used for external / internet reference. How domain resolve to hostname can't be summarized easily. You may see many places where both by fault were used as synonyms and so based on context you need to figure out the purpose.
Your example is not correct in context of JIRA.
"mycompany.atlassian.net" is actually your company account it might have multiple projects within it issues that are within the project got URLs like "mycompany.atlassian.net/browse/STAC-20" where STAC is the project key
It terms of how domain/sub-domain name works. There are different level of configurations and a good start for you probably might be this link:
https://uk.godaddy.com/help/what-is-a-subdomain-296
Here is short explanation in case you are referencing "Name server" hosts:
Each domain once configured needs 2-3 name servers that will know how to resolve all its subdomains, aliases usually these are provided by hosting company where we are placing our domain.
So if "mydomain.com" might be configured with "ns1.anyhosting.com", "ns2.anyhosting.com" to serve "mydomain.com" dns requests.
In case you are the one that wants to to host "name server". It is possible by configuring "Hosts" at domain registration that have explicit IPs e.g. "ns1.mydomain.com" , "ns2.mydomain.com" and these are referred as Hosts.
This is the exact word from my textbook:
Demonstrate by giving an example:
What is the hostname of the following URL?
http://www.weather.com/summer/temperatures.html
solution: www.weather.com
Reason:
The hostname is the complete domain name, which is the characters after the scheme and
before the path.
Some other definitions:
Scheme - Characters at the beginning of a URL followed by a colon ":" or a colon and double slashes "://". Common URL schemes include http, https, mailto, and file. Ex: In http://www.cdc.gov/alcohol, the scheme is "http".
Hostname - The complete domain name specified in the URL. Ex: In http://www.cdc.gov/alcohol, the hostname is "www.cdc.gov".
Path - All characters to the right of the hostname in the URL. Ex: In http://www.cdc.gov/alcohol, the path is "/alcohol".
I have a complex web app at example-app.com, hosting fully on AWS using ELB and Route 53 for DNS. It's a Rails app.
I'm running an experiment that I'm using in the rails app, at example-app.com/test. I want to set up new-domain-app.com, to point at example-app.com/test, and have the URL cloacked to always be new-domain-app.com. It's a single page site, so it shouldn't require any navigation.
I'm having a lot of trouble figuring out how to set up my DNS on Route 53 to accomplish this. Does anyone have good ideas on what this Route 53 configuration should look like?
AWS offers a very simple way to implement this -- with CloudFront. Forget about the fact that it's marketed as a CDN. It's also a reverse proxy that can prepend a fixed value onto the path, and send a different hostname to the back-end server than the one typed into the browser, which sounds like what you need.
Create a CloudFront web distribution.
Configure the new domain name as an alternate domain name for the distribution.
For the origin server, put your existing hostname.
For the origin path, put /test -- or whatever string you want prefixed onto the path sent by the browser.
Configure the cache behavior as needed -- enable forwarding of the query string or cookies if needed and any headers your app wants to see, but not Host.
Point your new domain name at CloudFront... But before you do that, note that your CloudFront distribution has a dxxxexample.cloudfront.net hostname. After the distribution finishes setting up (the "In Progress" status goes away, usually in 5 to 20 minutes) your site should be accessible at the cloudfront.net hostname.
How this works: When you type http://example.com into the browser, CloudFront will add the origin path onto the path the browser sends, so GET / HTTP/1.1 becomes GET /test/ HTTP/1.1. This configuration just prefixes every request's path with the string you specified as the origin path, and sends it on to the server. The browser address bar does not change, because this is not a redirect. The host header sent by the browser is replaced with the hostname of the origin server when the request is sent to the origin.
What you are trying to do is not possible. Route53 is a DNS system, and you can not configure a hostname (e.g. new-domain-app.com) to point to URL (e.g. http://example-app.com/test) using DNS.
However, you are probably using a wrong tool for the job. If example-app.com/test is indeed a simple, static, single page site, then you do not need to host it inside Rails app. Instead, you can host it on AWS S3 bucket, and then you can point new-domain-app.com to that bucket using Route53.
See the following for details:
http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/RoutingToS3Bucket.html
DNS knows about Domains, not url's. DNS simply converts names to IP addresses.
You can't do what you are asking for just using DNS and ELB, however, what you can do is have a seperate VHOST for new-domain-app.com that points to your example-app.com site and accomplishes what you want using some sort of redirection rule that only fires for new-domain-app.com.
I'm not sure that this qualifies as an SO question, and more likely is a serverfault question. Specifics about your webserver and OS platform would be helpful in getting more specific advice.
So here's some details:
You already have example-app.com setup and working
You create a CNAME entry pointing new-domain-app.com to example-app.com or you can make an A record pointing to the same IP. If you already have example-app.com pointing to a different IP address, then use a subdomain (test.example-app.com) to isolate it.
Setup a new vhost on your server that basically duplicates the existing vhost for new-domain-app.com. The only thing you need to change is the server name configuration.
Why does this work? Because HTTP 1.1 included the HOST header that browsers send along, and web servers use in vhosting to determine which virtual host to route an incoming request to. When it sees that the client browser wanted "example-app.com" it routes the request to the appropriate vhost.
Rather than having to do some fancy proxying, which certainly can be used to get to a similar result, you can just add a redirection rule that looks for requests for the host example-app.com and redirects those to example-app.com. In apache that uses mod_rewrite which people often utilize by putting rules in the ubiquitous .htacess file, but can also be done in nginx and other common web servers. The specifics are slightly different for each.
I have a VPS. I have placed a Drupal installation on that IP address. There is no URL registered for my website. The site on the IP address is for personal reference.
Can my IP address get indexed and found on search engines if there is no traditional URL for it? Will it get crawled?
I have no A-records pointing to it from other domain names I have on another VPS platform either. As far as I know, I am the only one that knows this IP address by heart or even goes there to add or refer to content.
There are three ways I know for a search engine to learn about the existence a website.
You submit the domain to them directly.
Someone else links to the domain.
The search engine watches all domain registrations (Google can do this easily because they run a DNS themselves), and tries the standard prefixes (e.g. www).
There does not seem to be an automatic approach for discovering IP addresses with content unless someone links to it.
If it's purely for personal reference and you want to be sure no one else can access it, then you should implement security anyway. Don't just rely on no one knowing the IP.
Can my IP address get indexed and found on search engines if there is no traditional URL for it?
Yes, if you can reach it externally, then so can the search engines. If you don't want it to be indexed, add a "robots.txt" that requests for the site not to be indexed. Bear in mind that crawlers do not have to respect this, but the major ones do.
As for how the search engines discover IP addresses that are not indexed elsewhere, that is probably part of their "secret sauce" that we will never know about. Perhaps your IP has been used before, and it has previously been indexed in that context; if so, a search engine that has a poke around may be expecting that old site but will happily index your new one.
Or, maybe other IP addresses in the same netblock are in active use, and the search engines give yours "a quick try" to see if it responds on ports 80 (http) or 443 (https). If they do, it gets added to their indexes (or do-not-crawl lists, if your robots.txt requests it).
If you specifically do not want search engines to see your content, you could make the default home page blank, and put your Drupal installation in a sub-directory. The search engines will then have nothing to index apart from a blank home page.