On Mon, 4 Mar 2019, Ray Bellis wrote:
This new draft describes a way for clients and servers to exchange a limited amount of information where the semantics of that information are completely unspecified, and therefore determined by bi-lateral agreement between the client and server operators.
This makes me very nervous. An edge ISP DNS server could use this to mark DNS packets from certain users, and applications could use this as another cookie to track users, especially in light of endusers talking directly to open resolvers like the Quads, from within the application, bypassing the operating system.
There are known cases where bespoke implementations are using experimental EDNS option values for this purpose, for example for a front-end load-balancer to tell the server whether an incoming connection arrived over TCP or UDP (c.f. my XPF draft).
Great. And once experimenting is done, submit a draft and get a real EDNS code point. Do this as many times as you want. The idea of a limited experimental space is that you cannot rely on it to be rolled out into the wild word. That's a feature.
A goal of this draft is to assign a common EDNS code-point such that popular OSS implementations can support similar features interoperably.
I would much rather see 10 specfic EDNS code points for features, than a kitchen sink EDNS option that can be abused to send potentially dangerous tracking identifiers that we cannot distinguish from actual DNS infrastructure options. Paul _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
