[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] lame server
- Subject: Re: [cobalt-users] lame server
- From: elmer@xxxxxxxxxxxxxx
- Date: Thu Feb 1 22:29:52 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
On Fri, 2 Feb 2001, Diana Brake so wrote:
} I wonder about these things too...but I'm skeptical about this being a hack
} attempt. I also got an entry from verio.net similar to yours in my logs. In
} the past, I've gotten many "lame server" messages that appeared to be
} related to a cobaltlist user and there have been many times I've come close
} to asking onlist if there was someone who knew something about some lame
} domain, or did they use such-and-such host because it was throwing lame
} messages out.
For the most part the reality of these type of error
messages is that they are indicative of a poorly or improperly
configured name server. Worse yet, the misconfiguration is not
necessarily the fault of the servers administrator. Anyone can add
any name server on the Internet to their domains record and if the
administrator of that name server is not notified or is not willing
to handle the zone the result will be a lame server message in your
servers log anytime a lookup is conducted for that domain. Seeing
your DNS servers name listed as a lame server means that someone
somewhere has it listed as authoritive for their domain and you
either didn't correctly configure your server to support it or they
never bothered to tell you. That's really all there is to it. Yes an
exploit attempt coming in on a spoofed IP address or Domain Name may
result in the creation of such a message but that does not change
what they are - nothing much to worry about.
While Cobalt's GUI may have something to say about this (I
don't run DNS on our Cobalts so I can't say for sure), Bind provides
the ability to see or not see these messages via the, you guessed
it, 'lame-servers' system log category. The definition of the
'lame-servers' category pretty well sums things up; "Detection of
bad delegation". By default Bind writes out all error messages but
one can configure logging so that lame server messages will not be
written.
Perhaps the lame server error message is best described by
the quote used when explaining what these messages are indicative
of in DNS and Bind - the book; "Aye, Captain, she's sucking mud!".
While sucking mudd is not a lot of fun, it's certainly no
reason to call in a forensic team...