http://aws.amazon.com/about-aws/whats-new/2014/11/05/amazon-route-53-now-supports-private-dns-with-amazon-vpc/
BELOW IS DEPRECATED!
- create a Hosted Zone, something like "mydomain.internal"
- get the IP addresses of the name servers assigned to your new zone
- STRIP OFF '.' at the end of the name servers or BOOM!
- create a new DHCP Options Set
- add the IP addresses you gathered above to the domain-name-servers field
- Change DHCP Options Set of your VPC by right-clicking it
- run sudo dhclient on any already-running instance in the VPC to pick up changes
- 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, 10.0.0.254 in my case.
NOTE: Btw, unbound is available under "epel" yum repo.
server:
verbosity: 1
interface: 0.0.0.0
access-control: 10.0.0.0/16 allow
forward-zone:
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
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".
ReplyDeleteI 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.
ReplyDeleteNot being able to reach the outside world, I believe I attempted to add 8.8.8.8 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.
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?
ReplyDeleteMake 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.
ReplyDeleteYou 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.
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.
ReplyDeleteBasically: `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.
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".
ReplyDeleteSecond, 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.
I works fine for me, whereas I had the same problem than Brian R.
ReplyDeleteTHe 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.
I have the same problem than Brian, and I think that my config is correct (no trailing dots):
ReplyDeletehttp://pastebin.com/Cu7v5Gi6
dig test.thz.internal @ns-218.awsdns-27.com: http://pastebin.com/WwqdtYuE
dig test.thz.internal @localhost: http://pastebin.com/hASQY8QQ
Any thoughts?
I have thoughts like: why the semi-colons at the end of your config file lines?!
ReplyDeleteDNSSEC. This was the culprit! AWS Route53 is not compatible with DNSSEC so disable it in server: part, like this:
Deleteserver:
verbosity: 1
interface: 0.0.0.0
access-control: 10.0.0.0/16 allow
module-config: "iterator"
The last line is important!
Thank you for your information.it is very nice article.
ReplyDeleteDigital Marketing Training in Pune
Really nice blog post.provided a helpful information.I hope that you will post more
ReplyDeleteupdates like this
AWS Online Course