Nov 16 04:01:59 insomnia named[3178]: lame server on '209.250.131.24.in-addr.arpa' (in '250.131.24.in-addr.arpa'?): 24.128.1.82#53

Nov 15 15:49:19 insomnia named[3178]: lame server on 'updates.tubescan.com.darkorb.net' (in 'darkorb.NET'?): 64.21.152.7#53


Anyone know what they are? They appear a lot in my PortSentry email logs - never use to be there :/

--James

tubescan's kevin/tubedogg's web site what's it doing there ??? :)

:)

He came over to the server - think RockerGrrl nabbed him :)

--James

Originally posted by WildWayz
:)

He came over to the server - think RockerGrrl nabbed him :)

--James

LOL

Because a certain friend of ours is no longer hosting, so I told him I would host him.... cheap.... ;)

Originally posted by rockergrrl


LOL

Because a certain friend of ours is no longer hosting, so I told him I would host him.... cheap.... ;) oh i see :)

Originally posted by eva2000
oh i see :)

I'm glad you see.... :D He was looking around without success trying to find a host that met his requirements and was within his budge. I did both for him. ;)

From the bind FAQ:

uestion 4.8. What is lame delegation ?

Date: Tue Mar 11 21:51:21 EST 1997

Two things are required for a lame delegation:

* A nameserver X is delegated as authoritative for a zone.
* Nameserver X is not performing nameservice for that zone.

Try to think of a lame delegation as a long-term condition, brought about by a misconfiguration somewhere. Bryan Beecher's 1992 LISA paper on lame delegations is good to read on this. The problem really lies in misconfigured nameservers, not "lameness" brought about by transient outages. The latter is common on the Internet and hard to avoid, while the former is correctable.

In order to be performing nameservice for a zone, it must have (presumed correct) data for that zone, and it must be answering authoritatively to resolver queries for that zone. (The AA bit is set in the flags section)

The "classic" lame delegation case is when nameserver X is delegated as authoritative for domain Y, yet when you ask X about Y, it returns non-authoritative data.

Here's an example that shows what happens most often (using dig, dnswalk, and doc to find).

Let's say the domain bogus.com gets registered at the NIC and they have listed 2 primary name servers, both from their *upstream* provider:

bogus.com IN NS ns.bogus.com
bogus.com IN NS upstream.com
bogus.com IN NS upstream1.com

So the root servers have this info. But when the admins at bogus.com actually set up their zone files they put something like:

bogus.com IN NS upstream.com
bogus.com IN NS upstream1.com

So your name server may have the nameserver info cached (which it may have gotten from the root). The root says "go ask ns.bogus.com" since they are authoritative

This is usually from stuff being registered at the NIC (either nic.ddn.mil or rs.internic.net), and then updated later, but the folks who make the updates later never let the folks at the NIC know about it.

Aaaah - so any way I can stop it?

PortSentry sends me daily logs and it is making it hard to see what is a security issue in the logs because of the amount of lame server errors.

James

Originally posted by WildWayz
Aaaah - so any way I can stop it?

PortSentry sends me daily logs and it is making it hard to see what is a security issue in the logs because of the amount of lame server errors.

James

You can turn off the lame servers logging on your named.conf, however I don't know the exact syntax :(

It is probably a good idea to turn it off anyway, since it only wastes your disk space, it is probably not your fault and there is nothing you can do to fix that.

Is there anyway i can prevent the Lame Delegations?