In message <20141023010708.28bf611fc...@lawyers.icir.org>, Mark Allman writes: > Let me try to take care of both of these related points together: > > Joe Greco <jgr...@ns.sol.net>: > > Then we merely move on to the issue of cache poisoning individual > > clients. > > > > Assuming that the CPE is a NAT (effectively firewalling clients from > > poisoning attacks) and/or that the individual clients have well- > > designed, impervious resolvers is likely to be a fail. > > David Conrad <d...@virtualized.org>: > > As I understand it, you're proposing pushing the resolvers out to the > > edges > > That is not what we are proposing. We are not suggesting resolvers be > *moved*, but rather *removed*. That is, clients simply do name lookup > on their own. > > Name lookup at an endpoint is different from name lookup in an > intermediate resolver. > > An intermediate resolver looks up a name on behalf of other hosts. It > therefore *must* listen for lookup requests that roll in from the > network. This is fundamental to a resolver's operation---it simply > *must* accept requests from other hosts. Don't get me wrong.... it > doesn't have to accept all requests and as we know, too many resolvers > accept requests they should not. All I am saying is that the resolver > cannot do its job without accepting requests from other hosts. > > On the other hand, an endpoint can look up a name without listening for > any request from the network. We suggest this be an entirely local > operation. Think of it like this: just because I want to load the > cnn.com web page I don't have to run httpd. Well, just because I want > to look up an A record for cnn.com doesn't mean I have to run bind.
Firstly it isn't "bind" it is "BIND". Secondly why not run BIND? It works fine only listening on 127.0.0.1 and ::1. It actually does do DNSSEC validation and everything else you would want a iterative resolver to do with sensible defaults. options { listen-on { 127.0.0.1; }; listen-on-v6 { ::1; }; dnssec-validation auto; directory "/var/named"; }; It also isolates all your clients from the big bad world of broken authoritative servers. It's also easier to upgrade than every application that makes a DNS lookup. > Could there be attacks against the internal lookup process on a host? > Of course. But, those are attacks that require some sort of access to > the end host first. > > David Conrad <d...@virtualized.org>: > > if you're not doing DNSSEC at the edges, > > Let me be clear.... I am not arguing against DNSSEC. A crypto signed > record is always better than a clear text record. But, DNSSEC is still > not here and it seems to me that factoring out some of the > intermediaries that we know sometimes both play games and have games > played on them may well be a useful path. > > allman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs