Re: [DNSOP] ECS badly formatted ADDRESS field

Paul Vixie <vixie@tisf.net> Wed, 30 December 2015 22:28 UTC

Return-Path: <vixie@tisf.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0209B1B29C3 for <dnsop@ietfa.amsl.com>; Wed, 30 Dec 2015 14:28:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level:
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxQh7UlvJvoD for <dnsop@ietfa.amsl.com>; Wed, 30 Dec 2015 14:28:48 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798111B29BF for <dnsop@ietf.org>; Wed, 30 Dec 2015 14:28:48 -0800 (PST)
Received: from linux-85bq.suse (unknown [24.104.150.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 5A46E1814C; Wed, 30 Dec 2015 22:28:48 +0000 (UTC)
From: Paul Vixie <vixie@tisf.net>
To: dnsop@ietf.org
Date: Wed, 30 Dec 2015 14:28:48 -0800
Message-ID: <3985237.IbNEhXfZM9@linux-85bq.suse>
Organization: TISF
User-Agent: KMail/4.14.10 (Linux/4.1.13-5-default; KDE/4.14.10; x86_64; ; )
In-Reply-To: <CAJE_bqdesZpOS7v1+Y3m2SjxzuNm=34rQmOhuhjUihhjK82qvA@mail.gmail.com>
References: <20151224023114.GA2748@jurassic.l0.malgudi.org> <CAJE_bqdesZpOS7v1+Y3m2SjxzuNm=34rQmOhuhjUihhjK82qvA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart4131290.XFbiNM7f3c"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/nInb2jFTrqPDyFylnwGGj25iETU>
Cc: Mukund Sivaraman <muks@isc.org>
Subject: Re: [DNSOP] ECS badly formatted ADDRESS field
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Dec 2015 22:28:50 -0000

On Wednesday, December 30, 2015 04:14:07 PM 神明達哉 wrote:
> At Thu, 24 Dec 2015 08:01:14 +0530,
> 
> Mukund Sivaraman <muks@isc.org> wrote:
> > https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-06
> > 
> > says in Section 6. Option Format:
> > >   o  A server receiving an ECS option that uses more ADDRESS octets
> > >   
> > >      than are needed, or that has non-zero bits set beyond SOURCE
> > >      PREFIX-LENGTH, SHOULD return REFUSED to reject the packet, as a
> > >      signal to the developer of the software making the request to fix
> > >      their implementation.
> > 
> > FORMERR seems more appropriate than REFUSED for an implementor to notice
> > format issues, and perhaps this has been raised on this list already. If
> > you can change this, please change this to FORMERR.
> 
> My understanding is that it's fodder for the imaginary followup
> standard document (whether it's FORMERR or something else may still be
> debatable, but should at least be something other than REFUSED).  I
> believe you can find the discussion that led to this conclusion in the
> ML archive (I didn't like it either but that seemed to be the "rough
> consensus").

if the intent is to document existing practice and existing implementations send REFUSED in 
this situation, then the document should say that. but the document should also say that 
FORMERR is the correct signal.

REFUSED means that some other name server might be willing to process the query. 
FORMERR means that no name server could process this query.

-- 
P. Vixie