We are trying to decide which DNS hosting solution to use. Today we use Power DNS and we want to move to a hosted DNS solution. The best solution for us would be using Amazon's Route 53 for this.
We are mandated to use DNSSEC for our DNS solution and I have been trying to understand what Amazon's DNS supports and what it doesn't.
Amazon's site says:
Amazon Route 53 supports DNSSEC for domain registration but does not support DNSSEC for DNS service. If you want to configure DNSSEC for a domain that is registered with Amazon Route 53, you must use another DNS service provider.
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-configure-dnssec.html
Can anyone explain what this means? In particular what is supported and what isn't as well as what does using another DNS service provider for a domain that is registered with Route 53 mean.
Route 53 offers two¹ different services:
a DNS hosting provider, providing authoritative DNS hosting in hosted zones
a domain registrar, allowing you to register new domains for use on the Internet (or transfer the registration of existing domains so that your annual registration fees are consolidated into your AWS account bill)
Those two services have no necessary connection to each other. You can register a domain with any accredited registrar (for example, let's say GoDaddy), and still host the DNS with Route 53... or you can register a domain with Route 53 and still host the DNS elsewhere (for example, let's say Dyn)... or you can use Route 53 for both services, since they are independent.
Amazon Route 53 supports DNSSEC for domain registration
So, if you register a domain with the Route 53 Registrar, it can be configured to use DNSSEC...
but does not support DNSSEC for DNS service.
...but not if you use Route 53 hosted zones for authoritative DNS hosting, which does not support DNSSEC, regardless of who the registrar is.
Therefore...
If you want to configure DNSSEC for a domain that is registered with Amazon Route 53, you must use another DNS service provider
...to host your authoritative DNS records. You can't use a Route 53 hosted zone with DNSSEC.
¹ two different services that are relevant here. The emphasis is intended to be on different, because many other service providers blur the distinction between domain registration and authoritative DNS hosting to the point that many users seem unaware that they can almost always be decoupled, in at least one direction, regardless of the providers in question. Also under the "Route 53" banner are other services like Route 53 Resolver (which deals primarily with recursive querying in VPC and/or on-premise) and Route 53 Health Checks (which can be used as a basis for DNS failover as well as for other health-checking and latency-measuring purposes that can be but aren't necessarily even DNS related).
DNSSEC is now supported by AWS Route 53 for both DNSSEC signing (Hosting service) and domain registration (Registrar service).
Please follow the official guide to configure DNSSEC signing of the hosted zone here
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html
Related
I want to use my country domain which is mydomain.id after setting up in my azure DNS and domain provider, I still cannot validate my domain in App Service. I already double-check everything and I think my settings are already correct. Now I wonder can we use the Country domain in my azure DNS because I'm afraid if it's that the problem.
First of all, I assume you are using a public domain. As Martheen's comments mentioned that you just need to create DNS records to map your app service IP or hostname like webapp.azurewebsites.net in your DNS provider so that you can add custom domains in your App Service. This is tutorial.
Azure DNS is a hosting service for DNS domains that provides name resolution by using Microsoft Azure infrastructure. By hosting your domains in Azure, you can manage your DNS records by using the same credentials, APIs, tools, and billing as your other Azure services. You have the option to host your records on Azure DNS.
After adding the DNS records, you can use the local tool nslookup or websites https://dnschecker.org/ to check the DNS propagation. It can take up to 72 hours to propagate worldwide, although it typically takes a few hours.
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.
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.
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.*
I am looking for an easy way to fail over to a different DC quickly, does CloudFlare offer anything special in this regards with things like health checks or is it just like a standard DNS service?
Update: CloudFlare started a closed beta for the Traffic Manager feature which allows to do exactly this kind of failover:
https://www.cloudflare.com/traffic-manager/
AWS Failover:
The following solution seems to work well when you are hosting your backend system on AWS:
I setup a AWS Route 53 zone with a separate domain (e.g. failover-example.com). Route 53 allows you to setup health checks on the backend server (e.g. the load balancer) with DNS failover. AWS will remove the unhealthy backend system from the DNS record list.
In cloudflare I setup a CNAME for example.com record to failover-example.com and activate the cloudflare proxy on example.com.
The result is that the browser resolves the IP address of example.com to a cloudflare IP address. Cloudflare queries the AWS DNS server to lockup failover-example.com. Cloudflare fetches the content from the resolved IP address and returns the content back to the browser.
In my tests the switch to the other backend system occurs after ca. 20 seconds.
The separate domain is required because cloudflare does not route the traffic through the proxy when the CNAME is a subdomain of example.com.
I have tried to visualize the failover. In theory the failover works with any DNS failover capable service and not only with Route53:
The browser connects always with CloudFlare and hence a DNS failover of the backend system does never effect the browser of the user.
We don't have automatic failover at this time (something we're looking at). We can support the additional DNS entries in your zone file, of course, but you would currently have to manually make the change in that circumstance.
To add -- in the mean time, I'd recommend looking at https://runbook.io
Several other DIY options:
http://blog.booru.org/?p=12
https://vpsboard.com/topic/3341-running-your-own-failover-dns-setup/
https://github.com/marccerrato/python-dns-failover
You'd want to decide if these are the right options for you, of course.