We are currently in the process of migrating from one host to the google cloud platform.
But there is one thing that is causing us confusion. We have various clients who have setup custom domains with us. Many of them have done so by updating their nameservers to the following:
ns1.mydomain.com
ns2.mydomain.com
ns3.mydomain.com
However, when we add domain zones to gcloud each domain seems to get assigned different NS records at random.
Some get assigned the following
ns-cloud-a1.googledomains.com, ns-cloud-a2., ns-cloud-a3.
While others get
ns-cloud-b1., ns-cloud-c1., ns-cloud-d1.* etc.
How can we make the current custom domains continue to work after we migrate? We have several hundred custom domains set up and we would like to migrate to gcloud without any changes required from our clients.
Our original plan for the migration was:
Add zones for mydomain.com to google cloud DNS and take note of NS records
Add zones to cloud DNS for all of our client custom domains
Update our nsX.mydomain.com nameservers to point to the IP address of the NS records for mydomain.com
All existing custom domains should continue to work regardless of their NS records (in theory)
However, I'm not sure if that is the correct way to proceed.
Some things I'm particularly confused about:
Do we need to set the NS records for the custom domains in gcloud to our nsX.mydomain.com servers? We don't currently specify any NS records for these domains in cPanel.
Does it matter which name servers the custom domains are assigned to in gcloud? (ns-cloud-a1 for some vs ns-cloud-b1 for others)
Would we expect any sort of downtime for this DNS transfer?
Any assistance with this would be greatly appreciated. Thanks.
I was able to get this to work by adding multiple A records for each of the name servers
So for ns1.mydomain.com I added A records for 216.239.32.106, 216.239.32.107, 216.239.32.108, 216.239.32.109, 216.239.32.110.
Those are the ips of ns-cloud-a1., ns-cloud-b1., ns-cloud-c1. etc. which you can find by running this command for each of the nameservers
host ns-cloud-a1.googledomains.com
I did the same for ns2. and ns3., adding A records for the second and third nameservers in each shard (i.e. ns-cloud-a2., ns-cloud-b2. and ns-cloud-a3., ns-cloud-b3.)
This is how the A records appear in the google cloud DNS dashboard
Cloud DNS assigns every public managed zone to one of five nameserver shards. Shards are the letter before the number in an authoritative nameserver name, so ns-cloud-e1 through ns-cloud-e4 are the E shard.
Multiple zones with the same DNS name cannot be assigned to the same shard, so only five zones can be created with exactly the same DNS name. For more information, please refer to Nameserver limits.
For example, you’ve zone1 for mydomain.com and NS as ns-cloud-bX.googledomains.com., but when you create a zone with the same domain name, you’ll get ns-cloud-eX.googledomains.com.
For your scenario:
Create managed Zone.
Copy the list of NS accordingly and update # Domain Registrar. These NS records will resolve queries for mydomain.com.
Only the DNS name servers pointed by the DNS registrar will resolve the requests which matter. However, subdomains that are delegated by creating NS (name server) records in their parent domain's zone need to have their own zones as well.
Your time to live (TTL) set on the records at the registrar will tell you how long you have to wait before the new name servers begin to be used.
Related
I am having trouble generating a HTTPS certificate from the AWS Certificate Manager, which is stuck in Pending Validation for more than 24 hours. I found this tutorial by AWS that gives some potential clues on how to solve the problem: https://www.youtube.com/watch?v=MBGo8m6UET8
One of the steps suggests running dig on the domain and comparing against the name servers in my hosted zone. When I run dig NS <my_domain> I get:
;; ANSWER SECTION:
<my_domain>. 0 IN NS ns-1144.awsdns-15.org.
<my_domain>. 0 IN NS ns-68.awsdns-08.com.
<my_domain>. 0 IN NS ns-1885.awsdns-43.co.uk.
<my_domain>. 0 IN NS ns-718.awsdns-25.net.
In my Route53 I have a hosted zone for <my_domain> with a NS record, which was created automatically, that points to:
ns-1309.awsdns-35.org.
ns-381.awsdns-47.com.
ns-1859.awsdns-40.co.uk.
ns-722.awsdns-26.net.
As far as I understood the name servers should match in both places, so I don't know why they don't. Should I be concerned? How should I fix this?
EDIT: I found the fix to my problem. The name servers that appear on the Hosted Zone:
need to be set as name servers on the domain here:
The values returned by dig are taken direct from DNS. As the NS (name server) records dont match your zone in Route53, that isnt the zone hosting your domain. There is a Route53 zone setup somewhere in AWS that hosts <my_domain> but thats not it. Do you have multiple zones in Route53, or multiple accounts perhaps - maybe your using the wrong one? Otherwise look to anyone previously involved with <my_domain>'s hosting - its probably in their aws account.
Yes you should be concerned, you do not have access to your own DNS, and some other account owns that zone in Route53. You need to resolve this issue to use domain validation in ACM or otherwise make changes to <my_domain>.
The NS values seen in dig come from the company you registered the domain name (the "registrar") - they will have a web portal. Somewhere in there will be an option for "custom name servers" or similar for your domain. They will currently be set to the values seen in dig. You need to set those to your Route53 zones name servers instead if you want to manage the DNS for the domain with that Route53 zone.
WARNING - changing name servers will effectively remove all DNS records provided by the current Route53 zone that dont already exist in your Route53 zone (once the TTL expires). This could break stuff - websites, email, 3rd party integrations etc. You should ideally get the current owner to export the zone file and then you can import it to avoid loosing any records.
If thats not possible and depending on how complicated <my_domain> is you might be able to dig DNS and retrieve enough info to setup your own route53. You need to ensure all A, CNAME, TXT, MX, etc records that exist in dns exist in your zone for the apex (<my_domain>) and any subdomains (eg www.<my_domain>). This approach is very risky and probably wont get all the records - this could break anything related to <my_domain> or any of its subdomains. This is a last resort, not a good idea ;-)
Per this earlier post, I was able to verify a domain of ours (which is in Route 53) to use as a custom domain with GCPs Cloud Run. However, we are struggling to update the DNS records for this domain now.
Our domain mydomain.com was previously used with an AWS EC2 instance. Our hosted zone in Route 53 for this domain currently has 8 records, of various record types (A, MX, NS, SOA, TXT, CNAME). Before uploading the 8 DNS records for cloud run (GCP gave us 4 A DNS records with ip addresses, and 4 AAAA DNS records with ip addresses, to upload), should I first delete all of the previous records in the hosted zone for this domain? I presume these earlier records are associated with our previous use of the domain with the ec2 instance.
Is it safe to delete all of the previous records from the hosted zone? Or maybe it is better to create a new hosted zone to use with GCP cloud run, and keep this initial hosted zone to remain with the EC2 instance? I am not sure if it is possible to have 2 hosted zones for 1 domain, or not. If only 1 zone is possible, I am not sure if i should delete + re-create a new hosted zone to use with Cloud Run, or try to edit my initial hosted zone (by deleting the old DNS records). I just need to move this custom domain from the EC2 instance to the cloud run app.
Thanks!
EDIT BEFORE BOUNTY: here are the DNS records that Cloud Run is telling me to add to my domain host (true values and domain name changed):
... and here is my Hosted Zone for the domain:
...the top 2 records are the new A and AAAA records that Cloud Run has given me (there was previously 2 A records that I deleted). When trying to create the A records, I actually received an error when I tried to create 4 separate A records, so I've put all 4 IP addresses into a single A record (not sure if this is correct).
Unfortunately, in the GCP /run/domains page, I am still receiving this error / warning message:
I do not plan to use the old AWS EC2 instance with this domain again, so perhaps I should delete all of the old DNS records that are associated with it? However I am not sure which records are safe to remove and which are not... Perhaps creating a new hosted zone is best (as suggested in an answer below)? Currently I am going the route of simply editing my old hosted zone (as was suggested in the comment below).
We have been struggling with this for most of the weekend and could really use some advice on getting this domain off of the EC2 instance and onto the cloud run deployment.
Edit2: I did just update the hosted zone with the cloud run DNS records a few minutes ago, so perhaps I just need to give it time? Again, I am not sure at all...
I will point out two most obvious ways and their pros/cons.
1. Safest way
You can create a new managed zone (GCP's equivalent to AWS hosted zones), create all the needed records for your cloud run app in GCP. Then change at your domain registrar DNS servers that you got from GCP (probably something like ns-cloud-a1.googledomains.com).
This way you will have full working copy (with setting to accomodate GCP's Cloud run) and in case you wanted to go back to AWS quickly you just need to point to AWS DNS servers at your domain registrar.
Cons of this solution are that you will have to pay a little bit more because you will be effectively hosting your domain at two providers (but only GCP will be actively used).
2. Easy way.
Create new managed zone at GCP, point your domain to GCP's DNS servers and delete hosted zone at AWS.
You can also backup your hosted zone in AWS - you can have a look at this blog post how to do it.
In my opinion if you ever plan to go back (or have a backup) of your domain records setup for AWS then first approach is the one to go for. Additional cost is also negligible.
UPDATE
Any changes made in DNS settings (adding & removing records, modyfying) requite usually up to 24 hours to propagate across the Internet.
Even more about DNS records and how to manage them.
If you want to add multiple A records to your managed zone edit your zone, click on "add record set" button, next select A record type (or AAA for IPv6 and type in the address first value, next click "add item" button below and type another etc.
If you prefer to do it using gcloud the here's some documentation how to add records to your zone (domain).
I am new to AWS and facing this issue for the past few days. So any help will be appreciated :)
I have created an AWS EC2 instance and deployed backend&frontend services on SINGLE INSTANCE that are used in my project.
Backend->Java,Apache tomcat,RDS,Elasti cache
Frontend-> Node
And now created a hosted zone under Route53 to host my Namecheap domain in AWS EC2.
Have checked all configs thrice, and added A type(Value as ec2 IP) and CNAME(Value as domain name e.g. xxyyzz.liv) type variables in the hosted zone including modifying nameservers from hosted zone to the Namecheap DNS settings.
Even after long waiting(of 48 hrs) my domain is not getting live, tried multiple times but no help.
This will be caused by misconfiguration. Perform the following steps to rectify this issue:
Ensure you have not replaced the NS or SOA records in Route 53, these should stay as the values that Route 53 generates. If you have replaced their values, create a new public hosted zone and migrate the records to this (excluding NS or SOA).
Run DIG against your domain for the MX record, either by running DIG NS example.com or by using an online tool such as https://toolbox.googleapps.com/apps/dig/. If you get no results back (returning a SERVFAIL) or incorrect name servers back then you will need to update the name server configuration.
Within your public hosted zone in Route 53 look for the NS record, copy the values (there will be 4 nameservers). Then within namecheap follow these instructions for "Custom DNS". Add each name server from Route 53.
By now running DIG again you should be able to see the records that should have previously been accessible. Depending on the TTL of the previous NS record you might find it takes a few hours/days for the DNS to migrate across, although you can clear the DNS cache on your local network.
We are migrating to AWS, and so far we are quite pleased with the performance and ease of use the AWS console provides, especially the Route53 UX. However we ran into an issue.
We have 3 subnets (datacenters), and our old DNS provider we had it set-up like this:
example.us
www
sn1.example.us (local datacenter)
gateway (CNAME)
demo1
feature1
sn2.example.us (old datacenter)
gateway (A record for static ip)
app-a-1
service-a-1
sn3.example.us (aws vpc)
gateway (A record for elastic ip)
app-a-1
service-a-1
So when we migrated to Route53, I maintained the same structure, in that I created a separate "hosted zone" for each subdomain, as it makes each zone easier to administer.
The problem I am seeing is that gateway.sn1 and gateway.sn3 are not resolving, however gateway.sn2 is resolving. With respect to Route53, is it ok to maintain this structure, or should I just have one hosted zone for example.us, and put everything in there?
Update #1
When I created each separate zone, they each were defaulted to differing nameserver records, so I went in and updated all the other zones NS records to match sn2.example.us (as it was the only one working).
Update #2
Bad idea trying to share nameservers across the various hosted zones, when testing behavior, I was getting REFUSED responses. So it does look like I have to move all entries from subdomains (in other hosted zones) up into the parent zone, so I can use the parent's zone nameservers when updating registrar's nameserver information for the domain example.us
You can definitely do this in Route 53... just not the specific way you tried to do it.
Create 4 hosted zones, example.com, sn1.example.com, sn2.example.com, and sn3.example.com.
Don't change the NS entries. You can't. (You technically can, but it doesn't work, if you try.)
Give the assigned nameservers for example.com to the registrar.
Then, in the example.com hosted zone, create one NS entry with hostname sn1, and paste the 4 automatically assigned nameservers for sn1 (as assigned by Route 53 to the hosted zone for sn1.example.com) in the box. Repeat the process for sn2 and sn3 using the correct NS records originally assigned by Route 53 in each case.
The way you tried to implement this can't work, because changing the NS in a hosted zone doesn't change which actual Route 53 servers will respond to requests. That can't be changed.
I'm using Route 53 for most of my website DNS needs but I have a question I couldn't find a clear answer for on Amazon's (usually very good) support docs.
It states everywhere in support not to change or remove the ns records for a hosted zone. But can I add ns records for a subdomain?
I'm migrating a site to Route 53 that requires ns records to point to a 3rd party for email. The current DNS set up is as follows:
When I come to move the parent domain to Route 53 can I add those records into the parent domain hosted zone as below or would I need to create a new hosted zone just for the sub-domain?
You can change the NS record in Route53 to add other DNS servers in the list or remove existing ones, but this is only required in very specific setups.
From your description, it seems you're simply trying to migrate the existing DNS settings from another provider to Route53. If this is the case, then you'll probably be using the AWS provided name servers exclusively for your domain, so the NS value that you have in Route53 is already what it should be and there's no need to change it.
The only reason why you would change the NS value is if you use other DNS servers (secondary DNS servers), separate from the ones Amazon has assigned to your hosted zone (possibly for redundancy, but the ones that Amazon provides already offer enough redundancy).
UPDATE (based on comments below):
If the subdomain user other name servers (it's delegated), then you'll need to create a new NS record in the hosted zone for that subdomain:
email.primary-domain.com. IN NS other-ns.dns-provider.com.
In this case, you'll need to leave the NS record for the root domain unchanged.