Making changes to DNS looks easy, but in the end something almost always goes wrong. Worst of all it is never really clear what the problem is or how to fix it.

I've been waiting a long time for Route53 to propagate my DNS changes.

You've likely changed your NS records, switched providers, or hosted zones, but your www or apex domain still isn't resolving.

How long is a long time, I've found on average (assuming minimal TTL for records) that resolution will work in 3 minutes. That's right if it isn't working in 3 minutes, you did something wrong. Sorry to be the bearer of bad news. (This number isn't true for Indian DNS, I don't what it is about Indian DNS, but frequently it can take over 24 hours for an update to propagate).

Let's say it has been an hour and you are still waiting. Me at this point, I would have already been clicking a 100 different things, how you managed to wait a whole hour is medal worthy. You have the patience of virtue, congrats.

So what's wrong?

Let's check to see what dig says:

dig DOMAIN NS

What do you get back, if you get back 4 NS DNS values, great, if they match your hosted zone, even better.
Correct Response

;; ANSWER SECTION:
authress.io.        172800  IN  NS  ns-181.awsdns-22.com.
authress.io.        172800  IN  NS  ns-796.awsdns-35.net.
authress.io.        172800  IN  NS  ns-1141.awsdns-14.org.
authress.io.        172800  IN  NS  ns-1563.awsdns-03.co.uk.

But if you get this:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48896

Or this:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2693

Then you know your domain name configuration (NOT the hosted zone) is incorrectly configured.

Go back and copy your hosted zone NS values TO your Domain name configuration. FROM AWS Route53 TO Domain Configuration. (For some reason hosted zone providers let you change your NS, why is beyond me, and this is always wrong) Do Not Change your NS record values in your zone configuration. You are looking to change the property called Name Servers of your Domain Registration.

But they ARE the same already

The problem likely stems from the fact that you might have copied the wrong direction. Instead of updating your domain with the hosted zone data, you updated the hosted zone removing the correct NS values. As I mentioned above this could be the case. The simplest solution is delete the hosted zone and start over. But if you are intent on keeping it, you could try to recover the real NS values, using your Cloud Provider. For instance, with AWS Route53:

aws route53 get-hosted-zone --id ZONE

Will return:

DelegationSet: {
  NameServers: [
    "ns-2048.awsdns-64.com", 
    "ns-2049.awsdns-65.net", 
    "ns-2050.awsdns-66.org", 
    "ns-2051.awsdns-67.co.uk"
  ]
}

Set these values in both locations.

Subdomain issues

My production domain (domain.com) works but the subdomain (dev.domain.com) does not.

1. Create a hosted zone named dev.domain.com
2. Copy the NS records from that new hosted zone
3. Go to the production hosted zone (named: domain.com)
4. Create an NS record:

Name: "dev.domain.com"
Type: "NS"
Value: "NS Values from Sub Hosted Zone"

Issue with resolving with 1.1.1.1

Sometimes the issue is just that not all DNS are resolving correctly. If dig domain NS @8.8.8.8 works, but dig domain NS @1.1.1.1 does not and you get this following error:

; EDE: 22 (No Reachable Authority): (at delegation domain.com.)
; EDE: 23 (Network Error): (216.239.32.107:53 rcode=REFUSED for domain.com NS)

You can likely fix it by going to https://1.1.1.1/purge-cache/.

Extending this to Certificates

Even once your domain works, certificates using DNS validation might still not work correctly. Certificates get validated using DNS records, these records need to be configured correctly in a hosted zone that works.

If we followed the steps above then we have a working hosted zone, now we need to make sure the correct validation records are added.

The first step is to validate that the records are working. To do this we can run dig VALIDATION_RECORD CNAME. By doing so we should get back the related CNAME value. If we don't get back the value then that means either record doesn't exist or the hosted zone isn't correctly configured.

One small note here, is that for every additional part of the domain we have, there could be a different hosted zone being used. Make sure that dig SUBDOMAIN NS matches the NS records of your hosted zone you are using. If the don't match then you aren't looking at the correct subdomain hosted zone.

In the case that you have the domain part-1.part-2.company.com there could three different hosted zones:

• One for company.com
• One for part-2.company.com
• One for part-1.part-2.company.com

Creating Certificates for the part-1 subdomain could mean needing to validate that all three hosted zones are configured correctly.

Note: if you only have one hosted zone, then you don't need to do this, BUT, if you have three hosted zones and:

• part-1.part-2.company.com is configured as a NS in the part-2.company.com hosted zone (that is there is a NS with the record name part-1.part-2.company.com in the part-2.company.com hosted zone)
• and part-2.company.com is configured as a NS in the company.com hosted zone (that is there is a NS with the record name part-2.company.com in the company.com hosted zone)

That means you need to validate all of these. Consequentially, validating that dig CERTIFICATE_DOMAIN CNAME works will validate all of them. But if one of them doesn't work, then you'll need ot deep dive.

Come join our Community and discuss this and other security related topics!