statistics / named.stats / IPv4 NS address fetch failed

2011-10-26 Thread Fabien Seisen 
Hello .*,

yesterday, i saw some weird behaviour on my recursive servers

I make some graphs using the data provided by "rndc stats" and i saw:

- a bit more of incoming queries
- a lot of dropped queries
- recursive slots goes to the max
- cache hit dropped from 90% to 65%)

- no more external queries than normal
- external queries response time did not changed

but i got a lot of (+500%)
 "IPv4 NS address fetch failed"

What is the real meaning of this counter ?

thank you
-- 
Fabien
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: maximum number of FD events

2011-10-26 Thread Cathy Almond 
On 25/10/11 21:09, Fr34k wrote:
> 
> 
> Hello,
> 
> Environment:  Solaris10 SPARC and x86, BIND 9.7.3-P3 and 9.8.1
> 
> Anomaly:  In our logs, we have been noticing "maximum number of FD events" 
> entries.  For example,
>   named[8592]: [ID 873579 daemon.info] sockmgr 288760: maximum number of FD 
> events (64) received
> 
> Action:  Our web searches have not found a lot of information on this.  One 
> resource suggested that a few of these are "normal".
> 
> We found someone else who seemed to suggest a "fix" by increasing the number 
> of sockets.
> We figured we would give that a shot and see what would happen.  We tried 
> 128, and then 256 -- but we still see these messages:
>   named[14050]: [ID 873579 daemon.info] sockmgr 288760: maximum number of FD 
> events (128) received
>   named[15910]: [ID 873579 daemon.info] sockmgr 288760: maximum number of FD 
> events (256) received
> 
> Does anyone have more information, suggestions, comments?
> 
> Thank you.

This can be 'normal' if you are just seeing the log message
intermittently.  It just indicates a peak in socket activity.  Nothing
should be dropped as a result - it's simply that when named's i/o
watcher polled for socket events, there were more than anticipated so
only the first 64 could be notfied.  The remaining events should get
picked up next time around.

If the message persists, then there is probably something else 'going
on' that you need to investigate.

https://deepthought.isc.org/article/AA-00508/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Strange issue with signed zone

2011-10-26 Thread Peter Andreev 
Hello!

We have ~30 servers running BIND (9.8, 9.7, 9.6). A week ago we have
signed first of our zones with RSA/SHA1 + NSEC3 + OPT-OUT.
Recently we realised that our servers don't generate NSEC3 for signed zone.
Problem has gone after we restarted BIND instances.

Is described behaviour normal for BIND or not?

-- 
--
AP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dispatch - permission denied

2011-10-26 Thread Michael Graff 
Is there something else running on those UDP ports?

On Oct 26, 2011, at 12:49 AM, Benzi Mizrahi  
wrote:

