0

Have a testing server where I have some stacks, a VPC (can get to interent, updates, etc) Now, I'm making a kubernete cluster with terraform and while deploying, couldn't resolve the new bought/registered domain at route 53 (I created the hosted zone and all).

My resolv.conf

cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
search ec2.internal
nameserver 10.0.0.2

nslookup result:

Server:         10.0.0.2
Address:        10.0.0.2#53

** server can't find myrandomdomain: NXDOMAIN

I have dns resolution/hostnames and dhcp options sets at my VPC, as well as private subnet for other servers in the same subnet (10.0.0.0/27) and an IG and public IP on the instace. First time I faced this issue.

Any ideas? Thanks.

Improve this question
6
  • You didn't seem to mention whether you had tested this same domain from outside the VPC, or whether other domains resolve correctly from inside. DNS in VPC still works, even with a variety of misconfigurations, because it is provided by the hypervisor, and thus immune to network ACLs, security groups, and even incorrect route tables.
    – Michael - sqlbot
    Jun 5, 2018 at 2:55
  • The hosted zone will be used as an option "--dnz-zone=" while creating the cluster with kops. I bought the domain at route 53 and then created a testing.mydomain.com as hosted zone (NS record). But when deploying, kops complains: error doing DNS lookup for NS records for "testing.mydomain.com": lookup testing.mydomain.com on 10.0.0.2:53: no such host Tries to resolve it through 10.0.0.2:53 (the hosted zone has aws name servers associateD) Thanks.
    – Rancor
    Jun 5, 2018 at 12:40
  • You are getting ahead of yourself, and you haven't answered my previous questions. Verify that the domain is resolvable from the Internet, and reporting the correct nameservers, as described by @qrkourier: dig example.com ns. The domain you registered, if you don't want to tell us the name, then please call it example.com for consistency. If that is what you registered, then the next question is this: are you using --dns-zone=example.com or --dns-zone=testing.example.com? If you created a hosted zone for testing.example.com and edited its assigned NS records, that is wrong.
    – Michael - sqlbot
    Jun 5, 2018 at 12:56
  • Sorry, It's not reachable from outside. I bought a random domain at route53 and created an additional hosted zone for testing.example.com , both hosted zones have aws nameservers like: ns-1877.awsdns-42.co.uk ns-701.awsdns-23.net ns-80.awsdns-10.com ns-1141.awsdns-14.org Didn't modify records. I'm watching a kubernetes course and they use it this way, setting testing.example.com at kops for --dns-zone but when trying to create the cluster, fails with the previously commented error.
    – Rancor
    Jun 5, 2018 at 14:15
  • Dig ns for testing.example.com only returns: ;; AUTHORITY SECTION: example.com. 60 IN SOA ns-1289.awsdns-33.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 No "answer section" as while digging at example.com, which returns aws' nameservers. Thank you!
    – Rancor
    Jun 5, 2018 at 14:20

1 Answer 1

Reset to default
1

TL;DR You need to delegate authority for the sub-zone in the parent zone.

To do this create an NS record in the parent zone that resolves to the value of the NS record in the sub-zone e.g.

ns-108.awsdns-13.com. ns-1006.awsdns-61.net. ns-1346.awsdns-40.org. ns-1875.awsdns-42.co.uk.

Troubleshooting context: Let's assume this has nothing to do with AWS, VPC attributes, or the local resolver configuration.

You might have to install dig with a command like sudo yum -y install bind-utils.

Pick one of the authoritative nameservers from the list e.g. dig +short -tNS example.com.

Query the picked nameserver for the anchor record e.g. dig +short example.com. @ns-290.awsdns-36.com.

This will tell you whether recursive resolvers elsewhere on the internet will eventually start answering requests for the same name.

If the query above for type=NS records of the zone do not show that authority has shifted to Route53, then either not enough time has passed or you haven't delegated authority to the NS recordset in your Route53 hosted zone at the registrar.

Improve this answer
2
  • digging at the domain I bought at route53 like example.com, returns aws nameservers, but then trying the same at testing.example.com, returns nothing. While deploying the cluster with kops, I set the "--dns-zone=" option as my subdomain (previously configured at route53 as hosted zone, NS record) but kops tries: error doing DNS lookup for NS records for "testing.mydomain.com": lookup testing.mydomain.com on 10.0.0.2:53: no such host Thanks
    – Rancor
    Jun 5, 2018 at 12:48
  • You need to delegate authority for the subordinate testing.example.com hosted zone in the parent namespace example.com. You need a total of two hosted zones to make this work with a subdomain. In Route53, create a hosted zone like example.com exactly matching the name you registered. Then paste the RDATA of the NS recordset from the subordinate hosted zone like testing.example.com in a recordset of type NS (nameserver) in that hosted zone. When this is done you'll be able to resolve the correct NSs of the sub-zone like dig +short -tNS testing.example.com.
    – qrKourier
    Jun 5, 2018 at 14:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .