> Let me try to take care of both of these related points together: > > Joe Greco <[email protected]>: > > 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 <[email protected]>: > > 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.
I feel that this is hopelessly naive. I understand what you're saying, and I agree that in theory name lookup at an endpoint could be different than name lookup in some intermediate resolver. The problem is that on- host resolution is still likely to be handled by an existing software package, unless you're actually arguing that each individual client process should handle the entire name resolution process, which seems like it would be untenable. So what you're really talking about is taking the intermediate resolver and simply placing it on the endpoint host, at which point what you seem to have done is to multiply the number of intermediate resolvers. I'm guessing that you feel this would be okay, if it resulted in those endpoint hosts being correctly configured and not vulnerable to attack. Please correct me if I'm wrong, by the way. This ought to be fine if only localhost is allowed to resolve names (ACL) and *:53 isn't open. I think, however, that's naive. I've seen too many examples of software deployed, sometimes even in products, where obvious things that ought to have been done simply weren't. And we really don't want/need people to be reinventing the wheel, because so often it gets reinvented poorly. So, let me restate what I said originally. You might have interpreted where I said "resolver" as meaning "intermediate resolver." It does not mean that. It means the bit of code, whereever located, that traverses the tree. We've been running resolvers on each host here since the days of BIND4, in forwarding-first mode, so I've got familiarity with the advantages to an environment that's got the advantages of both strategies. When this sort of stuff is deployed automatically by scripts by people who have been doing DNS since the '80's it isn't a problem. What I see, though, is an opportunity for much badness. Right now we have a handful of resolvers at some service provider plus a thousand customers with crappy dnsmasq-using CPE, plus fifty thousand customers with non-DDoS-generating DNS techniques (traverses the NAT to the ISP resolver, correctly-configured dnsmasq, BIND, whatever). So right now the average customer probably has half a dozen connected devices, including computers, printers, VoIP, tablets, and mobile phones. That's only going to grow, and it is going to be ever more diverse. And we're moving towards IPv6 - with all those endpoints potentially being accessible directly from the Internet. To me, what that really says is that eventually, instead of 51000 customers online with 1000 vulnerable resolvers, we're going to have far more than 300,000 (51000 * 6) devices online. My guess is that far more than 1000 of those devices will not be up-to-date with the latest code available. And instead of merely having to deal with 2% of your customer base (the 1000 with the crappy dnsmasq CPE), you're going to have to contact some unknown percentage of them. And for those devices that cannot have their software updated, because the company is no longer producing it, then you're in a bad position, because you're effectively telling your customer that they cannot use their techdevice. More likely is that you wind up with an irate and/or frustrated customer, and in all probability a bunch of them tell you to eff off. Of course that problem can be fixed, through proper design and configuration. I quite agree! But the problem is that the current state of affairs is completely fixable through proper design and configuration, yet it is still broken. I can extrapolate just how well the suggested "fix" will work. Therefore I do not believe that simply changing the location of the resolver from an intermediate host to the endpoint host is going to fix this problem; it seems to me to be a hopelessly naive solution. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
