But we only care about TCP connection setup time in *interactive*
sessions (a human using something like the web). If you have a
persistent connection to your dns server from your dns resolver on your
browser machine, you just send the request.... no TCP setup there at
all. You can even pool connections. We do this stuff in LDAP all the time.
How does TCP resolution work in most resolver libraries? A TCP
connection for each lookup? That is kind of dumb isn't it, speaking of
dumb.... I actually don't know. Not much of a coder, so I'll let you
coders check your code and get back to me on that...
well.. maybe i'll fire up snort or wireshark and check it out later with
some different dns libs....
Pretending for a moment that it was even possible to make such large
scale changes and get them pushed into a large enough number of clients
to matter, you're talking about meltdown at the recurser level, because
it isn't just one connection per _computer_, but one connection per
_resolver stub_ per _computer_ (which, on a UNIX machine, would tend to
gravitate towards one connection per process), and this just turns into
an insane number of sockets you have to manage.
For your average ISP recurser where they only have 50,000 people online
at any given time, this could still be half a million open sockets. We
already know this sort of thing doesn't scale well.
This is very broken in any number of other ways. This message is not
intended to imply otherwise.
... JG
Joe Greco wrote:
But we only care about TCP connection setup time in *interactive* sessions (a human using something like the web). If you have a persistent connection to your dns server from your dns resolver on your browser machine, you just send the request.... no TCP setup there at all. You can even pool connections. We do this stuff in LDAP all the time.
How does TCP resolution work in most resolver libraries? A TCP connection for each lookup? That is kind of dumb isn't it, speaking of dumb.... I actually don't know. Not much of a coder, so I'll let you coders check your code and get back to me on that...
well.. maybe i'll fire up snort or wireshark and check it out later with some different dns libs....
Pretending for a moment that it was even possible to make such large scale changes and get them pushed into a large enough number of clients to matter, you're talking about meltdown at the recurser level, because
it isn't just one connection per _computer_, but one connection per
_resolver stub_ per _computer_ (which, on a UNIX machine, would tend to
gravitate towards one connection per process), and this just turns into an insane number of sockets you have to manage.
Couldn't the resolver libraries be changed to not use multiple connections?
CP
Inline..
Chris Paul wrote:
Joe Greco wrote:
But we only care about TCP connection setup time in *interactive* sessions (a human using something like the web). If you have a persistent connection to your dns server from your dns resolver on your browser machine, you just send the request.... no TCP setup there at all. You can even pool connections. We do this stuff in LDAP all the time.
How does TCP resolution work in most resolver libraries? A TCP connection for each lookup? That is kind of dumb isn't it, speaking of dumb.... I actually don't know. Not much of a coder, so I'll let you coders check your code and get back to me on that...
well.. maybe i'll fire up snort or wireshark and check it out later with some different dns libs....
Pretending for a moment that it was even possible to make such large scale changes and get them pushed into a large enough number of clients to matter, you're talking about meltdown at the recurser level, because
it isn't just one connection per _computer_, but one connection per
_resolver stub_ per _computer_ (which, on a UNIX machine, would tend to
gravitate towards one connection per process), and this just turns into an insane number of sockets you have to manage.
Couldn't the resolver libraries be changed to not use multiple connections?
And we'll change to IPv6 tomorrow!
Victor Jerlin wrote:
Couldn't the resolver libraries be changed to not use multiple connections?
And we'll change to IPv6 tomorrow!
Total apples and oranges. We all have to patch anyhow. This is just code and firewall rules. IPv6 is way more complicated, friend.
No - IPv6 is just code (and not even firewall rules).
cheers!
Unix machines set up by anyone with half a brain run a local caching
server, and use forwarders. IE, the nameserver process can establish a
persistent TCP connection to its trusted forwarders, if we just let it.
That old sneer we used to use against Windows users of not having a
"full featured host" and all.
Windows stub resolvers multiplex through AD to a MS DNS server; which
can easily use TCP to its trusted forwarders; unless they have no DC,
which is not so common; in which case they just use standard queries,
presumably to a patched ISP host (often a Nominum box).
In both cases, the fix is in the local server, which serves only a few
(and in a "full featured host" only one) machines using TCP to its
forwarder, and the chain repeating itself.
I don't see the problem with going to TCP for the recursive queries
here. It's akin to the CDN scaling model, which has worked pretty well.