Re: [DNSOP] New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

"Peter van Dijk" <peter.van.dijk@powerdns.com> Sat, 09 March 2019 15:03 UTC

Return-Path: <peter.van.dijk@powerdns.com>
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 D0F02127598 for <dnsop@ietfa.amsl.com>; Sat, 9 Mar 2019 07:03:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pPNshn8ICfvp for <dnsop@ietfa.amsl.com>; Sat, 9 Mar 2019 07:03:46 -0800 (PST)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 18F701240D3 for <dnsop@ietf.org>; Sat, 9 Mar 2019 07:03:46 -0800 (PST)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id D26C36A262; Sat, 9 Mar 2019 16:03:41 +0100 (CET)
Received: from [10.242.2.3] (unknown [10.242.2.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 8B4213C0431; Sat, 9 Mar 2019 16:03:41 +0100 (CET)
From: "Peter van Dijk" <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>
Date: Sat, 09 Mar 2019 16:03:41 +0100
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <FACD884D-FC6E-4D6F-87F0-046B82C236CA@powerdns.com>
In-Reply-To: <CAJE_bqc_a5-W+FvFGFn0p2MbQU7FJB9Qwa9Xiy1KMwNG0EUFKA@mail.gmail.com>
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> <alpine.LRH.2.21.1903081154310.30421@bofh.nohats.ca> <CAJE_bqc_a5-W+FvFGFn0p2MbQU7FJB9Qwa9Xiy1KMwNG0EUFKA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oHxiilB04xtPcZZKi8T3yykEvvQ>
Subject: Re: [DNSOP] 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: Sat, 09 Mar 2019 15:03:48 -0000

On 8 Mar 2019, at 19:33, 神明達哉 wrote:

> +1.  It's very difficult for me to imagine how we can expect that two
> "heterogenous off-the-shelf software" products can be interoperable
> just because we have a standardized EDNS option code for opaque tags.
>
> For example, assume that an operator uses dnsdist as a DNS load
> balancer and BIND 9 as backend servers with RRL, and the operator
> wants to trust particular clients (identified by their IP addresses)
> and bypass RRL for them.  How can we expect off-the-shelf dnsdist and
> off-the-shelf BIND 9 support this operation with the only assumption
> being that both of them support edns-tags?  Is there an implicit
> assumption that:
> - this version of off-the-shelf dnsdist happens to have a new
>   configuration option so it will add an edns-tag with setting bit X
>   when the client IP address matches a specified set of address list,
> - this version of off-the-shelf BIND 9 happens to have a new
>   configuration option to skip RRL if an incoming request contains an
>   edns-tag option with bit X on
> ?

Yes.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/