Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Paul Wouters <paul@nohats.ca> Fri, 08 March 2019 17:03 UTC
Return-Path: <paul@nohats.ca>
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 4A6381279A2 for <dnsop@ietfa.amsl.com>; Fri, 8 Mar 2019 09:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 FaRQ9tAheJSe for <dnsop@ietfa.amsl.com>; Fri, 8 Mar 2019 09:03:34 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 1A90A1279AD for <dnsop@ietf.org>; Fri, 8 Mar 2019 09:03:34 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44GDNK5WW0z38y; Fri, 8 Mar 2019 18:03:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552064609; bh=4+OFNxwEWTCdfQque/IYfts3Is27UcXI46q+F/iwLmA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=p5y437d4ENK0hjKkoDeNQAFAE6YR6VBbbSq6IRqB3ykpwhvUNTouu/NUtr1G0Ixrp N7Lb6n0ghcVJ1jCi0AasJzF4zIeWQ/sjzX2gAvC1pXADEu7wAbaakjR4ELwRaLECCw 59t9dTS2Cls/zneD5I4nAoZRxLE8dbqfxt7wQ2jY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vPvPjvcnDBMI; Fri, 8 Mar 2019 18:03:28 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 8 Mar 2019 18:03:28 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8A95F5C856; Fri, 8 Mar 2019 12:03:27 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8A95F5C856
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 829FC411602B; Fri, 8 Mar 2019 12:03:27 -0500 (EST)
Date: Fri, 08 Mar 2019 12:03:27 -0500
From: Paul Wouters <paul@nohats.ca>
To: Ray Bellis <ray@bellis.me.uk>
cc: dnsop@ietf.org
In-Reply-To: <e07b94d6-d974-4e4f-5519-a90cc0e98979@bellis.me.uk>
Message-ID: <alpine.LRH.2.21.1903081154310.30421@bofh.nohats.ca>
References: <155171606493.5281.3957934874516100450.idtracker@ietfa.amsl.com> <5c3cc3f9-2225-9077-fb9e-0fb940bd1c1b@isc.org> <yblef7mp7io.fsf@wu.hardakers.net> <CAKW6Ri5doXL=uBpEy3Eqrkoyfu9rvt9upH9qxXkzZKUgS_=dMw@mail.gmail.com> <ybla7iap5nx.fsf@wu.hardakers.net> <B137690E-8063-4416-BFE2-706F0589AD5F@isc.org> <yblsgw125x4.fsf@w7.hardakers.net> <40758bbd-5289-8e21-8043-3c3d09c6b8d1@nic.cz> <bd27789a-e6f8-adca-874f-a4c298f0891f@bellis.me.uk> <alpine.LRH.2.21.1903072249100.7137@bofh.nohats.ca> <5f06e2ad-3710-4dbf-3c04-ca31f8b19c4a@bellis.me.uk> <alpine.LRH.2.21.1903080916520.20997@bofh.nohats.ca> <e07b94d6-d974-4e4f-5519-a90cc0e98979@bellis.me.uk>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/S_TwtIDEjO6mCtaCQx1PhDJvgEc>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
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, 08 Mar 2019 17:03:36 -0000
On Fri, 8 Mar 2019, Ray Bellis wrote: [my last email in this thread. I don't think we are progressing and I'd like to give others a chance to participate in this thread. But feel free to reply] >> But assigned and left completely opague is not really suitable for >> "heterogenous off-the-shelf software". These different vendors must >> understand the meaning of the opaque data even if their functionality >> can be non-standard. > > No, it does *not* require that at all. Unless the implementations just log these numbers, they are expected to do or trigger something. Either with their own interpretation, or by some helper process or configuration magic interpreting these things for them. > We very careful referred to the *operators* of the software in the draft, not > the implementors. That's just talking around the issue. You expect bind or knot or unbound or a DNS load balancer to cause an act to happen based on these transmitted values. > The intention is that software operators can define rules in their > configuration files such that *they* determine which values have what > meaning. And my argument has been that this is bad DNS design not enhancing interoperability, and that you should just more narrowly define the actual things you are trying to do instead of bitbanging them into opaque data. That way, interoperable RFCs and software can be written. > In the load-balancer case, they might decide to use a few bits to select one > of several RPZ feeds, or perhaps a view, without having to pass the client IP > for the use a "source match" ACL to the backend. > They might decide to use another bit to indicate that the client is trusted > such that the server doesn't need to apply RRL. Specify seperate options and drafts for those use cases. It is better for the entire community. > Granted this will need some form of representation in whatever configuration > syntax is in use, but that would be implementation dependent. The minimal > implementation would just need to be able to test "tag & mask == value". This is the wrong way of getting independent implementations to interoperate. Additionally, as you pointed out yourself, opague data can be abused for nefarious purposes wile still claiming protocol compliance. By narrowly specifying things, abusing those values at least forces those implementations to violate the DNS protocol. Paul
- [DNSOP] Fwd: New Version Notification for draft-b… Ray Bellis
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Paul Hoffman
- Re: [DNSOP] Fwd: New Version Notification for dra… Ted Lemon
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Paul Hoffman
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Ted Lemon
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] Fwd: New Version Notification for dra… Wes Hardaker
- Re: [DNSOP] Fwd: New Version Notification for dra… Dick Franks
- Re: [DNSOP] Fwd: New Version Notification for dra… Wes Hardaker
- Re: [DNSOP] Fwd: New Version Notification for dra… Mark Andrews
- Re: [DNSOP] Fwd: New Version Notification for dra… Dick Franks
- Re: [DNSOP] Fwd: New Version Notification for dra… Dick Franks
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Wouters
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Paul Hoffman
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Paul Wouters
- Re: [DNSOP] Fwd: New Version Notification for dra… Wes Hardaker
- Re: [DNSOP] Fwd: New Version Notification for dra… Wes Hardaker
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] Fwd: New Version Notification for dra… Dick Franks
- Re: [DNSOP] Fwd: New Version Notification for dra… Shane Kerr
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] Fwd: New Version Notification for dra… Dick Franks
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] Fwd: New Version Notification for dra… Tony Finch
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] Fwd: New Version Notification for dra… Petr Špaček
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] [Ext] Fwd: New Version Notification f… Peter van Dijk
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Wouters
- Re: [DNSOP] Fwd: New Version Notification for dra… Dick Franks
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] New Version Notification for draft-be… Peter van Dijk
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Wouters
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Wouters
- Re: [DNSOP] Fwd: New Version Notification for dra… 神明達哉
- Re: [DNSOP] Fwd: New Version Notification for dra… Ray Bellis
- Re: [DNSOP] New Version Notification for draft-be… Peter van Dijk