Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 24 April 2020 02:34 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403F53A0DF4; Thu, 23 Apr 2020 19:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kfp15BDQm6Uh; Thu, 23 Apr 2020 19:34:54 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D181D3A0DF3; Thu, 23 Apr 2020 19:34:53 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03O2Ymrw007215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Apr 2020 22:34:50 -0400
Date: Thu, 23 Apr 2020 19:34:48 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Warren Kumari <warren@kumari.net>
Cc: Vittorio Bertola <vittorio.bertola@open-xchange.com>, Tim Wicinski <tjw.ietf@gmail.com>, DNSOP-Chairs <dnsop-chairs@ietf.org>, dnsop <dnsop@ietf.org>, draft-ietf-dnsop-extended-error@ietf.org
Message-ID: <20200424023448.GU27494@kduck.mit.edu>
References: <158757569995.2664.12998778065062751539@ietfa.amsl.com> <1944826400.13464.1587632654845@appsuite-gw1.open-xchange.com> <CAHw9_iKOHe0ET4p0G+gi-hZkdj-_R6JWasYmdgW6JWnkaVdUYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHw9_iKOHe0ET4p0G+gi-hZkdj-_R6JWasYmdgW6JWnkaVdUYA@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cXnpKoq0vcVdBOFjpOneaIK5WkE>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 24 Apr 2020 02:34:55 -0000

On Thu, Apr 23, 2020 at 02:14:26PM -0400, Warren Kumari wrote:
> On Thu, Apr 23, 2020 at 5:04 AM Vittorio Bertola
> <vittorio.bertola@open-xchange.com> wrote:
> >
> >
> >
> > > Il 22/04/2020 19:15 Benjamin Kaduk via Datatracker <noreply@ietf.org> ha scritto:
> > >
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > >
> > > Sections 4.16 and 4.17 have some discussion that suggests that the
> > > respective extended errors apply only to the current "local hop" of a DNS
> > > query, and thus should not be propagated by a resolver/forwarder as part of
> > > a response.  If so, this would be at odds with the discussion in Section 3
> > > that leaves such bhavior as merely "implementation dependent" (giving some
> > > MAY-level options).  I'm not sure what the intent is, here, so let's talk
> > > about whether there's anything that should change.
> >
> > Indeed, thinking at the possible use case for those error codes, it would make sense for the forwarder to forward them to the final user. Perhaps we can fix the language to make this clear? E.g., instead or "the server being directly talked to", "the server actually resolving the queries" or something like that?
> 
> Hah! Wes and I spent some time yesterday trying to figure out how best
> to answer this, and ended up with two ideas:
> 1: just remove the "being directly talked to":
> "The server is unable to respond to the request because the domain is
> blacklisted due to an internal security policy imposed by the operator
> of the server being directly talked to." -> "The server is unable to
> respond to the request because the domain isblacklisted due to an
> internal security policy imposed by the operator of the server"
> or 2: some very convoluted text...
> 
> In my view your proposed text is simple, clear, and addresses the issue...

I think it would address my concern as well ... plus all that other stuff
:)

-Ben