2017-03-28 12:41 GMT-05:00 Paul Vixie <[email protected]>: > at DNSOP yesterday i asked that anyone who thought zone enumeration was > a risk and that any crypto change (such as NSEC5) could manage that risk > should please accept a free demonstration of passive dns. > > i realized that i could offer this more broadly. here is *.vix.su, one > of my vanity domains. passive dns works by storing cache miss traffic > (so there is no PII here). DNSDB, whose result is shown below, is one of > about a dozen security-community projects who aggregate these cache > misses into searchable databases. > > summary: all dns content is running naked through the forest covered in > honey. if you put something into the dns, and it gets used, then it's > going to be known. no amount of crypto on dnssec authenticated denial is > going to change that. (nor will the DPRIVE effort, since passive dns > relies on inside-the-RDNS-servers cooperation, such as for example > 'dnstap'). >
Hi Paul, I'm quite familiar with DNSDB and similar passive DNS systems and would guess that many in the DNSOP crowd are also. Some years ago, when I worked in the US R&E community, I used DNSDB to enumerate most of the .edu TLD to do DNSSEC deployment statistics and analyses. These systems see a lot, no doubt, but they are still limited to data contributed by the set of participating resolvers. And as far as I know, they aren't open to inspection by the world (usually only participating resolvers, researchers, and customers of the passive DNS service). The fact that systems like this exist, does not invalidate the desire for the DNS protocol to prevent easy "bulk disclosure" of zone content. The DNS privacy considerations RFC for example has a section that provides such arguments - the protocol queries public data, but you have to know what to query for, and mechanisms that permit mass leakage of such data are undesirable. Similarly, the fact that website observatories exist doesn't mean that the web protocol should provide a mechanism to enumerate all website names hosted at a CDN for example. Before DNSSEC, enumerating zone content was only possible by means of online queries of candidate names. NSEC and NSEC3 made that problem strictly worse (walking the NSEC chain, and offline dictionary attack of the NSEC3 chain). NSEC5 restores the pre-DNSSEC property that only online guessing works. Perhaps passive dns will become so prevalent, all-encompassing, and accessible that it isn't worth investing time in doing better than NSEC3, but let's have that discussion as a community. > nsec5 is a work of beauty and wonder. but changing the DNSSEC protocol > every two years is why we're 19 years in and still lack ubiquitous > deployment. adding more complexity would have to pay back more cost than > any new form of authenticated denial could even theoretically do. > I don't think protocol evolution can be blamed for lack of ubiquitous DNSSEC deployment. In my experience, most people who haven't deployed it, don't see any immediate compelling need for it. If cache poisoning and DNS MITM attacks were happening on a large scale (they aren't), that would act as a deployment incentive. If there were a killer app that depended on DNSSEC (perhaps DANE will be that some day down the road), that would also be an incentive. Another deployment disincentive is that DNSSEC has a generally bad rap in the larger technical community. Much of it is based on FUD and misunderstanding. But there are legitimate criticisms that we ought to be paying more attention to - DNSSEC deployment is littered with 1024-bit RSA is one. Zone enumeration obviously is another. Shumon.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
