Strange behaviour unbound server

[Phil Pennock]

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