IETF Logo Mail Archive

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

Francis Dupont <Francis.Dupont@fdupont.fr> Sun, 30 July 2017 13:39 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
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 A1845128D86 for <dnsop@ietfa.amsl.com>; Sun, 30 Jul 2017 06:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 OcCOA_HwEtwM for <dnsop@ietfa.amsl.com>; Sun, 30 Jul 2017 06:39:26 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359681275F4 for <dnsop@ietf.org>; Sun, 30 Jul 2017 06:39:26 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6UDMNd5043453; Sun, 30 Jul 2017 15:22:23 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201707301322.v6UDMNd5043453@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Evan Hunt <each@isc.org>
cc: Joe Abley <jabley@hopcount.ca>, Shane Kerr <shane@time-travellers.org>, dnsop@ietf.org, Paul Wouters <paul@nohats.ca>
In-reply-to: Your message of Sun, 30 Jul 2017 07:42:54 -0000. <20170730074253.GA33522@isc.org>
Date: Sun, 30 Jul 2017 15:22:23 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/julUz4UapAjXwDZQebfPZxeO0mQ>
Subject: Re: [DNSOP] 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: Sun, 30 Jul 2017 13:39:27 -0000

 In your previous mail you wrote:

>  But, yes, you're correct -- diagnostic information included with a
>  SERVFAIL is about as trustworthy as the AD bit, and in the absence of an
>  authentication mechanism such as TSIG, clients should not rely on it or
>  base policy on it.

=> TSIG can be in a response only if the query is signed...

Regards

Francis.Dupont@fdupont.fr

PS: I remember a similar operation vs security trade-off about IKEv2 NOTIFY
messages: in some cases it is better to get unsecure information than
no information at all because security is required. BTW in the case
of this proposal it is second order because the real/main error is
the SERVFAIL (or others but after a short study of bind9 code the first
time this idea was proposed it should be at 90% or more SERVFAILs).

v2.23.0 | Report a Bug | By Email