Re: client ... query (cache) './NS/IN' denied:
On Fri, Aug 19, 2011 at 3:24 AM, Shawn Bakhtiar wrote: > > Hi all, > > For the first time my primary name server is not reporting any more > > client XXX.XXX.XXX.XXX query (cache) './NS/IN' denied: 1 Time(s) > This is a DNS attacking. Many DNS Servers are meeting this kind of attack each day here. The traffic is huge, once I noticed the traffic to one of my NS host is 1.6G. It's a DDoS that will make your DNS can't serve at all. Regards. ___ 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: syntax error in $GENERATE crashed all nameservers
On Aug 18, 2011, at 1:53 PM, Lightner, Jeff wrote: > No but you're missing the point. I don't think the OP was and I certainly > wasn't suggesting it should have done what he "meant" to do. Nah, I was just referring you your 'If I typed "las" instead of "ls" on a command line and found out that "las" meant "lose all systems"...' comment -- with DWIM it would "helpfully" try and find something that it though you meant, and, when I used it, would basically always choose something bad... I really wasn't promoting this approach (and think we are in violent agreement) -- I probably missed a smily in my response... > However, I DO think it should have errored out because it was invalid input. > Yah... W > (That is to say unless you think negative numbers should be considered valid > input for this command? Please don't respond that negative numbers are > integers and therefore valid - that would be pure sophistry.) > > -Original Message- > From: Warren Kumari [mailto:war...@kumari.net] > Sent: Thursday, August 18, 2011 1:26 PM > To: Lightner, Jeff > Cc: bind-users@lists.isc.org > Subject: Re: syntax error in $GENERATE crashed all nameservers > > > On Aug 18, 2011, at 10:28 AM, Lightner, Jeff wrote: > >> It was certainly a typo and a user error in that regard. >> >> However, he was suggesting it was bug because it should have rejected input >> of negative numbers and I'll have to say I agree with that viewpoint. If I >> typed "las" instead of "ls" on a command line and found out that "las" meant >> "lose all systems" I'd certainly feel whoever had created such a program >> should have put some safeguards in to keep it from doing something so >> ridiculous. > > Ever work with Warren Teitelman? > > http://www.hacker-dictionary.com/terms/DWIM > > W > >> >> >> >> >> >> -Original Message- >> From: bind-users-bounces+jlightner=water@lists.isc.org >> [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of >> /dev/rob0 >> Sent: Wednesday, August 17, 2011 8:59 PM >> To: bind-users@lists.isc.org >> Subject: Re: syntax error in $GENERATE crashed all nameservers >> >> On Wed, Aug 17, 2011 at 04:45:38PM -0400, bl ton wrote: >>> We had a syntax error in our inverse zone file using GENERATE and >>> extra dash were added to the scope so '199--222' instead of >>> '199-222': >>> >>> $GENERATE 199--222 $ PTR 10-100-60-$.dhcp-bl.indiana.edu. >> >> Ouch! Sorry to hear this! >> >>> I would assume named will check the syntax error and refuse to load >>> this zone just like it normally does, but instead it tries to >>> generate millions of erroneous entry because it scanned '-222' to >>> the stop which created a huge number for the named to loop through >>> and the CPU at 100% and locked up 15 of our nameservers, some of >>> those need power recycle to respond to console. >>> >>> This is the first bug of that type we have seen, it's my 12th year >>> of running BIND for large site, another team member has nearly 20 >>> years experience with BIND and we're surprised named doesn't catch >>> the syntax error. >>> >>> Should a syntax error in inverse zone file cause named to locking >>> up the machine? >> >> You're calling this a bug and a syntax error. I disagree. I'd call >> this a typo and a user error. >> >>> But there is checking in forward file and same syntax error were >>> caught: >>> >>> Aug 16 19:09:19 named named[4169]: 16-Aug-2011 19:09:19.609 >>> general: error: dns_rdata_fromtext: buffer-0x42200470 : near >>> '10.100.60.256': bad dotted quad >>> Aug 16 20:00:02 named named[4169]: 16-Aug-2011 22:00:02.649 >>> general: error: $GENERATE: Domain/test.example.edu:1496: bad >>> dotted quad >>> Aug 16 20:00:02 named named[4169]: 16-Aug-2011 22:00:02.649 >>> general: error: zone test.example.edu/IN: loading from master >>> file Domain/test.example.edufailed: bad dotted quad >> >> It's not the same error. You can create PTR names and values of >> anything you want. But the value for an A record is limited to the >> set of valid IPv4 addresses. Note that your A $GENERATE was quite >> happy until it reached 256. >> >> 4294967295.60.100.10.in-addr.arpa. IN PTR >> 10-100-60-4294967295.dhcp-bl.indiana.edu. >> -222.60.100.10.in-addr.arpa.IN PTR >> 10-100-60--222.dhcp-bl.indiana.edu. >> >> Those are both valid, as was the entire $GENERATE range. >> >> 10-100-60-255.dhcp-bl.indiana.edu. IN A 10.100.60.255 >> 10-100-60-256.dhcp-bl.indiana.edu. IN A 10.100.60.256 >> >> First one is valid, second one is not. >> >> That said, I wouldn't have thought that a $GENERATE range could go >> "over the top" like that, so to speak. I could see calling that a >> possible bug. >> -- >> Offlist mail to this address is discarded unless >> "/dev/rob0" or "not-spam" is in Subject: header >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/b
client ... query (cache) './NS/IN' denied:
Hi all, For the first time my primary name server is not reporting any more client XXX.XXX.XXX.XXX query (cache) './NS/IN' denied: 1 Time(s) I use authfail on it to insert any IP attempting to ssh in, and failing more than three times. I checked the current blocked IP address from the NS1 (name server), against the last list I saved, and this is the diff > iptables -I INPUT -s 203.116.40.105/32 -j DROP > iptables -I INPUT -s 75.98.70.11/32 -j DROP > iptables -I INPUT -s 202.93.212.37/32 -j DROP > iptables -I INPUT -s 41.222.10.230/32 -j DROP > iptables -I INPUT -s 193.231.27.8/32 -j DROP > iptables -I INPUT -s 75.102.10.231/32 -j DROP > iptables -I INPUT -s 77.222.43.28/32 -j DROP > iptables -I INPUT -s 67.205.103.187/32 -j DROP > iptables -I INPUT -s 173.246.100.44/32 -j DROP > iptables -I INPUT -s 147.102.208.41/32 -j DROP > iptables -I INPUT -s 113.31.19.111/32 -j DROP It has to be one or several of these IP address that are doing it. My NS2 (secondary name server) is still doing it. I'm going to upload the entire 3980 blocked IP's to it, and see if it stops. If it does, the offender has to be somewhere in this list. :) Is there also a good test to check and see if I can / am poisoned? Hope this helps, Shawn ___ 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: syntax error in $GENERATE crashed all nameservers
> No but you're missing the point. I don't think the OP was and I > certainly wasn't suggesting it should have done what he "meant" to do. > However, I DO think it should have errored out because it was invalid > input. (That is to say unless you think negative numbers should be > considered valid input for this command? Please don't respond that > negative numbers are integers and therefore valid - that would be pure > sophistry.) Yes, it's a bug. It's already in our ticketing system and we will fix it. The problem is in sscanf(), actually -- I hadn't realized this until now, but according to C99, the %u (unsigned integer) conversion format will accept a minus sign in the input without any complaint, and silently convert the result to a large positive number. This strikes me as rather bizarre; I would have expected the conversion to fail, but, shrug. We'll be adding a better formatting check. Meantime: exercise caution. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: syntax error in $GENERATE crashed all nameservers
No but you're missing the point. I don't think the OP was and I certainly wasn't suggesting it should have done what he "meant" to do. However, I DO think it should have errored out because it was invalid input. (That is to say unless you think negative numbers should be considered valid input for this command? Please don't respond that negative numbers are integers and therefore valid - that would be pure sophistry.) -Original Message- From: Warren Kumari [mailto:war...@kumari.net] Sent: Thursday, August 18, 2011 1:26 PM To: Lightner, Jeff Cc: bind-users@lists.isc.org Subject: Re: syntax error in $GENERATE crashed all nameservers On Aug 18, 2011, at 10:28 AM, Lightner, Jeff wrote: > It was certainly a typo and a user error in that regard. > > However, he was suggesting it was bug because it should have rejected input > of negative numbers and I'll have to say I agree with that viewpoint. If I > typed "las" instead of "ls" on a command line and found out that "las" meant > "lose all systems" I'd certainly feel whoever had created such a program > should have put some safeguards in to keep it from doing something so > ridiculous. Ever work with Warren Teitelman? http://www.hacker-dictionary.com/terms/DWIM W > > > > > > -Original Message- > From: bind-users-bounces+jlightner=water@lists.isc.org > [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of > /dev/rob0 > Sent: Wednesday, August 17, 2011 8:59 PM > To: bind-users@lists.isc.org > Subject: Re: syntax error in $GENERATE crashed all nameservers > > On Wed, Aug 17, 2011 at 04:45:38PM -0400, bl ton wrote: >> We had a syntax error in our inverse zone file using GENERATE and >> extra dash were added to the scope so '199--222' instead of >> '199-222': >> >> $GENERATE 199--222 $ PTR 10-100-60-$.dhcp-bl.indiana.edu. > > Ouch! Sorry to hear this! > >> I would assume named will check the syntax error and refuse to load >> this zone just like it normally does, but instead it tries to >> generate millions of erroneous entry because it scanned '-222' to >> the stop which created a huge number for the named to loop through >> and the CPU at 100% and locked up 15 of our nameservers, some of >> those need power recycle to respond to console. >> >> This is the first bug of that type we have seen, it's my 12th year >> of running BIND for large site, another team member has nearly 20 >> years experience with BIND and we're surprised named doesn't catch >> the syntax error. >> >> Should a syntax error in inverse zone file cause named to locking >> up the machine? > > You're calling this a bug and a syntax error. I disagree. I'd call > this a typo and a user error. > >> But there is checking in forward file and same syntax error were >> caught: >> >> Aug 16 19:09:19 named named[4169]: 16-Aug-2011 19:09:19.609 >> general: error: dns_rdata_fromtext: buffer-0x42200470 : near >> '10.100.60.256': bad dotted quad >> Aug 16 20:00:02 named named[4169]: 16-Aug-2011 22:00:02.649 >> general: error: $GENERATE: Domain/test.example.edu:1496: bad >> dotted quad >> Aug 16 20:00:02 named named[4169]: 16-Aug-2011 22:00:02.649 >> general: error: zone test.example.edu/IN: loading from master >> file Domain/test.example.edufailed: bad dotted quad > > It's not the same error. You can create PTR names and values of > anything you want. But the value for an A record is limited to the > set of valid IPv4 addresses. Note that your A $GENERATE was quite > happy until it reached 256. > > 4294967295.60.100.10.in-addr.arpa. IN PTR > 10-100-60-4294967295.dhcp-bl.indiana.edu. > -222.60.100.10.in-addr.arpa.IN PTR > 10-100-60--222.dhcp-bl.indiana.edu. > > Those are both valid, as was the entire $GENERATE range. > > 10-100-60-255.dhcp-bl.indiana.edu. IN A 10.100.60.255 > 10-100-60-256.dhcp-bl.indiana.edu. IN A 10.100.60.256 > > First one is valid, second one is not. > > That said, I wouldn't have thought that a $GENERATE range could go > "over the top" like that, so to speak. I could see calling that a > possible bug. > -- >Offlist mail to this address is discarded unless >"/dev/rob0" or "not-spam" is in Subject: header > ___ > 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 > > > > 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 unlaw
Re: syntax error in $GENERATE crashed all nameservers
On Aug 18, 2011, at 10:28 AM, Lightner, Jeff wrote: > It was certainly a typo and a user error in that regard. > > However, he was suggesting it was bug because it should have rejected input > of negative numbers and I'll have to say I agree with that viewpoint. If I > typed "las" instead of "ls" on a command line and found out that "las" meant > "lose all systems" I'd certainly feel whoever had created such a program > should have put some safeguards in to keep it from doing something so > ridiculous. Ever work with Warren Teitelman? http://www.hacker-dictionary.com/terms/DWIM W > > > > > > -Original Message- > From: bind-users-bounces+jlightner=water@lists.isc.org > [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of > /dev/rob0 > Sent: Wednesday, August 17, 2011 8:59 PM > To: bind-users@lists.isc.org > Subject: Re: syntax error in $GENERATE crashed all nameservers > > On Wed, Aug 17, 2011 at 04:45:38PM -0400, bl ton wrote: >> We had a syntax error in our inverse zone file using GENERATE and >> extra dash were added to the scope so '199--222' instead of >> '199-222': >> >> $GENERATE 199--222 $ PTR 10-100-60-$.dhcp-bl.indiana.edu. > > Ouch! Sorry to hear this! > >> I would assume named will check the syntax error and refuse to load >> this zone just like it normally does, but instead it tries to >> generate millions of erroneous entry because it scanned '-222' to >> the stop which created a huge number for the named to loop through >> and the CPU at 100% and locked up 15 of our nameservers, some of >> those need power recycle to respond to console. >> >> This is the first bug of that type we have seen, it's my 12th year >> of running BIND for large site, another team member has nearly 20 >> years experience with BIND and we're surprised named doesn't catch >> the syntax error. >> >> Should a syntax error in inverse zone file cause named to locking >> up the machine? > > You're calling this a bug and a syntax error. I disagree. I'd call > this a typo and a user error. > >> But there is checking in forward file and same syntax error were >> caught: >> >> Aug 16 19:09:19 named named[4169]: 16-Aug-2011 19:09:19.609 >> general: error: dns_rdata_fromtext: buffer-0x42200470 : near >> '10.100.60.256': bad dotted quad >> Aug 16 20:00:02 named named[4169]: 16-Aug-2011 22:00:02.649 >> general: error: $GENERATE: Domain/test.example.edu:1496: bad >> dotted quad >> Aug 16 20:00:02 named named[4169]: 16-Aug-2011 22:00:02.649 >> general: error: zone test.example.edu/IN: loading from master >> file Domain/test.example.edufailed: bad dotted quad > > It's not the same error. You can create PTR names and values of > anything you want. But the value for an A record is limited to the > set of valid IPv4 addresses. Note that your A $GENERATE was quite > happy until it reached 256. > > 4294967295.60.100.10.in-addr.arpa. IN PTR > 10-100-60-4294967295.dhcp-bl.indiana.edu. > -222.60.100.10.in-addr.arpa.IN PTR > 10-100-60--222.dhcp-bl.indiana.edu. > > Those are both valid, as was the entire $GENERATE range. > > 10-100-60-255.dhcp-bl.indiana.edu. IN A 10.100.60.255 > 10-100-60-256.dhcp-bl.indiana.edu. IN A 10.100.60.256 > > First one is valid, second one is not. > > That said, I wouldn't have thought that a $GENERATE range could go > "over the top" like that, so to speak. I could see calling that a > possible bug. > -- >Offlist mail to this address is discarded unless >"/dev/rob0" or "not-spam" is in Subject: header > ___ > 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 > > > > 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. > -- > ___ > 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@li
RE: syntax error in $GENERATE crashed all nameservers
It was certainly a typo and a user error in that regard. However, he was suggesting it was bug because it should have rejected input of negative numbers and I'll have to say I agree with that viewpoint. If I typed "las" instead of "ls" on a command line and found out that "las" meant "lose all systems" I'd certainly feel whoever had created such a program should have put some safeguards in to keep it from doing something so ridiculous. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of /dev/rob0 Sent: Wednesday, August 17, 2011 8:59 PM To: bind-users@lists.isc.org Subject: Re: syntax error in $GENERATE crashed all nameservers On Wed, Aug 17, 2011 at 04:45:38PM -0400, bl ton wrote: > We had a syntax error in our inverse zone file using GENERATE and > extra dash were added to the scope so '199--222' instead of > '199-222': > > $GENERATE 199--222 $ PTR 10-100-60-$.dhcp-bl.indiana.edu. Ouch! Sorry to hear this! > I would assume named will check the syntax error and refuse to load > this zone just like it normally does, but instead it tries to > generate millions of erroneous entry because it scanned '-222' to > the stop which created a huge number for the named to loop through > and the CPU at 100% and locked up 15 of our nameservers, some of > those need power recycle to respond to console. > > This is the first bug of that type we have seen, it's my 12th year > of running BIND for large site, another team member has nearly 20 > years experience with BIND and we're surprised named doesn't catch > the syntax error. > > Should a syntax error in inverse zone file cause named to locking > up the machine? You're calling this a bug and a syntax error. I disagree. I'd call this a typo and a user error. > But there is checking in forward file and same syntax error were > caught: > > Aug 16 19:09:19 named named[4169]: 16-Aug-2011 19:09:19.609 > general: error: dns_rdata_fromtext: buffer-0x42200470 : near > '10.100.60.256': bad dotted quad > Aug 16 20:00:02 named named[4169]: 16-Aug-2011 22:00:02.649 > general: error: $GENERATE: Domain/test.example.edu:1496: bad > dotted quad > Aug 16 20:00:02 named named[4169]: 16-Aug-2011 22:00:02.649 > general: error: zone test.example.edu/IN: loading from master > file Domain/test.example.edufailed: bad dotted quad It's not the same error. You can create PTR names and values of anything you want. But the value for an A record is limited to the set of valid IPv4 addresses. Note that your A $GENERATE was quite happy until it reached 256. 4294967295.60.100.10.in-addr.arpa. IN PTR 10-100-60-4294967295.dhcp-bl.indiana.edu. -222.60.100.10.in-addr.arpa.IN PTR 10-100-60--222.dhcp-bl.indiana.edu. Those are both valid, as was the entire $GENERATE range. 10-100-60-255.dhcp-bl.indiana.edu. IN A 10.100.60.255 10-100-60-256.dhcp-bl.indiana.edu. IN A 10.100.60.256 First one is valid, second one is not. That said, I wouldn't have thought that a $GENERATE range could go "over the top" like that, so to speak. I could see calling that a possible bug. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ 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 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. -- ___ 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: RFC 1918 error clarification
On 17.08.11 14:31, Morgan Toal wrote: I would like to clarify something. I have 14 locations each using a private class c address, and a single dns server which I have just moved from bind8 to bind9. I am getting a lot of these: Aug 17 13:33:13 mail2 named[18610]: client 192.168.16.3#55546: RFC 1918 response from Internet for 108.21.168.192.in-addr.arpa Aug 17 13:33:35 mail2 named[18610]: client 192.168.16.3#38729: RFC 1918 response from Internet for 171.1.168.192.in-addr.arpa where: 192.168.16.3 is the dns server and: 192.168.21.108 and 192.168.1.171 are clients on my network So what I need to do, then, is create a reverse zone file for each of my 14 internal subnets and reference these in /etc/named.conf, is that correct? Is there no way I could somehow tell bind to combine all these into a single reverse zone file? you can of course define 168.192.in-addr.arpa and put everything there. the problem above looks like client with IP 192.168.16.3 asked the named on server mail2 for 108.21.168.192.in-addr.arpa and 171.1.168.192.in-addr.arpa and got the responses from the internet. You should serve those zones locally... -- 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. ___ 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: rndc: 'addzone' failed: permission denied
Frank Bulk wrote: > Would be nice if the error output or log would indicate such failures. Yes, indeed! Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Variable 3 or 4, becoming northwest 4 or 5 later in Dogger. Slight, occasionally moderate in Forties and Dogger. Showers. Moderate or good. ___ 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