Re: [dnsext] Lame Server responses

"George Barwood" <george.barwood@blueyonder.co.uk> Mon, 11 October 2010 17:50 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AEB73A6A00; Mon, 11 Oct 2010 10:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.491
X-Spam-Level: **
X-Spam-Status: No, score=2.491 tagged_above=-999 required=5 tests=[AWL=1.896, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4xRNvEKSl4Y; Mon, 11 Oct 2010 10:50:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 121983A67FE; Mon, 11 Oct 2010 10:50:21 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1P5MRX-0003l7-Mu for namedroppers-data0@psg.com; Mon, 11 Oct 2010 17:45:47 +0000
Received: from smtp-out5.blueyonder.co.uk ([195.188.213.8]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <george.barwood@blueyonder.co.uk>) id 1P5MRU-0003kh-8y for namedroppers@ops.ietf.org; Mon, 11 Oct 2010 17:45:44 +0000
Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1P5MRR-000702-PF; Mon, 11 Oct 2010 18:45:41 +0100
Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with smtp (Exim 4.52) id 1P5MRG-0004SH-Ke; Mon, 11 Oct 2010 18:45:30 +0100
Message-ID: <15C444FDEB61471D8FFC167D9CF14435@local>
From: "George Barwood" <george.barwood@blueyonder.co.uk>
To: <namedroppers@ops.ietf.org>, "Edward Lewis" <Ed.Lewis@neustar.biz>
Cc: <ed.lewis@neustar.biz>
References: <a06240801c8d8cde3e37e@[192.168.129.62]>
Subject: Re: [dnsext] Lame Server responses
Date: Mon, 11 Oct 2010 18:52:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

----- Original Message ----- 
From: "Edward Lewis" <Ed.Lewis@neustar.biz>;
To: <namedroppers@ops.ietf.org>;
Cc: <ed.lewis@neustar.biz>;
Sent: Monday, October 11, 2010 3:33 PM
Subject: [dnsext] Lame Server responses


> 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.)
> 

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

> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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?
>