On Mon, Nov 11, 2013 at 07:27:25PM +0000, Wiley, Glen <[email protected]> wrote a message of 67 lines which said:
> I realize that this is obvious, but it might be worth noting that > there is often (typically) a network connection made to the subject > of a DNS query sent from a stub resolver. For example after sending > a query for www.example.com I am likely to make a connection via TCP > to the address returned. This fact reduces the value of obscuring > DNS queries That's one of the reasons that I mentioned other practices such as having a local resolver (with caching) to limit the number of actual outgoing queries. When it comes for privacy, it is very unlikely that *one* technical solution will plug all the leaks. We have to deploy a consistent set of anti-surveillance measures. Another thing, not yet mentioned in the draft, would be to send dummy queries from time to time, requests you're not interested in, just to blur the patterns. > then they will see outbound connections to www.example.com and so it > doesn't really matter whether they were able to see the DNS query. Read the draft again (section 3.2). For instance, the manager of the TLD .example sees the DNS requests coming in his name servers but typically cannot tap the TLS traffic to www.something.example. > While I agree with the sentiments in this section, is this in scope for > this draft? Yes, it is. We have seen already malwares who modifies the DNS resolvers to a server which, apparently does not lie. The only explanation I can find is that people want to spy on DNS traffic. > Section 6.1 > > It feels as though this section dives into the solution rather than the > problem. At the beginning of this draft, it was only about problem statement. Some people feared it would not be taken seriously if it never mentioned at least possible solutions. (After all, knowing a problem for which there is no solution is depressing.) May be in the future, this draft should be split in two, problem statement and best practices to limit DNS leakage. But, IMHO, it is too early in the discussion to say so. In practice, solutions would probably require several RFC since some are only practices (having a local caching resolver), some require change in software but not in protocol (sending only NS queries to the authoritative servers) and some require new protocols (encrypting DNS traffic). _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
