>It occurs to me that it introduces knobs that might not work, since the >easiest way to implement it is to accept the EDNS0 options, ignore them, >and do whatever you were doing anyway. (This isn't a new issue; see RFC >8689, the SMTP require TLS option, which I've implemented the same way.)
I don't understand the threat model here. The local DNS proxy that implements this draft is on the same system as the application. The proxy either comes with the operating system or is explicitly installed by the user of the host. Who benefits from a fake implementation? It seems weird to argue against a draft with the argument that it may intentionally be implemented wrong. >Since we all seem to agree that there are already plenty of ways to tell >devices what kind of upstream cache to use, what's the benefit of adding >another one that as likely as not wouldn't work? Yes, there are ways for the network to inform a device. I don't any options for a local proxy to inform a stub resolver. Or for the local proxy to know what the application really wants of needs. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
