Re: Server overwhelmed by rejections?
On 19.01.10 08:29, Lightner, Jeff wrote:
> Luckily my machines have enough horsepower not to shut down from this
> but I have on occasion seen the CPU load start going up due to it. On
> lowered powered machines this would likely cause what you're seeing.
>
> If you're running a firewall (external device or iptables on Linux) the
> best way to deal with this is to determine the IP or IP range that is
> hammering you and simply blacklist it (drop its packets).
>
> If you're not running a firewall you can blacklist the IPs in
> named.conf.
> In options insert a line like:
> blackhole { blackhats; };
> Then create an acl called blackhats with the IPs or range you want to
> drop:
> acl "blackhats" {
> x.x.x.x; x.x.x/22;
> };
> In the above first x.x.x.x would be a single IP and the x.x.x/22 would
> be an entire 22 CIDR for a given network.
in response to some ddos attacks a year ago when many servers were receiving
queries for ". IN NS" and advice was given - don't blackhole those IP
addresses. At least some of them are real authoritative-only nameservers and
putting them to blackhole would prevent your bind from reaching them.
It's better to firewall off requests from those IP addresses to your port
53. If you have recursive-only nameserver, you can safely disable requests
to it from unauthorized sources and allow only authorized networks.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange CNAME issue
seren wrote: Hi, I've run into some strange issues with BIND and CNAMES. The examples you show indicate strange issues only with whatever name server code is running on your localhost. Nothing in your examples actually identify this as BIND. We're using BIND9 (on Ubuntu) internally and have our external DNS hosted by NetworkSolutions. Occasionally I'll be able to create a CNAME in NetworkSolutions that BIND is unable to resolve. Using dig I notice it's doing a query for an A record, This is the record type use by dig in default of a specific type on the command line. and in most cases this works even if the entry is a CNAME. In the cases where it fails, I see either a timeout error or a SERVFAIL. Your local instance of named is respectively either not responding, or reporting an error. Have you looked in your logs for more information? Have you tried 'dig +trace'? If I then do a dig query specifying a CNAME, I get a quick successful result and subsequent queries to BIND succeed, until the record expires from the cache. The records that fail don't seem to have anything in common besides them all being CNAMES and longer names seeming to fail more. Both BIND9 and two windows-based DNS servers fail with the exact same records, however Google (8.8.8.8) and several other public DNS services resolve them fine. I think you need to ask what's different between (on the one hand) your "BIND9" and windows-based name servers and (on the other) name servers which you tell us work: if not in the configuration, then in the environment. Are all of your "failing" name servers behind the same firewall? If so, does the firewall allow DNS queries and responses over TCP as well as UDP? Does the firewall perhaps break "long" responses? I ask because I've noticed some truncation and fallback to TCP when I use 'dig +trace' to query for one of the names you've mentioned as failing. Best regards, Niall O'Reilly University College Dublin IT Services ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.5.2-P2 is now available
Evan Hunt writes: >BIND 9.5.2-P2 is now available. > > BIND 9.5.2-P2 is a SECURITY PATCH for BIND 9.5.2. It addresses two > potential cache poisoning vulnerabilities, both of which could allow > a validating recursive nameserver to cache data which had not been > authenticated or was invalid. The ISC web site has a typo on it. https://www.isc.org/downloadables/11 reads: BIND 9.5.1-P2 is a Current - Production Release, published 19 January 2010. ^ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
master server selection / notify
Hello, I wasn't able to find answer, if this is documented anywhere, please point me there. I like reading docs ;-) when I have configured a zone with multiple masters, does the server selection work the same way as "ordinary" when resolving remote domains? And if a NOTIFY comes from one of those servers, is the one preferred or is the source of NOTIFY ignored and the selection works as usual? I have small farm of servers and when any of them fetches zone from the master and sends notify, I't like others to fetch zone from this one as a small optimization. Thank you. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. A day without sunshine is like, night. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Server overwhelmed by rejections?
I was quite satisfied the ones I blacklisted were causing my CPU load to
spike and have seen no ill effects from having blocked them. I wasn't
suggesting anyone blacklist every IP they don't recognize but rather
those that are trying the same thing over and over such as attempting to
update one of my zones.
Restricting everything to port 53 would not have solved the CPU load
issue since that is where the traffic was coming in already.
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of Matus UHLAR - fantomas
Sent: Wednesday, January 20, 2010 3:53 AM
To: bind-users@lists.isc.org
Subject: Re: Server overwhelmed by rejections?
On 19.01.10 08:29, Lightner, Jeff wrote:
> Luckily my machines have enough horsepower not to shut down from this
> but I have on occasion seen the CPU load start going up due to it.
On
> lowered powered machines this would likely cause what you're seeing.
>
> If you're running a firewall (external device or iptables on Linux)
the
> best way to deal with this is to determine the IP or IP range that is
> hammering you and simply blacklist it (drop its packets).
>
> If you're not running a firewall you can blacklist the IPs in
> named.conf.
> In options insert a line like:
> blackhole { blackhats; };
> Then create an acl called blackhats with the IPs or range you want to
> drop:
> acl "blackhats" {
> x.x.x.x; x.x.x/22;
> };
> In the above first x.x.x.x would be a single IP and the x.x.x/22 would
> be an entire 22 CIDR for a given network.
in response to some ddos attacks a year ago when many servers were
receiving
queries for ". IN NS" and advice was given - don't blackhole those IP
addresses. At least some of them are real authoritative-only nameservers
and
putting them to blackhole would prevent your bind from reaching them.
It's better to firewall off requests from those IP addresses to your
port
53. If you have recursive-only nameserver, you can safely disable
requests
to it from unauthorized sources and allow only authorized networks.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Upgrading BIND 9.2.1 to BIND 9.6.1-p3 on AIX
In message , Balanagaraju Munukutla writes: > Hi > > we are running BIND 9.2.1 on AIX 5.3 TL11. Now, I would like to upgrade it > to BIND 9.6.1-p3. > > Is this BIND version is stable? > > Can anybody help me to suggest how upgrade the BIND with minimal impact? I > am running BIND in "bind-jail". Apart from the allow-recursion acl now having a tighter defaults, BIND 9.6.1-P3 will just use the old config assuming that you don't have errors in your master files. If you do you should be correcting them anyway. Later versions of BIND are less forgiving of configuration errors. You can take correct master files from BIND 4.8 (+20 years ago) and use them unchanged in BIND 9.7.0. I would just compile named and then run it from the source tree with "bin/named/named -g ", having first stopped the current version, and see what it reports. When you are happy that all errors are corrected you can install it and adjust your startup scripts to call /usr/local/sbin/named instead of the version that ships with aix. Mark > Thanks for your help. > > Regards > Nagaraj -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.6.1-P3 is now available
On Jan 19, 2010, at 12:28 PM, Evan Hunt wrote: BIND 9.6.1-P3 is a SECURITY PATCH for BIND 9.6.1. It addresses two potential cache poisoning vulnerabilities, both of which could allow a validating recursive nameserver to cache data which had not been authenticated or was invalid. Do these vulnerabilities only apply to recursive name servers that have DNSSEC trusted keys or lookaside keys configured? Or do they also apply if the server has dnssec-enable & dnssec-validation enabled (as by default on 9.6.x) but no trusted keys or lookaside keys configured? Thanks, Dave Coulthart ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.6.1-P3 is now available
David Coulthart wrote: > On Jan 19, 2010, at 12:28 PM, Evan Hunt wrote: >> BIND 9.6.1-P3 is a SECURITY PATCH for BIND 9.6.1. It addresses two >> potential cache poisoning vulnerabilities, both of which could allow >> a validating recursive nameserver to cache data which had not been >> authenticated or was invalid. > > Do these vulnerabilities only apply to recursive name servers that have > DNSSEC trusted keys or lookaside keys configured? Or do they also apply > if the server has dnssec-enable & dnssec-validation enabled (as by > default on 9.6.x) but no trusted keys or lookaside keys configured? There is no validation until you have a trusted key or lookaside configured. The default enabling has no effect without the keys - therefore you are not vulnerable either without the keys. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Fatal Error in resolver.c
Our secondary server died last night with the following messages: named[18768]: resolver.c:3827: fatal error: named[18768]: RUNTIME_CHECK(((pthread_mutex_unlock(((&res->buckets[bucketnum].lock))) == 0) ? 0 : 34) == 0) failed named[18768]: exiting (due to fatal error in library) Has anyone seen this before? I tried to do some googling around but didn't really find anything. It's bind version 9.6.1-P2 running under RHEL 5.4. -- Timothy A. Holtzen Campus Network Administrator Nebraska Wesleyan University ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Notify "storms"
On 1/18/2010 4:27 PM, Todd wrote: Good day all, We've run into a problem with our DNS servers. The way we update our masters is via a CVS Checkout and reload of the zones modified. Sometimes though, we need to reload the whole config for big changs/etc. When that happens, all 6 masters (I know, we're getting rid of some) send notifies to all 80+ (I know, we're getting rid of some) slaves for all 1800 zones. This causes all the slaves to verify all 1800 zones on 6 masters, which then delays the changes we made from actually getting to the slaves. Right now it's about 2.5 hours for all slaves to do all zones. We would like to make this better. Can anyone help with ideas on this? Are we missing something obvious? In that situation I'd consider using CVS on all of the servers to maintain the DNS data. Just make all of the servers masters, and forget about slaves. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Notify "storms"
On 2010/01/20, at 13:03, Dave Sparro wrote: >> We would like to make this better. >> Can anyone help with ideas on this? Are we missing something obvious? >> > > In that situation I'd consider using CVS on all of the servers to maintain > the DNS data. > Just make all of the servers masters, and forget about slaves. Agreed .. that's definitely one solution. With your data already in a version control system, and that many name servers, you might benefit from replacing zone transfers with a configuration management tool (cfengine, bcfg2, etc.) which can take care of "noticing" that there's new data in the version control system, getting it onto the slaves, and then telling them to reload or reconfig as appropriate (depending on whether it's zone files or named.conf that changed). Another option if you want to stick with the master/slave approach is to tier your slaves. Reduce the masters to just two or three, and then assign 10 or so of the slaves to be intermediate masters. The intermediates slave from the real masters, and then every other server slaves from, at most, two or three of the intermediates each. If you group these appropriately, then you can get it down to a maximum of 10 or so slaves talking to any one upstream master, with a nice mesh to maintain redundancies. How you divide them up is up to you ... regionally works well though. Matt ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: master server selection / notify
When I tested the multiple masters configuration, I noticed, that slave chooses master which sends notifies. I used bind-9.4.3-p2. 2010/1/20 Matus UHLAR - fantomas > Hello, > > I wasn't able to find answer, if this is documented anywhere, please point > me there. I like reading docs ;-) > > when I have configured a zone with multiple masters, does the server > selection work the same way as "ordinary" when resolving remote domains? > > And if a NOTIFY comes from one of those servers, is the one preferred or is > the source of NOTIFY ignored and the selection works as usual? > > I have small farm of servers and when any of them fetches zone from the > master and sends notify, I't like others to fetch zone from this one as a > small optimization. > > Thank you. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > A day without sunshine is like, night. > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Notify "storms"
> serial-query-rate While this appears to be helping in the lab, it's still taking between 2 and 3 minutes for each slave to even finish receiving the NOTIFYs from the master. They then start hitting the master(s) with SOA queries whch seems to take a really long time. We're going to keep tuning, but it looks like we've reached some sort of tipping point where inefficiencies in our methodology, architecture and the underlying protocol might be combining to make for less than ideal conditions for fast changes. Thanks for this tip ... big 'ah-ha' moment for us. Cheers, Todd. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
compiling bind without xml support
Greetings everyone: How do I configure bind 9.5 and newer without xml support in FreeBSD as what happens is named fails to start in FreeBSD from /etc/rc.conf as it basically says: /libexec/ld-elf.so.1: Shared object "libxml2.so.9" not found, required by "named" It runs fine when I do /etc/rc.d/named start I'm compiling bind as follows: ./configure --prefix=/usr --sysconfdir=/etc/namedb --with-openssl make make install Is there a way to make it run from /etc/rc.conf with the xml support or do I have to somehow disable the xml statistics support as I looked in README but it only mentions that 9.5 added a experimental XML statistics server but doesn't say how to disable it. named is run as: /usr/sbin/named -u bind -t /var/named vi...@bigbang [1:26pm][~] >> ldd /usr/sbin/named /usr/sbin/named: libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x28224000) libz.so.2 => /lib/libz.so.2 (0x2832) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2833) libm.so.3 => /lib/libm.so.3 (0x2841d000) libc.so.6 => /lib/libc.so.6 (0x28433000) Thanks! Cheers, Vince Vincent Poy, Ph.D. - Astrophysics ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: compiling bind without xml support
In message <429af92e1001201328h2f2c6ef8s6074d706e3eb1...@mail.gmail.com>,
Vincent Poy writes:
> --===4861971564982172998==
> Content-Type: multipart/alternative; boundary=000e0cd6afe0e73eec047d9f4336
>
> Greetings everyone:
>
> How do I configure bind 9.5 and newer without xml support in FreeBSD as what
> happens is named fails to start in FreeBSD from /etc/rc.conf as it basically
> says:
>
> /libexec/ld-elf.so.1: Shared object "libxml2.so.9" not found, required by
> "named"
>
> It runs fine when I do /etc/rc.d/named start
>
> I'm compiling bind as follows:
> ./configure --prefix=/usr --sysconfdir=/etc/namedb --with-openssl
> make
> make install
>
> Is there a way to make it run from /etc/rc.conf with the xml support or do I
> have to somehow disable the xml statistics support as I looked in README but
> it only mentions that 9.5 added a experimental XML statistics server but
> doesn't say how to disable it.
>
> named is run as:
>
> /usr/sbin/named -u bind -t /var/named
>
> vi...@bigbang [1:26pm][~] >> ldd /usr/sbin/named
> /usr/sbin/named:
> libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x28224000)
> libz.so.2 => /lib/libz.so.2 (0x2832)
> libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2833)
> libm.so.3 => /lib/libm.so.3 (0x2841d000)
> libc.so.6 => /lib/libc.so.6 (0x28433000)
>
> Thanks!
>
> Cheers,
> Vince
> Vincent Poy, Ph.D. - Astrophysics
I suspect the problem is that named is being started before
ldconfig is being called so /usr/local/lib is not being
searched.
You could change the "-L/usr/local/lib" before -lxml2
to "-Wl,-rpath,/usr/local/lib" in bin/named/Makefile,
remove bin/named/named then re-run make to embed
/usr/local/lib into the search path built into named
for the loader.
Alternatively add
LD_LIBRARY_PATH="/usr/local/lib:${LD_LIBRARY_PATH}"
export LD_LIBRARY_PATH
to /etc/rc.conf/named so that /usr/local/lib will
always be searched.
If you want to disable xml add --with-libxml2=no
to configure's arguments.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.5.2-P2 is now available
This has been fixed, sorry. On 1/20/2010 2:13 AM, lheck...@users.sourceforge.net wrote: > Evan Hunt writes: >> BIND 9.5.2-P2 is now available. >> >> BIND 9.5.2-P2 is a SECURITY PATCH for BIND 9.5.2. It addresses two >> potential cache poisoning vulnerabilities, both of which could allow >> a validating recursive nameserver to cache data which had not been >> authenticated or was invalid. > > The ISC web site has a typo on it. > https://www.isc.org/downloadables/11 reads: > > BIND 9.5.1-P2 is a Current - Production Release, published 19 January 2010. > ^ > > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Notify "storms"
On Wed, Jan 20, 2010 at 03:52:33PM -0500, Todd wrote: > > serial-query-rate > > While this appears to be helping in the lab, it's still taking between > 2 and 3 minutes for each slave to even finish receiving the NOTIFYs > from the master. They then start hitting the master(s) with SOA > queries whch seems to take a really long time. Your NOTIFY tree sounds like it's many-to-many. Maybe you should be using a sparser tree. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
