On Sat, Jan 03, 2015 at 11:17:13AM -0800, David Conrad <d...@virtualized.org> wrote a message of 120 lines which said:
> Some comments on the qname-minimisation draft: Many of them integrated in the live text at <https://github.com/bortzmeyer/my-IETF-work/tree/master/draft-ietf-dnsop-qname-minimisation> Expect a new release next week. > 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. > "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. > "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. (Apparently, there is no published rationale for this choice.) > "On the other hand, it will decrease their legal responsability, in > many cases." > > I'm not sure it's worth raising this as "legal responsibility" in an > engineering document sounds like a 'rathole of unusual size' to me. I'm inclined in that direction, too. What is the advice of the working group? Are there examples of RFCs with such "legal" mentions? > 'As an example of today, look at www.ratp.fr (not ratp.fr), which is > delegated to two name servers that reply properly to "A > www.ratp.fr" queries but send REFUSED to queries "NS www.ratp.fr".' > > I suspect this particular brokenness will be fixed at some point in > the future, thus I doubt this example will be useful. Right for a RFC, which must be stable. I rewrote it (with a note about www.ratp.fr, to be deleted before publication: in an Internet-Draft, I think actual examples are good). > 'For such a name, a cold resolver will, depending how qname > minimisation is implemented, send more queries.' > > It might be useful to go discuss ways in which qnames can be > implemented. 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> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
