Our Company local network is connected to a AWS VPC in VPN - see schema below :
view architecture here
Now, we want to configure DNS servers in order to use host name instead of Ip all over the network.
What is the best solution ?
Let Route53 handle DNS for the entire network (even the local one)
Have a DNS server on our local network, and Route53 on Amazon VPC. And if so, how to perform synchronization/replication between local DNS server and Route53 ?
Another solution :)
Thanks !
And have a nice day !
The problem with Route 53 is that it doesn't play with other DNS servers. It is a completely self contained solution. This means that if you used Route 53 your internal servers could only look up through the VNet into Route 53, you couldn't have a secondary Nameserver onsite that took a zone transfer from Route 53 (they don't support them)
You could potentially have caching nameservers internally, and have long expirely times on your host records, so if there was any problem the records wouldn't go stale but this brings its own set of problems.
This leaves you with a couple of solutions.
Use your internal network entirely, set up your internal name servers, internal.example.com and have a secondary name server located inside your Vnet that AWS clients can refer to. This way if there is a problem with the link, both sides still have working DNS.
Alternatively, you could configure internal.example.com in the same way, but then have aws.example.com running on Route 53. (or on a standalone server)
If Route 53 supported Zone Transfers and secondary servers it would be largely irrelevant what you went with but because they don't any solution you build is going to mean rolling some sort of glue to sit in between everything. This is invariably a Very Bad Thing™
We have the same architecture, network wise, and have not found a reasonable way to unify both networks' DNS data into one set of DNS servers.
Here is what works for us.
Assuming you want to use a corporate domain such as example.com, you can get a unified naming scheme where all hosts are under the example.com domain. This is done via Zone Delegation. In this document it states:
Domain Name System (DNS) provides the option of dividing up the
namespace into one or more zones, which can then be stored,
distributed, and replicated to other DNS servers. When you are
deciding whether to divide your DNS namespace to make additional
zones, consider the following reasons to use additional zones:
So in your case:
Use company network DNS for servers/devices on the local network. server1.example.com resolves to the IP# for the local network.
Delegate a subdomain such as 'corp' or 'cloud' to Route 53 for all hosts on AWS. Also known as a subzone, this gives full DNS responsibility to another name server. An instance in EC2 would be referenced as server1.cloud.example.com
This gives you a logical naming scheme, with IP resolution for all hosts on the network.
See Creating a Subdomain That Uses Amazon Route 53 as the DNS Service without Migrating the Parent Domain
There are some 3rd party solutions that add features onto Route 53, easyRoute53, and Route53d. Route53d claims for offer some sup[port for zone transfers (IXFR only).
Related
I am using a public API hosted behind CloudFront. I want to get the least possible latency.
I have done the following things so far:
Hosted my code on EC2 in the same region as the API origin server. (I have a clue as to which region the origin server could be hosted in based on ping times)
Tried pinging the API domain name from various availability zones within that region and identified the zone with least ping time.
However during my testing, I came across instances where ping time from my desktop was smaller than the ping time from my EC2 instance. So I had a look at what the CNAME & IP, the original API domain name was getting resolved to in each case. I found them to be different.
Is there something I can do to ensure that DNS resolution of CloudFront leads me to the lowest latency link.
I can use the CNAME or IP that I found to be the fastest during my testing. But that CNAME/IP may change so that's not a proper solution.
I think the answer could lie in a smart DNS client which pings all the servers in DNS file periodically and resolves DNS requests to the the fastest IP. However I don't know if any such client exists and how to use it if it does.
I would like to hear your ideas.
Is there something I can do to ensure that DNS resolution of CloudFront leads me to the lowest latency link.
If you have your own domain name, you could try using Route53's latency record or Geoproximity routing
Even though I have a private domain configured in route 53 resolver for a vpc, new instances still have default names like:
ip-10-1-1-170.ap-southeast-2.compute.internal
Is there a way to configure things such that new instances will automatically have an FQDN of the (sub)domain I have configured like:
ip-10-1-1-170.green.example.com
I am hoping to ensure that instances in seperate deployments (dev/green/blue) have FQDN's in seperate sub domains (and different VPCs), so that I can configure my onsite DNS to know where any host is based on that sub domain in its name, but automatically getting the host name on start is the first step on that journey.
I can successfully create route 53 records to achieve this too one by one, but it seems a bit nuts for a compute cluster, so I'm hoping that theres a way to achieve it just with the host name and the route53 resolver will still correctly handle DNS requests to those hosts somehow.
This domains are actually related to the domain controller that the instances are bound to.
When you create a VPC, the default DHCP configuration is amazons DNS (AmazonProvidedDNS) which in your case is providing the ap-southeast-2.compute.internal domain names.
If you added a custom DHCP option set of green.example.com then this would become part of that domain and show the DNS as you expect, although you are limited to one DHCP option set per VPC.
AWS have the following services which can act as domain controllers although you would need to ensure that your on premise can also forward requests to these name servers to resolve the domains:
Simple AD
Managed Microsoft AD
This is quite a bit of overhead in order to get the DNS names like those domains, it might be simpler by using 2 private hosted zones and automatings adding hosts to the domains along with an inbound endpoint instead from your on premise.
I am new to AWS Route53 and trying to brush up some of the basics. I have a question that might sound silly.
Lets say i have a public load balancer created with its DNS (AWS auto generated). Now i went ahead and got my corporate company to create a CName for the actual ELB A record, so say that CNAME is www.my-website.com.
Now when users start browsing www.my-website.com, their router DNS directly know where this public www.my-website.com is hosted and then once the DNS resolution happens, the request is directly forwarded to my ELB that has that CName to it.
Now all this is good but i would also like to play with Route53 here, so i go ahead and use Route53 to create a hosted zone and add my domain www.my-website.com under it and then create a record set with alias pointing to my actual ELB followed by rest of the configuration.
Now when someone hits www.my-website.com on their browser will the request directly go to the ELB or go to Route53 that will then route it to that ELB?
A summary of what these services provides is below:
Route 53 is a DNS Provider provided as a service by AWS. The functionality you're describing using is to store your DNS records within it for resolution.
An ELB is an appliance to distribute traffic across multiple nodes.
With your records in Route 53 the below journey takes place:
When a client in the browser attempts to go to www.example.com it will first check in its internal cache for any previously stored values for the domain, if theres a value it will be evaluated against a TTL to see if it has been expired.
If no value or expired the client will connect to the root domain, then the top level domain continuing until it finds the DNS provider for your domain (. -> .com. -> example.com..
Once it finds this DNS provider it will query for your domain, if it matches it will return the resolution value and the TTL.
If the value is that of a CNAME (such as an ELB) this process will begin again to resolves the IP address(es) for your hostname. This IP address will be cached by your local client.
If you're using Route 53 and an ELB one advantage would be to use Alias records they actually set your domain record to the IP address which improves the speed of DNS resolution.
So in summary Route 53 is only contacted if the client does not know the resolution value for your domain.
I am a newbie to AWS. I have read about DHCP Option Set and also about Route 53. However, I do not understand clearly about the similarities and differences between them.
In my understand, both help us customize DNS name, and DHCP is a component of VPC, but Route 53 is an AWS service, am I right? If yes, is there any differences between them? In which case we use DHCP? In which case we use Route 53 instead of DHCP Options?
Route 53 is a DNS service - this allows you to publish hostnames and their associated ip addresses to the world at large. For example, on a simple level, I might publish the following:
www.example.com A 123.45.67.89
This would tell internet users around the world that the server www.example.com can be found at ip address 123.45.67.89
This is hugely simplfied, but think of Route 53 as a part of a distributed, decentralised database of hostnames and ip addresses.
DHCP is used by a host to get its network configuration at startup. When a machine, or vps, or ec2 instance starts up, it will make a DHCP request for its network configuration, and a dhcp server will respond, giving the host a number of parameters, but at a minimum an IP address. The dhcp may then register this ip address/hostname combination in DNS. DHCP options are extra network configuration parameters, for example, telling the host that is part of the domain example.com, that its default router is 10.0.0.2, or any number of other options. These affect the way the host configures itself to talk to the network.
DHCP in your VPC is used to automatically assign domain names to your EC2 servers that are generated by Amazon. The domain names will look like ec2-public-ipv4-address.compute-1.amazonaws.com
Route53 is a DNS service for assigning custom domain names that you own to your AWS resources. If you wanted to assign someting like myapp.mydomain.com to your EC2 server, you wouldn't be able to accomplish that with DHCP, you would need to use a DNS service like Route53.
I'm working on transferring my website from godaddy, to AWS. I completed all the steps with the domain transfer, e.g. unlock domain, approve the transfer on both sides. And then I cancelled my Godaddy hosting. Now I have set up the AWS hosted zones, and I'm stuck on switching DNS services.
One of the steps is to enter the NS values on Route53 into the DNS provider on godaddy, but since I cancelled my hosting service I no longer have any way to access my DNS provider.
I'm wondering what to do in this situation. Is it possible to access the DNS provider directly? I waited for the TTL to expire before posting this because I thought that would fix my issues, but it did not.
If you transferred the domain registration to Route 53, you are following a set of instructions that doesn't match what you are trying to accomplish.
In Route 53...
Under "Hosted Zones," select your domain. Make a note of the 4 name servers assigned.
Then, under "Registered Domains," select your domain.
The name servers shown here need to match the 4 name servers that were assigned to your Hosted Zone.
Click Add/Edit Name Servers to modify them. They are probably still pointing to the Go Daddy (something like "nsxx.domaincontrol.com" if I remember correctly) name servers.
It sounds like what you were reading was instructions for moving your DNS hosting to Route 53, without doing a domain transfer, which is change of the registrar of record. Changing DNS hosting, only, would not have involved unlocking and approving as you described. Registrar and hosting are two completely separate services, but providers often bundle them together, leaving users often unaware of the distinction.