How do I test and confirm if the delegated subdomain is resolving correctly? If it's not resolving, how do I troubleshoot and fix it?

When you have a parent zone for your apex domain (such as example.com) configured with Amazon Route 53 or a third-party DNS provider, you can set up a delegation set for a subdomain (such as www.example.com) with Route 53 or a third-party DNS provider.

If you use a separate delegation set for your subdomain, you can have the following configurations:

  • An apex domain and a subdomain that both use Route 53
  • An apex domain that uses a third-party DNS service and a subdomain that uses Route 53
  • An apex domain that uses Route 53 and a subdomain that is delegated to a third-party DNS service

Follow the resolution for your configuration.

An apex domain and a subdomain that both use Route 53

1.    Use the command dig +trace to check that your subdomain resolves correctly.

2.    Be sure that you have a record type of your choice under your subdomain’s hosted zone. For this test case, there is an A record for www.example.com under the subdomain's zone. Note the output for dig against the desired record type:

dig <record type> <desired subdomain record>

Example output:

$ dig www.example.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48170
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.example.com.                IN         A
;; ANSWER SECTION:
www.example.com.     60          IN         A          127.0.0.1

3.    If the DNS lookup fails, then use the dig and dig +trace outputs to identify where the lookup fails along the DNS chain.

Example output:

$dig +trace www.example.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.56.amzn1 <<>> +trace www.example.com
;; global options: +cmd
.                                   518400 IN         NS        G.ROOT-SERVERS.NET.
.....
.                                   518400 IN         NS        F.ROOT-SERVERS.NET.
;; Received 228 bytes from 169.xxx.xxx.xxx#53(169.xxx.xxx.xxx) in 21 ms
com.                            172800 IN         NS        c.gtld-servers.net.
.....
com.                            172800 IN         NS        i.gtld-servers.net.
;; Received 498 bytes from 199.xxx.xxx.xxx #53(199.xxx.xxx.xxx) in 198 ms
.example.com.   172800          IN         NS        ns-xxx.awsdns-xx.com.
.example.com.   172800          IN         NS        ns-xxx.awsdns-xx.net.
.example.com.   172800          IN         NS        ns-xxx.awsdns-xx.co.uk.
.example.com.   172800          IN         NS        ns-xxx.awsdns-xx.org.
;; Received 207 bytes from 192.xxx.xxx.xxx #53(192.xxx.xxx.xxx) in 498 ms
www.example.com.     172800 IN         NS        ns-xxx.awsdns-xx.com.
www.example.com.     172800 IN         NS        ns-xxx.awsdns-xx.net.
www.example.com.     172800 IN         NS        ns-xxx.awsdns-xx.co.uk.
www.example.com.     172800 IN         NS        ns-xxx.awsdns-xx.org.
;; Received 175 bytes from 205.xxx.xxx.xxx #53(205.xxx.xxx.xxx) in 345 ms
www.example.com.     900      IN         SOA      ns-xxx.awsdns-xx.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig www.example.com.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22072
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
www.example.com.com.          IN         A
;; AUTHORITY SECTION:
www.example.com.com. 60       IN         SOA      ns-xxx.awsdns-xx.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

4.    Review the output to identify a reason for the failure:

dig returns a NOERROR status with no ANSWER section, and the dig +trace output only includes the apex domain’s name servers:

The NS record for your delegated subdomain is missing from the hosted zoned of your apex domain. Also, the record type (for example, an MX record instead of an A record) for the subdomain under the root domain is wrong. Create an NS record under your apex domain’s hosted zone for your subdomain with the correct name servers.

Remove the non-NS record for the subdomain under the apex domain’s hosted zone. Then, place the non-NS record under the subdomain’s hosted zone.

dig returns NXDOMAIN status and dig +trace output only includes apex domain’s name servers:

The NS record for your delegated subdomain is missing under your apex domain’s hosted zone.

Create an NS record under your apex domain’s hosted zone with the correct name servers.

dig +trace returns your name servers for the delegated subdomain, but dig returns NOERROR status with no ANSWER section:

The hosted zone contains a record of the wrong type for your delegated subdomain. There is a TXT record that exists instead of an A record for your subdomain under the subdomain’s hosted zone.

Create a new A record for the delegated subdomain under the subdomain’s hosted zone.

dig +trace returns name servers for the delegated subdomain but dig returns the error “connection timed out; no servers could be reached”:

The Route 53 name servers in the NS record for your delegated subdomain under your apex domain’s hosted zone are incorrect. Confirm this problem with a DNS lookup against one of the delegated subdomain’s name servers using the dig @ command. An incorrect name server returns a REFUSED status.

Modify the NS record with the correct name servers for your subdomain’s hosted zone.

5.    If the lookup is successful against other DNS servers, your local resolver might have caching issues.

Use the dig @ command with another resolver and your domain name to bypass your local resolver. For example, this lookup uses Google’s public resolver:

dig @8.8.8.8 www.example.com 

Perform the lookup directly against one of the authoritative AWS name servers for the apex domain’s hosted zone:

dig @ns-***.awsdns-**.com www.example.com

An apex domain that uses a third-party DNS service and a subdomain that uses Route 53

1.    Confirm if the name servers for the subdomain are properly configured in the parent zone.

2.    If not, look up the NS records for your subdomain’s hosted zone, and then add them to the apex domain’s hosted zone or zone file with the third-party DNS provider.

3.    Use dig @ to be sure that the subdomain resolves using one of its hosted zone name servers:

dig @ns-***.awsdns-**.com www.example.com

Note: If the DNS resolution is failing, refer to the Troubleshooting DNS lookup failure section to identify and fix the reason for failure.

An apex domain that uses Route 53 and a subdomain that is delegated to a third party

1.    Confirm if the name servers for the subdomain are properly configured in the parent zone.

2.    If not, add NS records under the hosted zone for your apex domain in Route 53

3.    Use dig @ with your third-party DNS service's authoritative name server to be sure that your subdomain resolves correctly:

dig @<Third party Name Server assigned for www.example.com> www.example.com

Note: If the DNS resolution is failing, refer to the Troubleshooting DNS lookup failure section to identify and fix the reason for failure.


Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center

Published: 2018-08-31