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.
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.
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.
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
They started yesterday evening here but we're only seeing it on some of
the name servers.
Brian Bruns 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.
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.
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.
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
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.
Doh! knew I should have checked 