I'm need to point an Azure hosted root domain/naked domain (example.com) to an AWS Elastic Load Balancer. Classic ELB's don't have IP's while A records can only point to IP's. Azure doesn't support the non-standard ALIAS/ANAME records that allow a CNAME-like configuration for A records.
Azure DNS provides a way to point to Azure cloud hosted websites using a combination of pointing the A record to the website's IP and creating a TXT record containing the DNS name of the website.
AWS Route 53 provides the ALIAS record type for connecting root domains to Load Balancers.
Is there a way to do this without resorting to using an extra server instance with a static (elastic) IP address just to do 301 redirects to www.example.com?
EDIT:I should add that since asking this question I found out that AWS network load balancers support both static and elastic IPs but we are on OpsWorks Chef 11 stacks which only supports classic load balancers.
Azure doesn't support the non-standard ALIAS/ANAME records
Note that these are not non-standard records, because they aren't record types at all. They are configuration entries that allow the nameservers to generate and return a standard A or AAAA record (or other standard types, in Route 53) based on information obtained dynamically by the nameserver, rather than based on static configuration.
But, there isn't another good solution to this. That's why these options exist.
A workaround is to use a service like http://wwwizer.com.
But your easiest and most straightforward solution is to host the domain on Route 53. This doesn't require changing your registrar -- you only have to change the authoritative nameservers. If you have subdomains that need their DNS hosted elsewhere for operational reasons, you can always delegate them. But this is a limitation of the fundamental design of DNS.
Related
We are planning to use cloudfront distribution for our main domain and the setup will be as follows.
Cloudfront Origin - route.domain.com -> Remote Server IP address(xx.xx.xx.xx)
www.domain.com, domain.com -> d123.cloudfront.com
As we know, we can setup CNAME for www.domain.com to point to cloudfront distribution(d123.cloudfront.net). However, for domain.com we should point A record to IP address and its not possible to setup CNAME record.
In route53, there is an option called Alias which can be used to point the domain to Cloudfront. But, our domain.com nameserver uses different provider and we would like to stick with current nameserver.
Any help would be appreciated.
Since this is a limitation in DNS itself, there is no way to accomplish this without a DNS hosting provider that supports an alias-like feature, sometimes called an "ANAME" or "flattened CNAME". Route 53 is of course the canonical example. CloudFlare and DNS Made Easy are others.
Or use a service like this one¹ to redirect your naked domain name to the www address, which would be your "real" site. They give you a single IP address for your A record. Note that your current DNS provider may have a "redirection" option that does this. It is not properly a part of DNS, but some providers allow you to configure domain redirections in their DNS portal.
Or migrate your DNS hosting to Route 53, keeping your DNS registration with your current vendor. In my mind, there is really no compelling reason not to use Route 53. See Making Route 53 the DNS Service for a Domain That's in Use for migrating to Route 53 without disruption, noting that the final step -- Transfer Domain Registration to Amazon Route 53 -- is entirely optional, as mentioned in the docs.
¹ this one is not a service I am affiliated with or have ever used in production, because I built my own service for that purpose using EC2, which is another option but outside the scope of this answer. This is intended as an example, not an endorsement.
Bluehost is my DNS provider and my app is hosted on heroku. I'm trying to point the DNS at my heroku app but there's an issue. Heroku's documentation states the following:
Some DNS providers will only offer A records for root domains. Unfortunately, A records will not suffice for pointing your root domains to Heroku because they require a static IP. These records have serious availability implications when used in environments such as on-premise data-centers, cloud infrastructure services, and platforms like Heroku. Since Heroku uses dynamic IP addresses, it’s necessary to use a CNAME-like record (often referred to as ALIAS or ANAME records) so that you can point your root domain to another domain. See examples below.
They go on to recommend creating a CNAME record with the values # and your root domain alias, e.g. hidden-sierra-7936.herokudns.com.
But Bluehost won't allow this because they want an IPv4 IP Address only and won't accept something like hidden-sierra-7936.herokudns.com as a valid CNAME record. I've already done the www record and things aren't working, so I'm guessing I need the ANAME record as well.
Is there any way around this other than switching to a new DNS provider?
Bluehost does not support this. Google and Cloudflare do, perhaps others. Cloudflare worked for me.
Simply put:
I have a domain called erik.com, two azure websites (east and west), and one traffic manager that is setup to manage the two azure websites.
When I take east offline (by throwing a non-2** status code) erik.com goes offline. This should not be the case! Right?
However, when I add a sub domain to the two azure websites (www.erik.com) then it works! I take one or the other offline and the traffic manager resolves to the available website.
I'm hearing/reading things that tell me that Traffic manager doesn't work with root domains like that... Say what?! Why?
As explained in the FAQs at https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-how-traffic-manager-works/#faq , Traffic Manager does not support 'naked' / apex domain names.
*Can I use Traffic Manager with a ‘naked’ (www-less) domain name?
Not currently.
The DNS CNAME record type is used to create a mapping from one DNS name to another name. As explained in the Traffic Manager example, Traffic Manager requires a DNS CNAME record to map the vanity DNS name (e.g. www.contoso.com) to the Traffic Manager profile DNS name (e.g. contoso.trafficmanager.net). In addition the Traffic Manager profile itself returns a second DNS CNAME to indicate which endpoint the client should connect to.
The DNS standards do not permit CNAMEs to co-exist with other DNS records of the same type. Since the apex (or root) of a DNS zone always contains two pre-existing DNS records (the SOA and the authoritative NS records), this means a CNAME record cannot be created at the zone apex without violating the DNS standards.
To work around this issue, we recommend that services using a naked (www-less) domain that want to use Traffic Manager should use an HTTP re-direct to direct traffic from the naked domain to a different URL, which can then use Traffic Manager. For example, the naked domain ‘contoso.com’ can re-direct users to ‘www.contoso.com’ which can then use Traffic Manager.
Full support for naked domains in Traffic Manager is tracked in our feature backlog. If you are interested in this feature please register your support by voting for it on our community feedback site.*
Our internal DNS is company.internal. I have aws.company.local running in a Route53 private hosted zone. Is it possible for me to use Route53 to resolve the parent's resources?
Not all of my VPCs have a route back to our company so I can't just forward to our internal DNS (and I'd rather not have to do resolution over that link anyways). I am trying to avoid creating caching DNS servers all over the place.
Route 53 doesn't do what you are looking for.
Route 53 provides an authoritative -- not recursive -- DNS resolver, and it doesn't currently have the ability to do zone transfers as a slave from a master. The only ways to update the records Route 53 will serve would be through the API or the console.
Marco#AWS (AWS support rep) wrote, in a forum post dated 2012-03-09:
“AXFR/IXFR is a feature we will consider adding in the future, but have no firm plans for at this time”
— https://forums.aws.amazon.com/thread.jspa?threadID=88666
The resolver built in to VPC can be configured to short-circuit the normal top-down resolution of hosts via the global root servers within a specific domain using private hosted zones... but the information has to be provisioned as authoritative inside Route 53 -- it can't be picked up and cached from elsewhere without an external mechanism to do the synching of records into Route 53. This isn't a built-in capability.
I'm using Google Compute Engine and want to point a custom url to the appspot domain. I don't need a whole hosting service, so I was wondering if there was a company that would allow me to purchase/transfer/register a domain, and host it simply pointing it to the appspot domain. I know I can do this through godaddy and cloudflare, but I don't want to pay for a bunch of stuff I'm not using. Is there any company that could just purchase and point the domain for me for really cheap?
It's not clear to me if you're using App Engine (appspot.com) or Compute Engine. (no DNS by default, just raw IP addresses)
In any case, you'll need to register the domain with a domain registrar like GoDaddy. It looks like Google's option, Google Domains, is currently an invite-only beta.
Once you've registered your domain name, the process is a little different depending on whether you meant App Engine or Compute Engine.
For App Engine, you'll want to set up DNS A records for the domain itself (aka "named domain" forwarding). This can be done in the Google Developer Console.
For Compute Engine, you'll probably want to set the A record for the named domain to point to a static IP address you have reserved in your GCE project. You can assign a static address to either a single instance (for small websites) or to a load balancer. If I were setting this up for a company, I would probably try to use the HTTP load balancing feature that's in limited preview, as it can perform latency-optimized cross-region load balancing.