How do I test if my delegated subdomain resolves correctly?
"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."
"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 descriptionYou 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 53An apex domain that uses a third-party DNS service and a subdomain that uses Route 53An apex domain that uses Route 53 and a subdomain that's delegated to a third-party DNS serviceTo verify if your subdomain resolves correctly and troubleshoot as needed, complete the following steps depending on your DNS provider and configuration.ResolutionNote: 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 531.    To check that your subdomain resolves correctly, run the dig command:dig RECORD_TYPE DESIRED_SUBDOMAIN_RECORDNote: 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.13.    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.comPerform the lookup directly against one of the authoritative AWS name servers for the apex domain’s hosted zone:dig @ns-***.awsdns-**.com www.example.com4.    If the DNS lookup fails, then use the dig +trace command:dig +trace www.example.comThen, 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 mscom.                            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 mswww.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 mswww.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 864005.    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 serversThe 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 serversThe 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 sectionThe 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 statusThe 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 531.    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.comNote: 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 party1.    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.comNote: 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 informationHow do I create a subdomain for my domain that's hosted in Route 53?Follow"