John,Thanks for the response. The article and video helped some. We are still
looking into the issue.
Re: stub zonesAll our zones with exception of one is hosted in Route53. So
would Unbound be hitting the recursory servers then?
On Tuesday, October 30, 2018 9:56 AM, John Peacock
<[email protected]> wrote:
We've hit several un[der]documented limits when using AWS, see the first two
entries here:
https://www.sparkpost.com/blog/?s=dns
Our Principal Operations Engineer did a more technical presentation at several
Usenix conferences:
https://www.usenix.org/conference/srecon18americas/presentation/blosser
I don't know if any of that will help you; we are fully in the cloud and so our
usage pattern is likely very different from yours (since you have an on-prem
resolver).
I normally prefer stub zones over forward zones for this kind of configuration,
since the AWS zones are authoritative and you don't need to use forward (which
is implicitly a recursive query).
HTH
John
On Tue, Oct 30, 2018 at 9:52 AM, Andrew Meyer via Unbound-users
<[email protected]> wrote:
I have recently setup unbound on CentOS 7 (latest) running version 1.6.6. So
far unbound has been chugging away for about a month. In my configuration I
have an on premise server configured with lots of internal forwarded domains
going to Amazon Route53. As of yesterday unbound started to flip/flop
resolution from the internal/private zones to the external zones. I'm not sure
why. I have turned up the logging verbosity to see if there was an apparent
issue. I though at one point we hit a wall with number of packets per request.
My colleague and I thought we hit a resource records maximum limit. We have
opened a ticket with Amazon to get more information on their side.
In my config file:num-threads: 4 so-rcvbuf: 4mso-sndbuf:
4mcache-max-negative-ttl: 10do-ip4: yesdo-ip6: yesdo-udp: yesdo-tcp: yes
Everything in my zones config file is a forward-zone and not a stub-zone, not
sure if that matters.
Any help is greatly appreciated.
Regards,Andrew
