Tuesday 2 April 2013

Set up private, internal DNS for your VPC using Route 53 and unbound

CRITICAL: AWS now offers internal VPC DNS! Below is no longer necessary AFAIK. Woo hoo!


  1. create a Hosted Zone, something like "mydomain.internal"
  2. get the IP addresses of the name servers assigned to your new zone
    1. STRIP OFF '.' at the end of the name servers or BOOM!
  3.  create a new DHCP Options Set
    1. add the IP addresses you gathered above to the domain-name-servers field
  4. Change DHCP Options Set of your VPC by right-clicking it
  5. run sudo dhclient on any already-running instance in the VPC to pick up changes
  6. debug changes have taken place on an instance: cat /etc/resolv.conf

RECOMMEND ALTERNATE SOLUTION: here's a sample unbound.conf I ended up using for a DNS forwarding server within my VPC -- see comments below. I adjusted the "options set" to point at this DNS server instead, in my case.

NOTE: Btw, unbound is available under "epel" yum repo.

        verbosity: 1
        access-control: allow
       name: "mydomain.internal"
       forward-host: ns-123.awsdns-12.com
       forward-host: ns-234.awsdns-34.biz
       forward-host: ns-567.awsdns-56.net
       forward-host: ns-890.awsdns-78.org
       forward-first: no 

See also:

unbound, custom records:  http://sysadminandnetworking.blogspot.com/2014/05/unbound-custom-records.html
unbound, default to google: http://sysadminandnetworking.blogspot.com/2014/05/unbound-default-to-googles-dns.html


  1. So do you do something for resolving DNS as well? If I understand this correctly, you won't be able to resolve anything but your "mydomain.internal".

  2. I had the same issue of getting DNS working with the outside world, and ended up using unbound (see other post on building unbound) to do DNS forwarding. I couldn't ping www.google.com for instance.

    Not being able to reach the outside world, I believe I attempted to add to the list of nameservers for the DHCP options, but that didn't work either since resolve wasn't passing from one nameserver to the next on failure. Would be nice if it did.

    The "unbound" solution undermines the info in this post to a degree, I ended up only forwarding DNS requests to one of the Route 53 nameservers mentioned above.

  3. I'm having some trouble with this. My unbound server is correctly resolving external requests such as www.google.com however it does not resolve any of the mydomain.internal requests. If I nslookup directly at the ns-xxx.awsdns servers instead of my unbound server, those resolve properly. Any thoughts on why the forwarding for my internal records does not appear to work?

  4. Make sure you update your VPC "dhcp option set" to point your servers at the unbound server ONLY. And make sure port 53 is open to other servers on the unbound server's security group firewall.

    You can "tcpdump -nn port 53" on your unbound server to make sure other servers are reaching it.

    If that doesn't work, let me know.

  5. Actually, I haven't gotten to the point where I'm configuring the option set. I'm just testing using nslookup and specifying my unbound server from another machine in the VPC.

    Basically: `nslookup -q=cname test.mydomain.internal 10.0.x.x`

    test.mydomain.internal is a cname that points to www.google.com

    If I run the same nslookup command pointing to ns-xxx-awsdns servers it resolves correctly.

    If I run `nslookup google.com 10.0.x.x` I see the request hit my unbound box and it resolves google properly.

  6. First, you may want to learn the "dig" command. Replace the above with "dig test.mydomain.internal @10.0.x.x" and "dig google.com @10.0.x.x".

    Second, send me a pastebin link to your config contents. Strip out or replace sensitive data first.

    Also, make sure when you stop unbound, you have no lingering unbound processes, and nothing listening on port 53 with "lsof -nP -i :53" as root. Then, start unbound up again. I want to make sure your config is getting loaded with your changes.

  7. I works fine for me, whereas I had the same problem than Brian R.
    THe problem was coming from the fact that I pasted the ns server list directly from Route53 admin console, which contains a dot at the end.

    Removing this trailing dot solved my problem.

  8. I have the same problem than Brian, and I think that my config is correct (no trailing dots):

    dig test.thz.internal @ns-218.awsdns-27.com: http://pastebin.com/WwqdtYuE
    dig test.thz.internal @localhost: http://pastebin.com/hASQY8QQ

    Any thoughts?

  9. I have thoughts like: why the semi-colons at the end of your config file lines?!

    1. DNSSEC. This was the culprit! AWS Route53 is not compatible with DNSSEC so disable it in server: part, like this:

      verbosity: 1
      access-control: allow
      module-config: "iterator"

      The last line is important!

  10. Thank you for your information.it is very nice article.
    Digital Marketing Training in Pune

  11. Really nice blog post.provided a helpful information.I hope that you will post more

    updates like this
    AWS Online Course


Note: only a member of this blog may post a comment.

Interview questions: 2020-12

Terraform provider vs provisioner Load balancing Network Load Balancer vs Application Load Balancer  Networking Layer 1 vs Layer 4 haproxy u...