Delegating sub domains to AWS R53

rajasuperman · 2017-11-15 13:06:29 UTC

Hello,

I have my root domain (rsubr.in) hosted with CloudFlare and working great.

I have a private subdomain (int.rsubr.in) in AWS VPC Route53. This is not public and visible only within the VPC.

In CloudFlare I want to delegate int.rsubr.in to the internal Route53 resolver so users can lookup internal hosts even when they are using public DNS servers.

This is necessary as some VPN clients who connect to the VPC do not get correct DNS settings and end up using public 8.8.8.8 DNS. int.rsub.in name resolution fails and users are unable to access VPC hosts via VPN.

My plan is to configure CloudFlare to delegate int.rsubr.in to the internal Route53 resolver IP (172.31.0.2), then VPN users can resolve internal hosts regardless of the DNS they are using.

I followed the steps described here: https://malware.expert/howto/delegate-subdomain-cloudflare-to-other-dns-servers/ but I’m unable to get it working.

In CloudFlare for rsubr.in, I have created these 2 records:

A record for nsint.example.com with value 172.31.0.2 (glue)
NS record for int.example.com pointing to nsint.example.com

AWS Route53 setup:

[email protected]:~$ dig -t ns rsubr.in

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t ns rsubr.in
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62841
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;rsubr.in.                      IN      NS

;; ANSWER SECTION:
rsubr.in.               21599   IN      NS      art.ns.cloudflare.com.
rsubr.in.               21599   IN      NS      vera.ns.cloudflare.com.

;; Query time: 419 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Nov 15 18:30:57 DST 2017
;; MSG SIZE  rcvd: 91

[email protected]:~$ dig -t ns int.rsubr.in

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t ns int.rsubr.in
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1972
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;int.rsubr.in.                  IN      NS

;; Query time: 74 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Nov 15 18:31:02 DST 2017
;; MSG SIZE  rcvd: 41

I am also unable to resolve any A records (*.int.rsubr.in) in my subdomain.

Any help is much appreciated!

cscharff · 2017-11-15 16:21:33 UTC

Are you connected to your VPN when you do this query? If you query ‘dig foo.int.rsubr.in @172.31.0.2’ do you receive an answer from the NS that is supposed to be the delegate for the subdomain?

dig int.rsubr.in ns +trace times out (obviously) trying to communicate with the nameserver running in your private address space (my assumption is this would succeed if I were o the private network).

In looking at your AWS setup, does one of the ns-.awsdns-00. servers correspond to that same 172. address you’ve specified in the delegation? (You said it does I think, just confirming).

rajasuperman · 2017-11-15 17:11:43 UTC

To rule out any VPN issues, I am testing dig/DNS from a host within the VPC.

Within the VPC, everything works fine when I resolve via 172.31.0.2.

[email protected]:~$ dig gromit.int.rsubr.in @172.31.0.2

; <<>> DiG 9.10.3-P4-Ubuntu <<>> gromit.int.rsubr.in @172.31.0.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46629
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gromit.int.rsubr.in.           IN      A

;; ANSWER SECTION:
gromit.int.rsubr.in.    60      IN      CNAME   ip-172-31-17-139.ec2.internal.
ip-172-31-17-139.ec2.internal. 20 IN    A       172.31.17.139

;; Query time: 3 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Wed Nov 15 16:55:42 UTC 2017
;; MSG SIZE  rcvd: 107

When I query external DNS, it is broken:

[email protected]:~$ dig gromit.int.rsubr.in @art.ns.cloudflare.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> gromit.int.rsubr.in @art.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60360
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gromit.int.rsubr.in.           IN      A

;; AUTHORITY SECTION:
int.rsubr.in.           300     IN      NS      nsint.rsubr.in.

;; ADDITIONAL SECTION:
nsint.rsubr.in.         300     IN      A       172.31.0.2

;; Query time: 4 msec
;; SERVER: 173.245.59.102#53(173.245.59.102)
;; WHEN: Wed Nov 15 16:57:27 UTC 2017
;; MSG SIZE  rcvd: 84

When I run dig +trace from withing the AWS VPC, I get a BAD REFERRAL response in the end. Lengthy dig output edited for clarity:

[email protected]:~$ dig  int.rsubr.in +trace @172.31.0.2

; <<>> DiG 9.10.3-P4-Ubuntu <<>> int.rsubr.in +trace
;; global options: +cmd
.                       518400  IN      NS      G.ROOT-SERVERS.NET.
...
.                       518400  IN      NS      F.ROOT-SERVERS.NET.
;; Received 239 bytes from 172.31.0.2#53(172.31.0.2) in 0 ms

in.                     172800  IN      NS      c0.in.afilias-nst.info.
...
;; Received 891 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 1 ms

rsubr.in.               86400   IN      NS      art.ns.cloudflare.com.
rsubr.in.               86400   IN      NS      vera.ns.cloudflare.com.
...
;; Received 586 bytes from 199.249.117.1#53(a2.in.afilias-nst.info) in 1 ms

int.rsubr.in.           300     IN      NS      nsint.rsubr.in.
;; Received 77 bytes from 173.245.59.102#53(art.ns.cloudflare.com) in 2 ms

.                       518400  IN      NS      L.ROOT-SERVERS.NET.
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
;; BAD REFERRAL
;; Received 824 bytes from 172.31.0.2#53(nsint.rsubr.in) in 0 ms

I’m unable to fully understand how AWS Route53 works in this case. In my VPC 172.31.0.2 is the NS I’m using in my servers. It does full recursion and I can resolve any domain.

ns-aws-00 all point to public IPs.

[email protected]:~$ host ns-0.awsdns-00.com
ns-0.awsdns-00.com has address 205.251.192.0

[email protected]:~$ dig int.rsubr.in @ns-0.awsdns-00.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> int.rsubr.in @ns-0.awsdns-00.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18779
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;int.rsubr.in.                  IN      A

;; Query time: 12 msec
;; SERVER: 205.251.192.0#53(205.251.192.0)
;; WHEN: Wed Nov 15 17:06:05 UTC 2017
;; MSG SIZE  rcvd: 30

All ns-.awsdns-00 servers give me the same response (status: REFUSED).

In CloudFlare I also tried delegating to ns-.awsdns-00, but that also got me nowhere.

Thanks again for your help.

rajasuperman · 2017-11-15 17:57:05 UTC

To answer my own question and for the benefit of others facing a similar situation:

The correct solution is to use Split DNS in Route53. Create matching internal and external zones. Then delegate from CloudFlare base domain to public Route53 zone.

mnordhoff · 2017-11-17 11:01:06 UTC

Probably not. In a typical configuration, where the subnet is something like 172.31.0.0/20, 172.31.0.2 is Amazon’s recursive DNS IP.

It’s a managed split horizon setup. The NS records, delegation or authoritative, probably don’t matter at all. The authoritative DNS servers refuse direct queries for private zones.

duvis10 · 2017-11-18 17:28:37 UTC

whewww !!! I had to take a breather this was too complicated for me but I read slowly and understood what needed to be achieved and I must say that’s a lot of routing going on. Good use of the tools to isolate the Name servers responses but base on the little I know the VPC is privately hosted in Amazon and delegation should done from amazon using this references.

**NOTE: **
Route 53 automatically creates a public hosted zone that has the same name as the domain To route traffic to your resources, you create resource record sets, also known as records, in your hosted zone. Each record includes information about how you want to route traffic for your domain. WELL THANK YOU FOR THE EXPERIENCE!!! I NEED A TYLENOL!!

First one:
**http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html **

Then this:
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-dns-service.html