I'm in the process of migrating a bunch of stuff over to AWS and I've hit a bit of a snag in relation to Route53, specifically with vanity nameservers.
Current setup (not on Route53);
ns1.example.com - Glue records pointing to IP address of current DNS provider
ns2.example.com - Glue records pointing to IP address of current DNS provider
Various domains, all set to ns1.example.com for their authorities nameservers at the registrar;
website-one.com
website-two.com
etc.
So I've been doing some testing with getting this migrated to Route53, and I'm not sure this is straight forward to do when you want to use a single vanity nameserver across multiple domains. When I create 2x hosted zones in Route53, they get different nameservers that Route53 automatically generates, i.e.;
example.com Hosted Zone - ns-123.awsdns-456.com
website-one.com Hosted Zone - ns-789.awsdns-321.com
website-two.com Hosted Zone - ns-987.awsdns-654.com
etc.
As such, with there only being one option at the registrar for example.com to configure the Glue Records;
ns1.example.com - pointing to IP Address of the Route53 nameserver, i.e. ns-123.awsdns-456.com (1.2.3.4)
ns2.example.com - pointing to IP Address of the Route53 nameserver, i.e. ns-123.awsdns-456.net (1.2.3.4)
Then I'm a bit lost as to how you're supposed to get this kind of setup working in Route53.
The reason for wanting this is to avoid having to go messing around with the nameservers at all of the different domains, some of which I can easily access, others are a bit of a pain to get access to so they can be updated.
Thoughts on how to best approach this?
Related
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.
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.
I am trying to configure a www domain on azure. I want to have website under this domain. My domain is "legia.fitness". I have created the DNS zone as follows:
On this picture you see 4 DNS servers. I have delegated my domain that I bought at home.pl to those servers:
And this doesn't work. When I try to browse legia.fitness I get "ERR_NAME_NOT_RESOLVED" error. What am I doing wrong?
Your Azure DNS zone does not have any A or CNAME records for www or # so the name cannot be resolved to an IP address.
Add a new A record with the label # set to the IP address of your Azure website, and another A record with the label www also set to the same IP address.
Alternatively, create CNAME records (both # and www) and set them to your Azure Website's name (e.g. yourwebsite.azurewebsites.net). CNAME records are aliases of existing A or CNAME records, but are slower to resolve which is why I prefer A records.
You haven't directed the domain anywhere yet.
You have a DNS zone that works. I can see the SOA records on Dig web interface.
Now you have to add CNAME/A records to the DNS zone to direct the traffic to where you want it.
Here is a guide for Azure Web Apps: https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-custom-domain-name
If you use something else, you'll need to find its guide.
I'm not a routing expert. But what I know: It can be a really big topic. So, I'm currently thinking about geo-load balancing and how I can provide it. You can use Route 53 to create GeoDNS lookups. And this is fine and good. But I think about CDNs. I have only two location, while CDNs have tons of locations. Why not resolving my domain www.example.com with one of these CDNs IPs directly? My frontend is static. The dynamic stuff is created by Javascript. So, is it possible to resolve my domain example.com directly with the nearest CDN IP?
What you describe is quite usual setup. On AWS, after you create CloudFront distribution, you will simply create ALIAS in your Route53 console:
www.example.com A ALIAS xyz123xyz.cloudfront.net
If you are using other CDN/DNS providers, you will create CNAME record:
www.example.com CNAME xyz456xyz.somecdn.net
It is possible to resolve your domain to only one CDN IP. And when we talk about CDN IP, it is usually virtual IP (Anycast IP) where it maps to different physical edge servers globally. Depending on where the request is coming from, that virtual IP will map to the edge server closest to the end user.
Take this domain www.cloudflare.com for example, it is on Cloudflare (http://www.whatsmycdn.com/?uri=www.cloudflare.com), and it is pointing to two Cloudflare virtual IPs for failover purpose I suppose.
dig www.cloudflare.com +short
198.41.215.162
198.41.214.162
Of course, pointing that domain to only one Cloudflare virtual IP is completely doable, although it is not desireable.
We have several servers on AWS VPC, but all have a 'public' face via DNS, handled with Route53. The problem is that when one server looks up the address of another server via DNS, if the entry is an 'A' record, it gets the public IP, not the AWS 'private' IP, and transfers go via the external network address.
If on the other hand I configure the domain as a CNAME pointing the the AWS public DNS name, like this:
CNAME super.domain.com ec2-1-2-3-4.compute-1.amazonaws.com
then lookups from 'outside' the VPC get the real external IP address, and lookups from 'inside' get the local 10.x.x.x address. This is exactly as I want it. Now the problem comes that these servers need to send mail, and pretty much everyone (mailgun, mandrill, etc.) requires SPF and DKIM records. But you can't mix those TXT records with a CNAME.
I know I could use /etc/hosts files on the servers to pre-empt the DNS lookup and use A records, but there are 14 servers and growing, and every time one of them is restarted, I'd have to update all the hosts files - seems like a recipe for messing things up.
My question is this: Is there a way to set up AWS Route53 so I can take advantage of the automatic internal/external resolution of the Amazon public DNS name, and still provide effective SPF and DKIM records? I did ask this on the AWS forum, but didn't get any help there...
Mailgun is probably closest, in that you can use a subdomain for the SPK/DKIM records (e.g. mg.super.domain.com), which then doesn't clash with the CNAME records. But then you hit this problem, the solution to which appears to be an A record, and I'm back to having to maintain many records when the instance IP addresses change!