maybe a dumb idea on how to fix the dns problems i don't know....

Mon Aug 11 02:35:58 UTC 2008

> > I think that the text I wrote clearly assumes that there IS only one
> > connection per resolver instance.  The problem is that hostname to IP
> > lookup is pervasive in a modern UNIX system, and is probably pretty
> > common on other platforms, too, so you have potentially hundreds or
> > thousands of processes, each eating up additional system file descriptors
> > for this purpose.
> 
> Well how I read what you first wrote implied that the resolvers are now 
> going to DOS servers with millions of connections due to each resolver 
> stub making a TCP connection...  I say this is something that if true, 
> can and should be changed.

Sure.  We can introduce a new feature, called a "local recurser," which
will do unified name resolution for all lookups asked for by any process
on the box.

Now, of course, the box enjoys certain benefits, such as being able to
remember who "MX nanog.org" is for the second time without having to 
bother an external recurser.  And a hypothetical ability to forward all
requests via TCP to the external recurser.  Except, why bother, now that
you have the capability right on the box, why be dependent on anything
else?  Might as well just let it resolve all by itself.

Of course, the box also enjoys certain other liabilities, such as the 
next time that all the name servers in the world need to be upgraded,
you now have just that many more recursers that are running on unattended
autopilot (because heaven knows, most PC's run without a professional
admin to keep things up to snuff, and this last problem wasn't exactly
the sort of thing you can just "auto update," because someone actually
has to verify that there aren't externalities such as NAT devices, etc!)

Sounds like a real fun time.

> Now you say that file descriptors on the client are going to run out 
> Isn't that changing the topic? And is that even really a problem?

Actually, it's quite a problem, for the server.  Try, sometime, having a 
few thousand file descriptors all open, and then running select() on that 
fdset.  But it's not even really that pleasant on many clients.  It's a
kernel consumable.  You try to avoid introducing additional requirements
without a good reason.

> So each process that needs to do a lookup opens a file descriptor for a 
> TCP connection, right? Whereas with UDP we don't have to do this. Is 
> this what I'm hearing you say? That I understand. (Hmm don't udp 
> connections take sockets too? Not sarcastic here.. just asking...)

You open and then close it for UDP.  You can do that for TCP, too, at a
substantial penalty.  

> And it is a good point but is this client file descriptor an 
> insurmountable problem? Also, what about the millions of connections to 
> the server? Is that really necessary for a dns resolver on one system to 
> open more than one TCP connection to its caching dns server?

There is no "DNS resolver on one system" unless you put one there.  At
which point, you can safely ask the question of why would you then connect
to a caching server (there are good reasons, in some cases).

The way libresolv works is that it takes those "nameserver" things listed
in resolv.conf and sends requests to them.  Since any program that uses
the network is likely to be linked to libresolv, you can have lots of
different programs on a system, each of which may want to resolve
different name resources.  There is no monolithic "thing" on a box to do
name resolution unless you put one there.

> I'm not saying that caching dns servers should keep open TCP connections 
> to authoritative name servers! OK? But how much latency do you increase 
> e on that uncached recursive lookup by changing to TCP?

Since latency would not be extremely high on my list of concerns with this
plan, I'll pass and say "I don't really care to speculate."  There are many
other ways you'll have lit your hair on fire before latency is a big
concern.

... 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.