Interesting BIND error
We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same. Seems harmless enough, but the logging is eating a disproportionate amount of cpu. Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument
From socket.c:
#undef ALWAYS_HARD /* * The other error types depend on whether or not the * socket is UDP or TCP. If it is UDP, some errors * that we expect to be fatal under TCP are merely * annoying, and are really soft errors. * * However, these soft errors are still returned as * a status. */ isc_sockaddr_format(&dev->address, addrbuf, sizeof(addrbuf)); isc__strerror(send_errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, "internal_send: %s: %s", addrbuf, strbuf); dev->result = isc__errno2result(send_errno); return (DOIO_HARD);
Once upon a time, Brian Wallingford <brian@meganet.net> said:
We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same.
I'm seeing them too (also BIND 9.2.1). They seem to come in bunches. It looks like they started at a little after 5am (CST) today. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Thu, 12 Feb 2004, Chris Adams wrote:
Once upon a time, Brian Wallingford <brian@meganet.net> said:
We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same.
I'm seeing them too (also BIND 9.2.1). They seem to come in bunches. It looks like they started at a little after 5am (CST) today.
They started yesterday evening here but we're only seeing it on some of the name servers. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Thu, February 12, 2004 4:52 pm, Brian Wallingford said:
We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same.
Seems harmless enough, but the logging is eating a disproportionate amount of cpu.
Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument
Its possible that someone is spoofing UDP packets to your nameserver from that IP range (which is IANA reserved space). It looks like BIND is refusing to send to that address, and thus the error. At least, IMHO. So I could be wrong :) -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org The AHBL - http://www.ahbl.org
At 05:31 PM 2/12/2004, Brian Bruns wrote:
On Thu, February 12, 2004 4:52 pm, Brian Wallingford said:
We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same.
Seems harmless enough, but the logging is eating a disproportionate amount of cpu.
Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument
Its possible that someone is spoofing UDP packets to your nameserver from that IP range (which is IANA reserved space). It looks like BIND is refusing to send to that address, and thus the error.
At least, IMHO. So I could be wrong :)
Someone is likely using relays.monkeys.com on their mail server which is resolving against your DNS server. It is a now defunct blacklist. They changed all their records to resolve to 244.254.254.254 in order to get people's attention and get them to stop using the service. You should filter 240.0.0.0/4 on your BIND servers anyway. Alternatively, you can just create an authoritative zone for relays.monkeys.com on your servers and leave them blank except for required records like SOA and NS. There is a small discussion going on about this on the bind9-users list and this information is strictly pulled from there. You might want to check that list out or similar ones for more information. Vinny Abello Network Engineer Server Management vinny@tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
Brian Bruns wrote:
On Thu, February 12, 2004 4:52 pm, Brian Wallingford said:
We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same.
Seems harmless enough, but the logging is eating a disproportionate amount of cpu.
Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument
Its possible that someone is spoofing UDP packets to your nameserver from that IP range (which is IANA reserved space). It looks like BIND is refusing to send to that address, and thus the error.
At least, IMHO. So I could be wrong :)
Considering the address range, I'd say it'll have problems sending there... multicast anyone? / Mat
On Fri, 13 Feb 2004 08:55:14 +1000, Matthew Sullivan <matthew@sorbs.net> said:
Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument
Considering the address range, I'd say it'll have problems sending there... multicast anyone?
Multicast ends at 239.255.255.255, unless somebody dorked with the RFCs while I wasn't looking, and failed to update the listing at http://www.iana.org/assignments/ipv4-address-space while they were at it.
Valdis.Kletnieks@vt.edu wrote:
Multicast ends at 239.255.255.255, unless somebody dorked with the
RFCs while I wasn't looking, and failed to update the listing at http://www.iana.org/assignments/ipv4-address-space while they were at it.
Doh! knew I should have checked ;-)
Brian Bruns wrote:
On Thu, February 12, 2004 4:52 pm, Brian Wallingford said:
We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same.
Seems harmless enough, but the logging is eating a disproportionate amount of cpu.
Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument
Its possible that someone is spoofing UDP packets to your nameserver from that IP range (which is IANA reserved space).
That's the old Class E space. Definately not routed over the Internet.
It looks like BIND is refusing to send to that address, and thus the error.
Or the OS is. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
On 12 Feb 2004, at 16:52, Brian Wallingford wrote:
We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same.
Seems harmless enough, but the logging is eating a disproportionate amount of cpu.
I'm not a BIND developer, and I don't have a good answer to your question. However, it may be worth mentioning that the most recent production release of BIND 9 was version 9.2.3; while you're spending cycles wondering what's up with your 9.2.1 install, you might as well burn a few more and upgrade :-) Joe
Brian Wallingford wrote:
Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error:
Hmm. A few weeks ago I started noticing some similiar messages that I had not ever seen before: Jan 29 18:21:52 named[658]: socket.c:1100: unexpected error: Jan 29 18:21:52 named[658]: internal_send: 210.22.158.126#39254: Connection reset by peer Jan 29 18:21:53 named[658]: client 210.22.158.126#39254: error sending response: connection reset On closer examination I could see that the remote client was attempting DDNS updates to a zone that server was auth for. It started Jan 29 03:19:39 MDT and then mysteriously ended Jan 31 11:06:11 MDT which I thought was a little odd. Usually someone sticks a domain name that they like (but have no real relationship to) into their Microsoft TCP/IP stack's domain name field and it tries to do it's Active Directory update thingy forever (we have 'clark.com' which is lots of fun). So once a client starts sending us updates, it's not likely to ever stop. FWIW, only a small percentage of the updates were generating this error.... # grep -c '210.22.158.126.*denied' messages.2 1375 # grep -c socket.c messages.2 24
On Thu, 12 Feb 2004 18:54:10 MST, Mike Lewinski <mike@rockynet.com> said:
FWIW, only a small percentage of the updates were generating this error....
# grep -c '210.22.158.126.*denied' messages.2 1375
# grep -c socket.c messages.2 24
Your kernel probably distinguishes between attempted sending to the class A/B/C space unicast addresses, the class D multicasts, and the martian zone above the class D space, and generates diferent errors for the three cases.
participants (10)
-
Brian Bruns -
Brian Wallingford -
Chris Adams -
Crist Clark -
jlewis＠lewis.org -
Joe Abley -
Matthew Sullivan -
Mike Lewinski -
Valdis.Kletnieks＠vt.edu -
Vinny Abello