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.
Related
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 have the following scenario:
I own the following domain: example.com, which has A record for it: job.example.com/8.8.8.8.
I have purchased an Elastic IP address, and I have changed the A record IP for job.example.com from 8.8.8.8 to AWS Elastic IP address.
What I want to achieve is to hide my "real" office IP. I want when someone visits https://jobs.example.com the IP address behind it will be the Elastic IP address, but some service in Amazon will forward all traffic to my real office IP (8.8.8.8 for example in this question).
I've looked into route53, couldn't find anything.
Please help :)
I might get your question wrong but it seems what you're asking for is a reverse proxy, or more likely in AWS, a CloudFront CDN distribution.
Considering CloudFront pricing, I'd go for that one.
The reverse proxy option would be to setup an EC2 instance with, for example, the nginx server configured like this:
location / {
proxy_pass http://8.8.8.8/;
}
Depending on your traffic, the later solution could be achieved with a free-tier t2.micro instance, which you will begin to be billed for next year.
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).
We have a domain mydomain.com, which we have registered with a UK registrar. We are using Amazon's Route53, and this domain has been added in Route53 and is using the name servers as follows;
ns-558.awsdns-05.net
ns-1755.awsdns-27.co.uk
ns-466.awsdns-58.com
ns-1343.awsdns-39.org
I've added the relevant A records for www etc to point our elastic IP to this domain.
We are also running MailEnable on this EC2 server (running Windows 2012). The MailEnable server is asking for me to enter DNS addresses (Check and configure DNS settings), I assume it will use when sending email.
My question is what DNS addresses / servers can I use ? Can I use
ns-558.awsdns-05.net
ns-1755.awsdns-27.co.uk
ns-466.awsdns-58.com
ns-1343.awsdns-39.org
You can see the DNS address(es) in the screen shot below.
You can't use those Amazon servers because they're authoritative-only (they'll only tell you about domains they know about, instead of acting as a recursive proxy). You can use Google's public DNS servers at 8.8.8.8 and 8.8.4.4 for that field.
(original answer below)
You need to create an A record that points at the elastic IP assigned to your mail server (for example, mail.yoursite.com points at 1.2.3.4). Then, you'd create an MX record for yoursite.com that points at mail.yoursite.com. Finally, I believe you would give MailEnable mail.yoursite.com, but I'm not 100% sure on that.
It is my first time with Amazon Route 53 and with a Registrar.
I can create an Amazon Route 53 Hosted Zone, and associate the delegate set in my Domain Registrar. It is also my first experience developing a JavaEE app.
I do have a running Amazon Elastic Load Balancer. I do have a server app accessed at a DNS address like https://:88888/my-app.
Please, could anyone clarify if (and how) it would be possible to have my domain address (www.my-domain.com.au) redirected to https://:88888/my-app ?
BR,
Rafael
There's a few problems with that:
First, DNS cannot include port numbers.
Second, DNS cannot include a path.
Third, the maximum port number is 65535, so even if DNS did let you add a port number, that port number is too high.
You'll probably want to just send your domain directly to the server. Use apache to reverse proxy 80/443 to 8080/8009 (glassfish default ports for http/ajp), and just add a mod_rewrite rule that redirects / to /my-app.