[Bug 270912] dns/unbound: issues with ASLR

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 19 Apr 2023 22:39:53 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270912

--- Comment #2 from Joshua Kinard <freebsd@kumba.dev> ---
It appears to be failing in the SSL/TLS handshake to the upstream forwarders
after a period of time.  Almost seems like a queue is getting backed up
somewhere and things start overflowing.  I've spent the last hour trying to
debug it, thinking it was a problem w/ Quad9 itself.

The key error in log files from Unbound is this:
> unbound[19]: [19:2] error: SSL_handshake syscall: Connection reset by peer

I've turned up the verbosity, but the additional detail does not shed any
additional light on why the connection was reset (no SSL errors/reasons, etc). 
It seems like everything just works with each connection until it doesn't.

I started noticing these issues when my Squid proxy would just start returning
read errors after launching a browser on one of my desktops.  Waiting about
~30s-1m after launching the browser seemed to let the dust settle and then
things would seemingly work fine for hours before you'd see things start to
hiccup again.  Websites that do a *lot* of background chatter, like Twitter,
Facebook, etc, seemed to trip the issue up the most because they pile the
queries up and seem to overload Unbound, causing the SSL errors to appear.

A good way to reproduce is first, silence outbound network traffic on the
network, or at least traffic that will hit a particular Unbound DNS server.  
Edit the config, set verbosity to '2' and restart the daemon.  tail -f the log
file and once it's loaded up, find a Windows box, and launch MS Edge.  Edge
makes a *ton* of queries at once when it loads and on my end, the first few got
resolved fine against Quad9, then the SSL errors would start to appear, causing
Unbound to try other forwarders and eventually giving up and returning
SERVFAIL.

Can confirm, though, that turning ASLR off for the Unbound binary appears to
make things smooth again.

-- 
You are receiving this mail because:
You are the assignee for the bug.