> Hi,
> 
> I've recently upgraded our nameservers  from version 9.6.2.-p3 to 9.7.4 , and 
> the following 
> messages started to appear on all nameservers logs:
> 
> 
> 22-Oct-2011 16:58:41.548 dispatch: dispatch 5612b0: open_socket(0.0.0.0#2049) 
> -> permission denied: continuing
> 22-Oct-2011 17:01:02.361 dispatch: dispatch 5612b0: open_socket(0.0.0.0#4045) 
> -> permission denied: continuing
> 22-Oct-2011 17:10:11.686 dispatch: dispatch 5612b0: open_socket(0.0.0.0#4045) 
> -> permission denied: continuing
> 
> I need to know how critical these messages are and where can I find some 
> information about what is means?
> 
> All our nameservers run on SUN  sparc machines with Solaris 10.
> 
>thank you,
> 
> --
> 
> Benzi Mizrahi, 
> computing center, 
> Weizmann Institute of Science,  Tel: 972-8-9342456 
> Rehovot, Israel. Fax: 972-8-9344102
> 
> Windows: "Where do you want to go today?"
> Linux:   "Where do you want to go tomorrow?"
> FreeBSD: "Are you guys coming or what?"
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dispatch - permission denied

2011-10-26 Thread Chris Thompson 

On Oct 26 2011, Benzi Mizrahi wrote:


Hi,

I've recently upgraded our nameservers  from version 9.6.2.-p3 to 9.7.4 , and the following 
messages started to appear on all nameservers logs:



22-Oct-2011 16:58:41.548 dispatch: dispatch 5612b0: open_socket(0.0.0.0#2049) 
-> permission denied: continuing
22-Oct-2011 17:01:02.361 dispatch: dispatch 5612b0: open_socket(0.0.0.0#4045) 
-> permission denied: continuing
22-Oct-2011 17:10:11.686 dispatch: dispatch 5612b0: open_socket(0.0.0.0#4045) 
-> permission denied: continuing

I need to know how critical these messages are and where can I find some 
information about what is means?

All our nameservers run on SUN  sparc machines with Solaris 10.


These ports are the ones used by nfs and lockd. They will be in use
(and are also privileged, as though they were <1024).

With Solaris I use the following in named.conf options:

 use-v4-udp-ports { range 32768 65535; };
 use-v6-udp-ports { range 32768 65535; };

This is the same as the (default) anonymous port range.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Using DNSSec with BIND

2011-10-26 Thread Mike Rostermund 

Hi all,

I've managed to set up two new DNS servers. One as a master, and the 
second as a slave.
All works perfectly using the traditionally DNS services, but I want to 
get DNSSec up and running.
So far I've managed to create the key's needed for my zones, sign the 
zones, load these zones into
BIND and I can query to get a correct answer if I ask for it (with all 
DNSSec stuff added).


My question is now: What is the best practice for resigning the zones?

I dont want to manually sign the zones each time they run out.
So what is 'usual' way to make this happen? There must be some sort of 
nice way, so I dont have to

create some nasty homebrew shellscript and add such as a cronjob.

Best regards
Mike Rostermund
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Using DNSSec with BIND

2011-10-26 Thread Alan Clegg 
On 10/26/2011 1:53 PM, Mike Rostermund wrote:
> Hi all,
> 
> I've managed to set up two new DNS servers. One as a master, and the
> second as a slave.
> All works perfectly using the traditionally DNS services, but I want to
> get DNSSec up and running.
> So far I've managed to create the key's needed for my zones, sign the
> zones, load these zones into
> BIND and I can query to get a correct answer if I ask for it (with all
> DNSSec stuff added).
> 
> My question is now: What is the best practice for resigning the zones?

BIND 9.7 or newer, dynamic zones and "auto-dnssec maintain;"

AlanC
-- 
a...@clegg.com | acl...@infoblox.com
  1.919.355.8851



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS Sinkhole in BIND

2011-10-26 Thread Michelle Konzack 
Hello Lightner, Jeff,

Am 2011-10-17 13:28:43, hacktest Du folgendes herunter:
> While setting up blackholes in BIND works fine when I did this on
> Linux I found that setting up iptables to do drops for known bad
> IPs/ranges was slightly better as the traffic never gets to BIND in
> the first place as it is stopped at kernel level.  It simply DROPs the
> packet without telling the bad guys why packets didn't go through.
> 
> Example rules for various IPs that have annoyed me in the past:
> -A RH-Firewall-1-INPUT -s 68.222.240.22 -j DROP
> -A RH-Firewall-1-INPUT -s 203.142.82.222 -j DROP
> -A RH-Firewall-1-INPUT -s 217.54.97.137 -j DROP
> -A RH-Firewall-1-INPUT -s 217.219.20.226 -j DROP
> -A RH-Firewall-1-INPUT -s 218.212.248.7 -j DROP

...and you get the hell on you ass if you have several 1000 of them!
In this case, bind9 with RPZ is cheaper.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux
   Internet Service Provider, Cloud Computing


itsystems@tdnet Jabber  linux4miche...@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3   Tel office: +49-176-86004575
77694 Kehl  Tel mobil:  +49-177-9351947
Germany Tel mobil:  +33-6-61925193  (France)

USt-ID:  DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: udp vs tcp query

2011-10-26 Thread Emanuele Balla (aka Skull) 
On 10/23/11 5:42 AM, Benny Pedersen wrote:
> On Sat, 22 Oct 2011 22:34:48 -0500, Larry Brower wrote:
>>> can i control this pr zone when bind is dns client ?
>> Why would you want to? Just fix the problem.
> 
> ask dnsbl owners to stop using rbldnsd ?

No point and no need for that.
TCP is needed only when replies do not fit 512 bytes (let's ignore EDNS0
and such). For any DNSBL, this limit is not a problem at all.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users