Subject: [dnsext] Lame Server responses

From: Edward Lewis <[email-masked]>
Date: Mon, 11 Oct 2010 10:33:36 -0400

It used to be that the response from a name server, in particular 
BIND, when it determined it was lame was to send a referral to the 
root.  In response to a network event a few years ago, this was 
thought to be a bad thing because it was being used to amplify the 
traffic volume for some apparently malicious intent.

At that time some software developers choose suspend the referral to 
the root response.  Today, ISC's BIND returns a response code of 
REFUSED.  UltraDNS code returns SERVFAIL.  There's no specification 
for this.

One of our customers asked us what we returned when lame and we told 
them SERVFAIL.  Paraphrasing the response "but BIND returns REFUSED".

A question to the group.  Is either SERVFAIL or REFUSED acceptable? 
I am not pushing for one-or-the-other (because no one wants to change 
code unnecessarily), nor am I wanting to debate whether one response 
is better than the other.  I'll note that UltraDNS internally did 
discuss this a long time ago and we went with SERVFAIL because we 
felt it was the most apt response, but that doesn't mean there were 
other choices.

The thing is - when we get a query that we are lame for, we want to 
tell the querier something that will stop them from trying again 
(even if just for the current query).  I think both REFUSED and 
SERVFAIL do that.

Does it matter that there is no return code for LAME?  Would an 
iterating resolver need to know this?  (Given lameness can be 
fleeting, it's not a permanent state.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?

---

From: "George Barwood" <[email-masked]>
Date: Mon, 11 Oct 2010 18:52:35 +0100

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 11, 2010 3:33 PM
Subject: [dnsext] Lame Server responses

> fleeting, it's not a permanent state.)

I agree with BIND, it seems to me that REFUSED is closest to then codes defined by the standard.
I expect either SERVERFAIL or REFUSED will work perfectly well.
I don't see any strong reason to have a specific LAME return code, so the chance of
introducing one at this stage seems practically zero, even if EDNS theoretically allows it.
Can you think of any other situation that causes REFUSED to be returned (to a normal query)?

- George

---

From: Edward Lewis <[email-masked]>
Date: Mon, 11 Oct 2010 15:21:17 -0400

At 18:52 +0100 10/11/10, George Barwood wrote:

>I agree with BIND, it seems to me that REFUSED is closest to then codes
>defined by the standard.  I expect either SERVERFAIL or REFUSED will
>work perfectly well.

 From reading the spec, neither really applies.  But I think they are 
the only two choices (from the existing pool). I.e., in REFUSED, the 
"eg" uses the word "wishes" which isn't the issue.  OTOH, SERVFAIL 
talks about name server error, which also isn't the issue.  Our bias 
was that it was a system error that caused any earnest query to go to 
a lame server, so we adopted SERVFAIL.  "Course, there's no telling 
what the right thing is for a non-earnest query (like a maintenance 
one, a probing one, a simple mistake).

>I don't see any strong reason to have a specific LAME return code, so
>the chance of introducing one at this stage seems practically zero, even
>if EDNS theoretically allows it.

Given we've lasted this long without an return code, we don't need to 
invent one now.

>Can you think of any other situation that causes REFUSED to be returned (to

AXFR?  Depends on what's normal.  A server that will only answer 
queries with specific TSIG keys?

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Oct 2010 11:30:30 +0100

On Mon, 11 Oct 2010, Edward Lewis wrote:
> From reading the spec, neither really applies.  But I think they are the only
> two choices (from the existing pool). I.e., in REFUSED, the "eg" uses the word
> "wishes" which isn't the issue.

You could view it as not wishing to / refusing to return a referral.

> OTOH, SERVFAIL talks about name server error, which also isn't the
> issue.  Our bias was that it was a system error that caused any earnest
> query to go to a lame server, so we adopted SERVFAIL.

BIND's behaviour makes a useful distinction between lame (REFUSED) and
broken (SERVFAIL).

> AXFR?  Depends on what's normal.  A server that will only answer queries with
> specific TSIG keys?

Or a recursive server that only provides service to specific networks.
Or a master server that does not permit dynamic updates.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 12 Oct 2010 08:43:07 -0400

>BIND's behaviour makes a useful distinction between lame (REFUSED) and

The problem (for both us and BIND, and everyone in general) there are at least:

"The answer failed DNSSEC"
"I couldn't follow a referral (all servers down)"
"I won't answer you (query, dynamic update, or zone management)"
"I am not properly informed" (lame)

These four cases (plus others probably) have to map into two response 
code values.  Distinctions really aren't going to be made.