unbound resolving different address intermittenly

Andrew Meyer andrewm659 at yahoo.com
Tue Oct 30 17:35:22 UTC 2018

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 <jpeacock at messagesystems.com> wrote:

 We've hit several un[der]documented limits when using AWS, see the first two entries here:
Our Principal Operations Engineer did a more technical presentation at several Usenix conferences:
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).
On Tue, Oct 30, 2018 at 9:52 AM, Andrew Meyer via Unbound-users <unbound-users at nlnetlabs.nl> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181030/a85de315/attachment.htm>

More information about the Unbound-users mailing list