How do I test if my delegated subdomain resolves correctly?

6 minute read
0

I want to test and confirm if my delegated subdomain resolves correctly. If the subdomain doesn't resolve correctly, then I want to troubleshoot it.

Short description

You can configure a parent zone for your apex domain (such as example.com) using Amazon Route 53 or a third-party DNS provider. You can also use your DNS provider to set up a delegation set for the subdomain (such as www.example.com).

If you use a separate delegation set for your subdomain, then 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's delegated to a third-party DNS service

To verify if your subdomain resolves correctly and troubleshoot as needed, complete the following steps depending on your DNS provider and configuration.

Resolution

Note: The following commands apply only to Amazon Elastic Compute Cloud (Amazon EC2) Linux instances. If you use Amazon EC2 for Windows, you can use third-party web tools such as DiG GUI and Dig web interface for troubleshooting.

An apex domain and a subdomain that both use Route 53

1.    To check that your subdomain resolves correctly, run the dig command:

dig RECORD_TYPE DESIRED_SUBDOMAIN_RECORD

Note: Replace RECORD_TYPE and DESIRED_SUBDOMAIN_RECORD with your relevant details.

2.    In the output, verify that you have a record type of your choice under your subdomain’s hosted zone. In the following example output, there's an A record for www.example.com under the subdomain:

$ 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 lookup is successful against other DNS servers, then your local resolver might have caching issues. To bypass your local resolver, run the dig @ command with another resolver and your domain name. For example, the following 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

4.    If the DNS lookup fails, then use the dig +trace command:

dig +trace www.example.com

Then, review the output to identify where the lookup fails along the DNS chain. See the following example output for a dig +trace command:

$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

5.    Depending on the information in your output, follow the relevant troubleshoot steps.

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 the subdomain under the root domain is wrong. For example, an MX record is listed instead of an A record.

To fix this issue, create an NS record under your apex domain’s hosted zone for your subdomain with the correct name servers. Also, 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.

To fix this issue, 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 that's the wrong type for your delegated subdomain. For example, a TXT record exists instead of an A record for your subdomain under the subdomain’s hosted zone.

To fix this issue, 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 SERVFAIL status

The Route 53 name servers for your delegated subdomain under your apex domain’s hosted zone are incorrect in the NS record. 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.

To fix this issue, modify the NS record with the correct name servers for your subdomain’s hosted zone.

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

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

2.    If the name servers aren't properly configured, then look up the NS records for your subdomain’s hosted zone. Then, add those records to the apex domain’s hosted zone or zone file with the third-party DNS provider.

3.    To verify that the subdomain resolves correctly, use the dig @ command with one of the subdomain's hosted zone name servers:

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

Note: If the DNS resolution fails, then follow the methods in step 4 of An apex domain and a subdomain that both use Route 53.

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

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

2.    If the name servers aren't properly configured, then add NS records under the hosted zone for your apex domain in Route 53.

3.    To verify that the subdomain resolves correctly, use the dig @ command with your third-party DNS service's authoritative name server:

dig @THIRD_PARTY_NAME_SERVER www.example.com

Note: If the DNS resolution fails, then follow the methods in step 4 of An apex domain and a subdomain that both use Route 53.

Related information

How do I create a subdomain for my domain that's hosted in Route 53?

AWS OFFICIAL
AWS OFFICIALUpdated a year ago