On 2019-07-11 at 12:45 +0300, Eduard Ahmatgareev via Unbound-users wrote: > amazon doesn't like NXDOMAIN records, if query arrived to nonexistent > domain, unbound forwards this query to aws vpc dns server and aws spend a > lot of time to return answer. > Probably it can be our issue, but I am not 100% sure
Amazon's DNS caches don't like a lot of things, and break DNSSEC in my past experience. I don't know if they've solved that, but I long since switched to only using them for the zones which need to be delegated to them. So when my Packer scripts build an OS image for use in AWS, they create /etc/unbound/unbound.conf.d/ec2.conf containing: -----------------------------8< ec2.conf >8----------------------------- # http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html # The 169.254.169.253 IP is guaranteed as long as DNS service is available for # the VPC. However, it breaks DNSSEC, so we don't use it for "." server: domain-insecure: "internal" private-domain: "amazonaws.com" private-domain: "internal" forward-zone: name: "amazonaws.com." forward-addr: 169.254.169.253 forward-zone: name: "internal." forward-addr: 169.254.169.253 -----------------------------8< ec2.conf >8----------------------------- This assumes a Debian-derived setup using /etc/unbound/unbound.conf.d/ files automatically. You'll want to add extra config files for any domains which you register in R53 for internal resolution. The above config covers the default `internal`, and adds in `amazonaws.com` because using VPC Endpoints will require you to go through their servers to get the overlaid DNS entries. Your main configuration would then just resolve DNS normally, instead of being a forwarder. This does mean that your security groups and subnet ACLs will need to permit the boxes running Unbound to make DNS queries out to the Internet. -Phil
