On 05/03/2019 01:44, Paul Wouters wrote:
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.
This is why the specification limits the data to a mere 16 bits.
Granted that this might permit more fine-grained "finger printing" when
combined with other meta data but the intention is that _by itself_ it's
insufficient to carry any PII (at least not unless your total number of
clients is < 2^16).
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.
It's not a feature, it's a bug. These internal experiments almost never
see the light of day, and as a result are unsupportable in e.g. BIND,
instead relying on internal patches (which are fragile) or bespoke
implementations (that are often protocol non-conformant).
Meanwhile we have customers who would like to deploy some kind of packet
tagging but find that the only "blessed" option that kinda fits their
needs is EDNS Client Subnet. No thanks!
Ray
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
