On Wed, Feb 18, 2015 at 3:31 PM, Stephane Bortzmeyer <[email protected]> wrote: > On Tue, Feb 17, 2015 at 01:47:37AM +0000, > Mankin, Allison <[email protected]> wrote > a message of 128 lines which said: > >> However, here it is now, > > Many thanks, a lot was integrated in commit > 16c6ee5e519716142d56fb59023f01e36f195f10 > <https://github.com/bortzmeyer/my-IETF-work/commit/16c6ee5e519716142d56fb59023f01e36f195f10> > and will appear in -02. > >> "Because there is typically no caching in the stub resolver, the recursive >> resolver, unlike the authoritative servers, sees everything." >> Comment: This isn¹t quite absolute. The DNS caches in some browsers may >> impact the data collection. Also, in some enterprises, a load balancer or >> other intermediary between the stubs and the recursive might affect how >> complete the data collection at a particular recursive is. > > True but I hesitate. Since RFCs have no footnotes, adding correct > precisions like this one always risk bloating the text of the future > document. Any editorial guidance from experienced RFC authors? > >> "It should be noted that DNS recursive resolvers sometimes forward >> requests to bigger machines, with a larger and more shared cache, the >> forwarders (and the query hierarchy can be even deeper, with more than two >> levels of recursive resolvers)." >> Comment: there are forwarders before recursive resolvers as well. > > "forwarder" seem poorly defined. See draft-hoffman-dns-terminology-01 > and > <http://mailarchive.ietf.org/arch/msg/dnsop/SDTdFyl7Fg1iMxX734tOPNz94mY> > >> "A note about IP addresses: there is currently no IETF document which >> describes in detail the privacy issues of IP addressing." >> Comment: This overlooks RFC 4941, which is all about the privacy issues of >> IP addresses (IPv6). > > May be rather > <http://www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-addresses-privacy-review.txt>, > which is broader? > >> "Since this [cache snooping] also is a reconnaissance technique for >> subsequent cache poisoning attacks, some counter measures have >> already been developed and deployed." >> Comment: A reference would be helpful here. > > Agreed. WG, any suggestion? > >> "As of today, all the instances of one root name server, L-root, receive >> together around 20,000 queries per second. While most of it is junk >> (errors on the TLD name), it gives an idea of the amount of big data which >> pours into name servers." >> >> Comment: this needs a reference. > > ICANN Web server says "The website you are trying to view is currently > undergoing maintenance" so I will search a reference later. >
Not sure if this would be a useful reference, but: http://hedgehog.dns.icann.org/hedgehog/hedgehog.html Claims more lik 40kqps, and ~27kqps of NXD. W >> "Also, it seems (TODO: actual numbers requested) that there is a strong >> concentration of authoritative name servers among ³popular" domains (such >> as the Alexa Top N list). With the control (or the ability to sniff the >> traffic) of a few name servers, you can gather a lot of information.² >> Comment: Is this based on the paper by Bala Krishnamurthy and Craig Wills >> in IMC 2006?, ³Generating a Privacy Footprint on the Internet² >> http://www2.research.att.com/~bala/papers/pfp-imc06.pdf? > > No. It's an unpublished survey. > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
