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.
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.
I've setup my personal website with github, figured out the DNS configs based on the following page. I used A records because those are used in Route53 configs and when I test my DNS routing for mydomainname.com with Route53 tool, I get the proper response.
i.e. the DNS returns me the required GitHub IPs as I configured. However, when I try to run dig mydomainname.com I get an empty response.
I'm confident that I've waited long enough for changes to propagate (probably more than two full days now) so what could be the issue here? Any advice on how to further troubleshoot the routing issues?
UPDATE:
Looked up my url's who is data.
DNS Hosting works with 2 steps: configuring the dns servers to answer queries, and delegating the domain to them.
The first part you seem to have working: you've set up a Route 53 Zone, configured the records, and have successfully resolved them from one of the nameservers in the NS record Route 53 configurd for you when you created the zone.
The second step is essentially to tell your registrar that when the public attempt to look up the domain, they should be referred to the route 53 servers you configured. By adding these same dns servers from the NS record in the working, public route 53 zone, you will delegate dns on that domain to those servers.
You registered your domain on amazon so it created a route53 zone for you, with matching DNS servers in it. Either you removed this zone or created another one. That's fine to do, but each zone costs 50 cents a month, so get in the habit of removing ones that aren't working. You can create any number of route 53 zones to serve the same domain, but the ones you put in the registrar are the ones the public will use to resolve the domain.
Once whois mydomain.tld ( or a web equivalent, if whois isn't available in your environment, like from your screenshot) shows the same nameservers that you can successfully query against with dig, you're golden. It might take some time for the registrar's setting to propagate; in practice this is typically on the order of minutes.
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.
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
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.