[DNS] BIND 9.9.9-P8 issue

[Daniel Rodrigues]

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
b.root-servers.net.
l.root-servers.net.
d.root-servers.net.
g.root-servers.net.
a.root-servers.net.
j.root-servers.net.
h.root-servers.net.
m.root-servers.net.
e.root-servers.net.
k.root-servers.net.
f.root-servers.net.
i.root-servers.net.
c.root-servers.net.

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


2017-08-21 15:18 GMT+02:00 Warren Kumari <warren at kumari.net>:

> On Mon, Aug 21, 2017 at 4:33 AM, Daniel Rodrigues <dro1976 at 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-users at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170821/00bfdc53/attachment-0001.html>