Re: [DNSOP] Trusting what you see - was Re: [Ext] Re: Call for Adoption: draft-wkumari-dnsop-extended-error

Petr Špaček <petr.spacek@nic.cz> Mon, 07 August 2017 10:52 UTC

Return-Path: <petr.spacek@nic.cz>
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 B0A9A13219C for <dnsop@ietfa.amsl.com>; Mon, 7 Aug 2017 03:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 jfpN91cFXl93 for <dnsop@ietfa.amsl.com>; Mon, 7 Aug 2017 03:52:20 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 90A061320B5 for <dnsop@ietf.org>; Mon, 7 Aug 2017 03:52:18 -0700 (PDT)
Received: from [192.168.1.76] (unknown [77.236.194.38]) by mail.nic.cz (Postfix) with ESMTPSA id D4BCF622A7 for <dnsop@ietf.org>; Mon, 7 Aug 2017 12:52:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502103136; bh=rIVldHMtyESKRSyUtsOfa4w5o3/VNCtYdNx3kI+coNE=; h=To:From:Date; b=WzWkZqaMMPqg27YZnea3M9BItuabAW090bgM2nANzBjQdEdISiprbbzJxvBgeeXUJ oc31co4hUVcfYGxSEGWvNlzvVeO4xvRRPMxvAeXBeRHyDhiJAztV6qtzjvW5Ysd74n ugyzPVQuBz9g0VDCkT8jM9LSXaJXcLDbenA28yuw=
To: dnsop@ietf.org
References: <FEF74B9E-3841-4CEF-9005-187FB9927BC9@icann.org>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <52fe314c-7dfa-150c-a6aa-463776e9106d@nic.cz>
Date: Mon, 7 Aug 2017 12:52:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <FEF74B9E-3841-4CEF-9005-187FB9927BC9@icann.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XrTzh497MzpUOmyK9EU6RAp58Bc>
Subject: Re: [DNSOP] Trusting what you see - was Re: [Ext] Re: Call for Adoption: draft-wkumari-dnsop-extended-error
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 07 Aug 2017 10:52:23 -0000


On 2.8.2017 16:56, Edward Lewis wrote:
> On 7/29/17, 06:06, "DNSOP on behalf of Shane Kerr" <dnsop-bounces@ietf.org on behalf of shane@time-travellers.org> wrote:
> 
>> ...
>> I'm happy with error codes that are informational, but don't change client behavior. Yes, I realize that users may be tricked, but that's also the case today, right? 
> 
> If a receiver can't trust what it gets from the network, you can't run a protocol.  Dead in the water.
> 
> No matter what, what a receiver does next will depend on what it gets from the network (or doesn't get/timeout).  That happens now, in an unmanaged way.  IMHO, it would be good to address that (the reactions, as opposed to elaborating on the error).
> 
> If you are worried about having trustable error codes, think of a way to secure the channel (like TSIG).  If you are worried and can't secure the channel, then it doesn't matter whether RCODES are extended or not - you have nothing trustable to act upon.  (See: dead in the water.)
> 
> Once you have faith that there's usefulness in the error/response code you do receive, then you can design what the reaction is.  (If you are worried, you need to do what is necessary to build the faith or this will not be solvable.)
> 
> I sent a long message urging that the response indicate the next step, not so much indicating what went bad.  I won't belabor that - my motivation comes from the observation that many folks are used to "debugging" DNS via query/resposnse as they are not the authorized operator of the answering system.  Extending RCODEs should be about solving the protocol's needs, not about preserving the ability of remote debugging of servers, leave that to the authorized operator.

I very much agree with Edward!

To be more specific, I think we should aim for set of information which
helps the user to to decide who to contact:

a) contact local support / fix his local system
(e.g. system time is likely off and validation fails for this reason)

b) contact ISP support
(e.g. local forwading cache is not able to contact recursor)

c) contact domain owner, e.g. bank
(e.g. all the NSes are timing out)

-- 
Petr Špaček  @  CZ.NIC