Stephane, >> While the pointer to the dns-privacy draft is helpful as a >> reference, I figure the introduction/background section should >> provide an introduction to the specific problem the draft is >> attempting to address and why it is a problem. > > I tend to disagree. The whole point of the reference to > draft-ietf-dprive-problem-statement is to avoid repeating. That's why > it's a normative reference.
I wasn't suggesting removing the reference, rather I was suggesting the intro/background should discuss the subset of the more general DNS privacy problem that QNAME minimization is intended to solve/help with. >> "It can be noted that minimising the amount of data sent also >> partially addresses the case of a wire sniffer, not just the case >> of privacy invasion by the servers." >> >> This probably needs a bit more explanation. If you're sniffing the >> wire, you'll see the final query for the full QNAME/QCLASS/QTYPE and >> all the intervening NS queries can simply be ignored, no? Or is the >> sniffer on a different wire? > > Yes, the sniffer may be in many places. If it is between the user and > the recursive resolver, of course, it will see everything, qname m12n > or not. But it may be, for instance, between the recursive resolver > and the authoritative name servers of a TLD. That's a very important > point of DNS privacy, and a reason why the DNS privacy issue is not > just a subset of general IP privacy issues. See section 2.4 of > draft-ietf-dprive-problem-statement-00. Right, so perhaps something like: "It can be noted that minimising the amount of data sent can reduce the exposure of the full query name to any wire sniffer that may be in the path between the resolver and any (except the last) authoritative server the resolver needs to iterate through." (or something like that)? >> "Sending the full qname to the authoritative name server is a >> tradition, not a protocol requirment." >> >> I'd actually call it an optimization, not a tradition. > > In many cases, sending the full qname degrades performance so I would > not call it an optimization. If there are cases in which sending the full QNAME degrades performance, it might be useful to document them in the draft (off the top of my head, I can't imagine non-broken cases where that would be true, but I haven't thought about it too long). The reason I'd call it an optimization is that in the case where a server is authoritative for multiple layers of hierarchy, sending the full QNAME allows that server to bypass the referrals for all intermediate layers of hierarchy and simply respond to the depth it knows. If QNAME minimization is applied, that shortcut isn't possible. > New paragraph. Does it address (at least partially) your concern? > > <t>As mentioned before, there are several ways to implement qname > minimisation. Two main strategies are the aggressive one and the lazy > one. In the aggressive one, the resolver only sends NS queries as long > as it does not know the zone cuts. This is the safest, from a privacy > point of view. The lazy way "piggybacks" on the traditional resolution > code. It sends traditional full qnames and learn the zone cuts from > the referrals received, then switching to NS queries. This leaks more > data but probably requires less changes in the existing resolver > codebase.</t> Sure. Thanks, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
