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: 4m
so-sndbuf: 4m
cache-max-negative-ttl: 10
do-ip4: yes
do-ip6: yes
do-udp: yes
do-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
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
John,
Thanks for the response. The article and video helped some. We are still looking into the issue.
Re: stub zones
All our zones with exception of one is hosted in Route53. So would Unbound be hitting the recursory servers then?
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
Never mind me; I was misremembering how the R53 stuff works. The VPC network AWS resolver is in fact not authoritative for zones hosted in Route53 (I just checked). FORWARD is what you want.
John
No worries. Just back to square one.
Never mind me; I was misremembering how the R53 stuff works. The VPC network AWS resolver is in fact not authoritative for zones hosted in Route53 (I just checked). FORWARD is what you want.
John
Hi Andrew,
Not sure I understand your question/problem. Is Unbound sometimes
skipping the forwarder and resolving as if there is no forwarder
configured? Do you have forward-first enabled? In that case Unbound will
ignore the configured forwarder when they become unreachable. Maybe that
happened?
-- Ralph
I don’t have forward-first enabled on any of the forwarded domains. We have done a tcpdump and unbound is reaching the forwarded DNS server each time but its not getting the correct information when establishing the web connection.
Hi Andrew,
Not sure I understand your question/problem. Is Unbound sometimes
skipping the forwarder and resolving as if there is no forwarder
configured? Do you have forward-first enabled? In that case Unbound will
ignore the configured forwarder when they become unreachable. Maybe that
happened?
– Ralph
Hi,
Can you clarify a little more please? In the packet capture, did unbound receive public answers incorrectly from the upstream resolver or did unbound make a recursive query?
Just trying to be 100% sure where the problem is.
Gavin
Yes it did.
Hi,
Can you clarify a little more please? In the packet capture, did unbound receive public answers incorrectly from the upstream resolver or did unbound make a recursive query?
Just trying to be 100% sure where the problem is.
Gavin