At Fri, 8 Mar 2019 12:03:27 -0500 (EST), Paul Wouters <[email protected]> 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. +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 ? 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. -- JINMEI, Tatuya
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
