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

[Ray Bellis <[e-mail]>]

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.

Ray