[dns-operations] resolvers considered harmful

[Joe Greco]

> Let me try to take care of both of these related points together:
> 
> Joe Greco <jgreco at 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 <drc at 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.

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.