BIND 'max-cache-size' Value on FreeBSD-13.0

[Mark Tinka]

On 9/2/21 23:51, Michael Sinatra wrote:

>
> I have noticed this also and have opened a (similar but different) 
> issue, but it's a bit weird how it manifests itself.
>
> On your freebsd installation, make sure that all of your interfaces 
> are configured and that bind can listen on them.  (They don't 
> necessarily need to be up; they just need to be configured.)
>
> Also, 'listen-on[-v6] any;' is more likely to prevent this kind of 
> memory leaking than having it listen on explicit addresses.  But the 
> way I can (more) reliably reproduce it is to have a 'listen-on' 
> statement that references a non-existent interface/address.
>
> I think this is a libuv problem, but I have been really short on time 
> to troubleshoot.  But in the meantime, I would check on your 
> 'listen-on' statements and make sure there aren't any stray addresses 
> in there.

What we have on all of our name servers is the below:

// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
//      listen-on       { 127.0.0.1; };

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver.  To give access to the network, specify
// an IPv6 address, or the keyword "any".
         listen-on-v6    { ::1; };
         listen-on-v6    { any; };

We are running dual-stack on all name servers, and both IPv4 and IPv6 
reachability is confirmed solid.

On IPv4, we are listening on just the main interface. On IPv6, we are 
listening on both the localhost and the main interface. Not sure if this 
matters.

For local resolution on each name server, it refers to localhost for 
both IPv4 and IPv6 in '/etc/resolv.conf'. Given our configuration, it's 
using ::1 for local resolution, whenever that may be required, since 
127.0.0.1 has nothing listening on it. Thanks.

Mark.