5

The situation

We are migration our web-applications to AWS. To connect our on-premise network and AWS we have created a VPN connection. This works without problems.

On-premise we have a MS AD (2008 R2) that is an authoritative server for (among others) ourcompany.tld (not actual domainname ;) )

On AWS we want all internal service to be named like: *.dev.ourcompany.tld. This DNS should be resolved by internal route53.

On AWS public resources are named *.ourcompany.tld. This DNS is resolved by our own nameservers. (working)

The problem

On our on-premise network we want to be able to resolve someserver.dev.saa.nl. To achieve this our MS ActiveDirectory needs to be told to do a lookup on AWS for this domainname.

AWS internal route53 is only accessible from within the AWS VPC. AD cannot reach this directly.

AWS internal route53 is only accessible through a VPC DNS forwarder which is non-authoritative.

MS AD requires an authoritative source for stub-zones and conditional forwarders.

What we have done / tried

  • Create a DNS forwarder in the VPC. This forwarder is non-authoritative. It works good when you setup the DNS forwarder as primary DNS on the computer itself. ActiveDirectory does not allow us to create a stub-zone or conditional forwarder with the message that the server is not authoritative.
  • Create a DNS server with a stub-zone for dev.ourcompany.tld in amazon VPC. When creating a stub-zone it will report as being authoritative, however since we can only resolve DNS over the VPC DNS forwarder (on VPC IP + 2) it refuses to create the stub as its source is not authoritative. Direct connection to the authoritative master returns state REFUSED.

  • searched AWS docs. The only proper solution we have found is https://aws.amazon.com/blogs/security/how-to-set-up-dns-resolution-between-on-premises-networks-and-aws-using-aws-directory-service-and-amazon-route-53/ However the frankfurt region (to which we are bound by regulations) does not have simple AD. A full MS AD on AWS will also work but we are not prepared to pay €300+ per month for a dns forwarder

  • Contact AWS support. After a week of lengthy waits they still don't seem to understand the issue. We are on business support plan.

Can anyone please give some directions in how we can solve this using our existing AD?

diagram

Update: Routing another domain to AWS internal route 53 works by simply ignoring the error with a conditional forward. However for a subdomain we would need to make a delegation which in turn throws a SERVFAIL when queried.

Update 2: It does not appear to be possible. Also AWS tech support gave up. We have now registered another domain name for all our servers and services and used a fixed DNS in our AD to setup the services used by others than the IT dep. with a proxy in EC2 that translates it to the LB DNS names.

nvanesch
  • 101
  • 1
  • 6

3 Answers3

2

If I get it right we've got two constraints:

  1. The dev.ourcompany.tld Route53 zone can only be resolved from the VPC and not over the VPN, and
  2. The on-prem AD wants to talk directly to the authoritative nameserver for dev.ourcompany.tld and not to a forwarder.

With these limitations we have to design a solution that will 1) make AD think it talks directly to Route53 and 2) make Route53 think that the DNS requests are coming from an IP in the VPC.

One possible answer is NAT - Network Address Translation, this is how I would do it:

  1. Spin up a small EC2 instance with e.g. Amazon Linux and Disable "Source/Destination Check" in the Networking settings of the instance. Maybe give it a fixed private IP address too. And allow incoming TCP and UDP port 53 in the Security Group.

  2. Permit IP forwarding in /etc/sysctl.conf by setting net.ipv4.ip_forward=1

  3. Configure the iptables on the instance to redirect all incoming traffic on port 53 to Route53, i.e. to VPC-CIDR+2. Something like:

    iptables -t nat -A PREROUTING -p tcp --dport 53 \
         -s <on-prem-cidr> -j DNAT --to <VPC-CIDR+2>

iptables -t nat -A PREROUTING -p udp --dport 53 \
         -s <on-prem-cidr> -j DNAT --to <VPC-CIDR+2>

  4. Point AD to the private IP of this instance. The DNS traffic will be NAT'ed and forwarded to Route53 which will think that it's coming from the VPC and will answer it. Also the AD will be happy because the answer will come directly from the authoritative nameserver.

Hope that helps :)

MLu
  • 24,849
  • 5
  • 59
  • 86
  • thank you for you answer. However the really fun part is that aws does not even expose the authoritative server in the vpc but only its own forwarder. so even with 53 natted to the dns host it will still redirect to a forwarder.. authoritative host is unreachable from anywhere. – nvanesch Dec 27 '17 at 00:07
  • @nvanesch hmm that's interesting. In that case your only choice is probably to spin up a DNS forwarder (e.g. with `unbound` or `dnsmasq` server) and hack the source to pretend that it's returning an authoritative answer in all cases. It should be just a flag in the answer, shouldn't be too difficult to do hopefully :) – MLu Dec 27 '17 at 00:39
1

I had same situation although an authoritative server wasn't MS AD on our on-premise. To resolve the issue, I wrote a plugin for CoreDNS which behaves an authoritative name server using Amazon VPC DNS as the backend. It works on our environment now.

Hiroyuki Wada
  • 11
  • 1
0

You can do it as follows:

  1. On your Authoritative DNS server for ourcompany.tld create delegation to dev.ourcompany.tld
  2. In the NS fields put the same DNS servers that are authoritative for ourcompany.tld - this will unblock you to set up Conditional Forwarder in next step
  3. Setup Conditional Forwarder for dev.ourcompany.tld and point it to IP(s) of "EC2 instance with DNS forwarder" (as depicted on your image)

Source

ihaz
  • 1