Symptom:

You may see in your name server logs a message about a lame response or lame delegation. (Log messages vary by name server software type and version.)

Problem:

When performing recursion, the process of looking up a record from the DNS, a name server must generally query several servers, follow up on referrals, and walk down the chain of authority to find the answer.

For each query, the recursing name server expects the other name server to be authoritative for a given zone. For example, the root servers are expected to be authoritative for the root zone. The root servers give out a referral for com, pointing to a set of servers; any such server is expected to be authoritative for com. The expected authority can be obtained either from a referral for that zone from a parent zone, or from the authority records returned by another authoritative name server for the zone.

If a query is answered in a way that indicates that the responder is not authoritative for the expected zone, the result is called lame. Since the response is almost always in the form of a referral (a delegation response) for either some zone higher up on the tree or for the expected zone itself, the response can be called a lame delegation or lame referral.

Examples

In our examples, the recursing name server will be called cache.example.net. These examples involve trying to look up an A record in the example.com zone. We’ll suppose that example.com is delegated to ns1.example.com and ns2.example.com.

Example 1

Suppose cache.example.net has nothing in cache except the list of root servers, derived by verifying its hint zone. It receives a recursive query for A records named host1.example.com.

The query that is sent by cache.example.net, every time, is for class IN, type A, name host1.example.com.

• cache.example.net queries f.root-servers.net
• a.root-servers.net sends back a referral for com
• cache.example.net queries c.gtld-servers.net
• a.gtld-servers.net sends back a referral for example.com
• cache.example.net queries ns2.example.com
• ns2.example.com sends back a referral for the root zone ← lame
• cache.example.net logs a lame delegation from ns2.example.com
• cache.example.net queries ns1.example.com
• ns1.example.com sends back an authoritative answer

Example 2

Suppose that after the previous example, cache.example.net has cached every answer it received. Further suppose that the authoritative answer at the end contained authority records pointing to ns1.example.com, ns2.example.com, and ns3.example.com.

Now suppose that another recursive query is sent to cache.example.net, this time for host2.example.com.

• cache.example.net queries ns3.example.com
• ns3.example.com sends back a referral for the example.com zone ← lame
• cache.example.net queries ns1.example.com
• ns1.example.com sends back an authoritative answer

Solution

So what can you do about a lame response message in your server’s log? Probably not much - it’s probably for a zone you don’t control. However, if the lame response is for a zone you control, then you should fix it.

If you want to notify the owner of the zone that one of his servers is lame, you may be able to find the person’s email address either through a whois query or by looking at the rname field of the zone’s SOA record.