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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
