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.
Related
I am playing with hosted zone creation and domain name servers.
Everything I have has been created in AWS (the registered domain and the hosted zone).
I am not sure about DNS when I create a hosted zone.
1 - Do I copy the DNS records from the Route 53 hosted zone that I created for the domain and add them to the DNS list where it domain is registered (which is also in AWS under Route53/registered domains) .
or
2 - Do I copy the DNS records listed from the registered domains page and replace the DNS addresses that are into the route 53 domains hosted zone?
Does it matter? Can I do it either way and it is ok as long as they both match with the same DNS servers?
Eventually I am going to need to create hosted zones for subdomains in a different AWS account than what the domain and hosted zone is registered in and wondering what the best way to handle this would be.
AWS account A - This is where the domain is registered and where the domain has its hosted zone created. - Lets call the domain ernie.com (not the actual domain I am playing with)
AWS account B - This is where I want to created the hosted zone qa.ernie.com
Since we might also want to create more subdomains later on, it just seems easier to be able to get the list of the four DNS servers from the registered domain and use them every time we create a subdomain hosted zone. That would be instead of appending the DNS list of the registered domain with each subdomains DNS list - I assume that list could get pretty long then.
I have played a bit and no know matter which way I try it I am not seeing my domains DNS when I look at the domain with a dns look up website so I am wondering what might have happened there.
FYI - This will all be done with Terraform once I figure it all out - in case some has a great example for me to look at with Terraform IAC.
I currently have a GKE cluster and service set up at app.companyname.com. It lives in the prod GCP "project". I am now spinning up a dev project, and it's all good, except I don't know what to do with the domain name and certificate settings. I want the app available at dev.companyname.com
Do I have a public DNS zone per project, or should I have one, in the prod enviromment that dev accesses somehow? Do they share nameserver settings? Does the prod project forward to the dev project?
Do I have a separate SSL certificates, one per environment? Or one in prod environment that dev accesses.
What is the general overview on how this should be set up with GCP?
Essentially the question is about separation between Prod and Dev. Following this approach ("spinning up" a separate Dev project in GCP) you should stay consistent and separate public DNS as well. This will make projects scalable and align GCP service boundaries accordingly with the administration, trust, management and billing scopes managed by different teams.
Do I have a public DNS zone per project? - Broadly speaking, you should have a separate DNS zone per environment (but in the described case this means "per project"), in particular because SOA settings like REFRESH or TTL could be set different between Prod and Dev. Also, since each managed zone that you create is associated with a Google Cloud project, you can leverage IAM access control features to stick with the principle of least privilege in DNS zone management.
Do they share nameserver settings? - With a managed service such as Cloud DNS your projects will use name servers provided by vendor. You can find them in GCP Console or with gcloud:
$ gcloud config set core/project myworks-240610
Updated property [core/project].
$ gcloud dns managed-zones list
NAME DNS_NAME DESCRIPTION VISIBILITY
my-works myworks.example.com. public
$ gcloud dns managed-zones describe my-works --format="flattened(nameServers)"
nameServers[0]: ns-cloud-b1.googledomains.com.
nameServers[1]: ns-cloud-b2.googledomains.com.
nameServers[2]: ns-cloud-b3.googledomains.com.
nameServers[3]: ns-cloud-b4.googledomains.com.
$ dig ns-cloud-b1.googledomains.com +short
216.239.32.107
NS address is different for different projects (that way between Prod and Dev).
See Updating your domain's name servers
Do I have a separate SSL certificates, one per environment? - In different DNS zones hosts will have different CNs, so you will have separate certificates in Prod and Dev. You can use wildcard certificates to make things simpler, for example in Dev environment.
I am not familiar with the specifics of GKE, but I can speak to general domain system.
Answers:
There is one DNS record for companyname.com, the NS records are set for the overall domain. But there would be two A records, one for prod and one for dev. The A record points to the IP, so you can host them on any two servers, or the same one, or in a subdirectory of the other one, as long as Apache, or whatever serves the website, can match the full subdomain name to the directory in which the subdomain's files live
There are separate SSL certificates for each subdomain
Here is the example as the final DNS zone record to give you an idea of how to set your DNS settings:
; Name Servers
companyname.com. IN NS ns1.somehost.com.
companyname.com. IN NS ns2.somehost.com.
companyname.com. IN NS ns3.somehost.com.
; A records
# IN A XXX.XXX.XXX.XXX ; IP for the main companyname.com
prod IN A XXX.XXX.XXX.XXX ; IP for the app.companyname.com
dev IN A XXX.XXX.XXX.XXX ; IP for the dev.companyname.com
About URLs
A URL consists of protocol://Domain Name:port/path/file
https://prod.companyname.com:80/index.html
Protocol is just http or https
Domain name is what traverses the entire internet and the Domain Name Systems entire purpose is to map the domain name with the IP of the public facing server that holds that domain
Just the port and hidden by the browser to the user
The server then receives the request (something like Apache, or maybe GKE takes it from there) and maps the domain name to a root directory on the server, and then traverses down the path to the correct files to serve up to the requester
I know it is a lot to take in, but that is the root problem. I can't speak to GKE and someone else might jump in and explain out it might be configured to do what you are doing. But if you can get access to the DNS settings of the domain, and make a proper subdomain, this all gets a whole lot easier for you.
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.
Hopefully you all can help - we're looking to migrate our website from an EC2 instance to Webflow hosting. Unfortunately, we'd like to keep our API on the EC2 instance. Is it possible (in DNS in general, and specifically with route53) to have one DNS record for test.co and it's URL's (text.co/zxc, test.co/abc) and one DNS record specifically for the API URLs (test.co/api/abc)?
This would make the process much, much easier, as we wouldn't have to migrate the files to our EC2 instance and could keep the benefits of hosting on Webflow. However, performance is a key concern here for the API layer - my gut tells me that redirects are slow, and would add time to every API call. Not ideal.
Let me know what you think - cheers!
Using Route53 (or any DNS host) you can only resolve the hostname part (not the path) of the URL to your EC2 instance (E.g test.co, text.co) using either using.
CName mapping to the Domain Name assigned to the EC2 instance
A Record to the IP of the EC2 instance
Note: It is recommended to setup an Elastic IP for the EC2 instance if you directly map the EC2 instance to Route53.
You need to map /zxc /abc and /api/abc paths to relevant routes inside your EC2 instance either at WebServer level or using a proxy (E.g Nginx, Apache).
Is it possible (in DNS in general, and specifically with route53) to
have one DNS record for test.co and it's URL's (text.co/zxc,
test.co/abc) and one DNS record specifically for the API URLs
(test.co/api/abc)?
The best solution is to create a subdomain. api.test.com, then create an "A" record that point your api.test.com to your EC2 instance.
NJOY
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).