stephane, you make a very important distinction: > Stephane Bortzmeyer <mailto:bortzme...@nic.fr> > Saturday, October 25, 2014 2:03 AM > On Mon, Oct 20, 2014 at 06:10:08PM -0700, > Paul Vixie <p...@redbarn.org> wrote > a message of 383 lines which said: > >> there are three points in the dns communication mesh where surveillance >> is possible: > >> 1. stub to recursive >> 2. recursive to authoritative >> 3. zone maintainance > > I am not happy with this list because it mixes two different types of > attackers (see RFC 6973, section 3.1, for terminology, and the > difference between attackers and observers): for #1, the DNS traffic > can be observed by a third-party sniffing the wire, or by the > recursor's operator. ... as a matter of responsible disclosure, the IETF should note well and publish widely the fact that a recursive name server operator receives incredibly high insight into a stub resolver's operator's activities. this risk begs for DNS RDNS privacy statements (google dns has a privacy policy for example, but so should opendns and all ISP's).
witnessing re-use events and end-user IP is how many security companies build their maps of who is infected with what, and which botnets are spreading where and how fast. this can be done responsibly, but is also a very attractive surveillance opportunity for commercial or political oppression purposes. RDNS users should be encouraged to only use RDNS servers whose operators and whose privacy policies they trust. and, as previously stated, we need to secure the last mile (stub-to-recursive) so that no third party has surveillance powers. finally, as previously stated, i would be alarmed to see changes proposed to the DNS itself that somehow caused RDNS operators to see only opaque data. the solution to RDNS operator surveillance is: use only an RDNS service you trust. note, i am not subscribed to dns-privacy@, other than to have posting rights there. so cc me on anything you want me to see. -- Paul Vixie
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
