[DNS] BIND 9.9.9-P8 issue

Daniel Rodrigues

unread,

Aug 21, 2017, 4:33:52 AM8/21/17

to bind-...@lists.isc.org

Hello guys,

We are facing to an important issue which is strongly annoying us on our DNS resolvers. We saw our cache decrease and we got lot of SERVFAIL/recursion during this period. The only way to solve it is to flush cache or reboot BIND. Our version is 9.9.9-P8 running on RHEL 6.6. We already got it 6 times in 1 week on different servers.

Here some logs when the problem appears :

named[10616]: database: warning: delete_node: dns_rbt_findnode(nsec): partial match

named[10616]: general: warning: checkhints: unable to get root NS rrset from cache: not found

general: info: sockmgr 0x7f4419f240f0: maximum number of FD events (64) received

Below one link to see one cacti’s screen showing the performance:

https://drive.google.com/file/d/0B3pglqx0sbOiN3ZWQmM3MDdYOTQ/view?usp=sharing

Do you have any idea to solve it definitively ? Is it an exploit bug ?

Thanks for you help.

Warren Kumari

unread,

Aug 21, 2017, 9:20:13 AM8/21/17

to Daniel Rodrigues, bind-...@lists.isc.org

On Mon, Aug 21, 2017 at 4:33 AM, Daniel Rodrigues <dro...@gmail.com> wrote:
> Hello guys,
>
>
>
> We are facing to an important issue which is strongly annoying us on our DNS
> resolvers. We saw our cache decrease and we got lot of SERVFAIL/recursion
> during this period. The only way to solve it is to flush cache or reboot
> BIND. Our version is 9.9.9-P8 running on RHEL 6.6. We already got it 6 times
> in 1 week on different servers.
>
> Here some logs when the problem appears :

Some questions:
1: What do you have in your hints file? What do you get if you run
"dig ns . @<address>" where
<address> are the addresses in the hints file.

2: Have you manually configured / changed the max-cache-size ? If so,
er, why and to what?

3: Do you usually get the "maximum number of FD events (64) received" message?
Have you followed the advice in
https://kb.isc.org/article/AA-00716/0/Since-upgrading-to-BIND-9.9-Im-seeing-maximum-number-of-FD-events-64-received.html
?

and, the obvious 4: What changed recently? What sort of boxes are
these? What is their network connectivity like?

W

>
>
>
> named[10616]: database: warning: delete_node: dns_rbt_findnode(nsec):
> partial match
>
> named[10616]: general: warning: checkhints: unable to get root NS rrset from
> cache: not found
>
> general: info: sockmgr 0x7f4419f240f0: maximum number of FD events (64)
> received
>
>
>
> Below one link to see one cacti’s screen showing the performance:
>
> https://drive.google.com/file/d/0B3pglqx0sbOiN3ZWQmM3MDdYOTQ/view?usp=sharing
>
>
>
>
> Do you have any idea to solve it definitively ? Is it an exploit bug ?
>
> Thanks for you help.
>
>
>
>

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf

Daniel Rodrigues

unread,

Aug 21, 2017, 3:12:26 PM8/21/17

to Warren Kumari, bind-...@lists.isc.org

Hi,

Thank you for your reply.

1. We got the last version of root.cache file.

Using dig, only d.root-servers.net doesn't respond at all.

All other root servers answers correclty :

e.g

# dig ns . @202.12.27.33 +short

2. max-cache-size is currently fixed at 200M. We have got this value since a few years and we had never problems with it.

When I run 'rndc dump' command, the result file size is less than 100MB.

3. No, I didn't follow this advice, because usually this message appears only during 'Water Torture Attack'.

And with the current cache problem, this message doesn't appears each time.

4. We only updated the root.cache file. And since we have got a lot of warnings but we don't know if this is the root cause!

Our servers are VMWare VM on RHEL 6.6 / 4GB of RAM with a 10GB network connectivity

Daniel Rodrigues

unread,

Aug 21, 2017, 3:35:56 PM8/21/17

to Peter, bind-...@lists.isc.org

Hi,

We don't have any IPv6 interfaces and normally IPv6 network stack is disabled (kernel module is blacklisted).

But we never use this flag, so in doubt I will try this tomorrow.

Thank you.

Daniel

2017-08-21 11:12 GMT+02:00 Peter <in...@sunnyday.sk>:

Hi,

We had same symptom/issue on several instances where IPv6 network stack was enabled on system (even with local IPv6 address only)
By default BIND will start to listen and try to use IPv6 transport for outgoing iterative query.

After some troubleshooting, we realized that cached NS record had only remaining IPv6 adddresses valid which cause issue in retrieving few list of NS

If you do not have full IPv6 connectivity implemented on network and I can suggest based on this experience to set BIND with flag -4 (use IPv4 transport only)

Peter

On 2017-08-21 10:33, Daniel Rodrigues wrote:

Hello guys,

We are facing to an important issue which is strongly annoying us on
our DNS resolvers. We saw our cache decrease and we got lot of
SERVFAIL/recursion during this period. The only way to solve it is to
flush cache or reboot BIND. Our version is 9.9.9-P8 running on RHEL
6.6. We already got it 6 times in 1 week on different servers.

Here some logs when the problem appears :

named[10616]: database: warning: delete_node: dns_rbt_findnode(nsec):
partial match

named[10616]: general: warning: checkhints: unable to get root NS
rrset from cache: not found

general: info: sockmgr 0x7f4419f240f0: maximum number of FD events
(64) received

Below one link to see one cacti’s screen showing the performance:

https://drive.google.com/file/d/0B3pglqx0sbOiN3ZWQmM3MDdYOTQ/view?usp=sharing

[1]

Do you have any idea to solve it definitively ? Is it an exploit bug ?

Thanks for you help.

Links:
------
[1]
https://drive.google.com/file/d/0B3pglqx0sbOiN3ZWQmM3MDdYOTQ/view?usp=sharing