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

Ray Bellis <> Fri, 08 March 2019 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C787A12716C for <>; Fri, 8 Mar 2019 13:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DDO8IjQTzgwX for <>; Fri, 8 Mar 2019 13:21:25 -0800 (PST)
Received: from ( [IPv6:2a03:9800:20:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9D97126DFA for <>; Fri, 8 Mar 2019 13:21:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ataVsnwgUVlpilrEW+mo6ESlKKeF8oOfX3EHGenO9hI=; b=IhQko4SS/gqi6JD4OiRmbqTHeC WmdD620MGpT+A95aLiIkYt7fU8bD3jK/e1wdynQ2k5QeX+TIndl+kYz7ocPdt0ZP5Se8MshrvmCEI iWxE2fLu+28HPiLxAL8oGUA6HjMpTM6vsdNdGCp2pqJjlMnnRIZERjaADb8ctbMcKQJg=;
Received: from [] (port=55085 helo=Rays-MacBook-Pro.local) by ([]:465) with esmtpsa ( (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1h2Mvj-0003IP-C9 (Exim 4.89) for (return-path <>); Fri, 08 Mar 2019 21:21:23 +0000
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Ray Bellis <>
Message-ID: <>
Date: Fri, 8 Mar 2019 21:21:22 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Mar 2019 21:21:29 -0000

On 08/03/2019 18:33, 神明達哉 wrote:

> 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,

Yes, that's feasible (and from dicussions I've had with them I think 
it's not just feasible but extremely likely).

> - 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, that is also completely feasible.  I would expect (at some point) 
that BIND would offer the ability to use a tag comparison as part of an 
`address_match_element` that could then be used like so:

   rate-limit {
     exempt-clients { ... };

> At this moment I don't have a strong opinion on the proposal itself,
> but the "off-the-shelf software" argument doesn't sound very
> convincing or realistic.  Perhaps I miss some implicit assumptions, in
> which case I'd like the draft to explain these in more detail.

The next version has this text:

"The intended mode of operation is that the value of a bit (or range of
bits) could be tested in access control lists or any other such policy
control mechanism."

I'm open to elaborating on this a little more in the draft, but it would 
be a shame for the draft to lose its current succintness.