dumb idea on how to fix the dns problems i don't
know
Joe Greco wrote:
>> 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 f
August 11, 2008 8:10 AM
To: Tomas L. Byrnes
Cc: [EMAIL PROTECTED]
Subject: Re: maybe a dumb idea on how to fix the dns problems i don't
know
> Unix machines set up by anyone with half a brain run a local caching
> server, and use forwarders. IE, the nameserver process can es
Joe Greco wrote:
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.
Organizations often choose not to do this because doing so involve
> 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.
Organizations often choose not to do this because doing so involves more
risk an
model, which has worked pretty well.
> -Original Message-
> From: Joe Greco [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 10, 2008 3:14 PM
> To: Chris Paul
> Cc: [EMAIL PROTECTED]
> Subject: Re: maybe a dumb idea on how to fix the dns problems
> i don't kno
Joe Greco wrote:
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
On Sat, Aug 9, 2008 at 5:18 PM, Chris Paul <[EMAIL PROTECTED]> wrote:
> Sorry if this is real stupid for some reason because I don't think about DNS
> all day (I'm the ldap dude) but since we have faster networks and faster
> cpus today, what would be the harm in switching to use TCP for DNS client
> > 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
> > thou
On Sun, 10 Aug 2008, Chris Paul wrote:
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!
==
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.
--
Chris Paul
Rex Consulti
Joe Greco wrote:
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 p
> > 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
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...
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.
[EMAIL PROTECTED] 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
> 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 e
The question isn't whether to offer TCP/53 up at the recursive
server. The issue is that for you to use TCP/53 from your recursive
server, it has to be offered up at the authoritative end.
The authoritative server operators have to offer TCP/53 and the
firewall administrators between the re
> 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 e
[EMAIL PROTECTED] wrote:
(I know; you old folks that created this wonderful thing didn't think of
that back then blah blah blah).
If they had thought of it back then, they would have allowed for a larger TXID,
not used TCP. TCP connection setup time is slow; TCP DNS is much slower t
On Sun, Aug 10, 2008 at 01:06:06PM -0700, Chris Paul wrote:
> brett watson wrote:
> >>Hey authority DNS server operators. Can you make a change to your
> >>servers to always allow TCP client connections? Would this be
> >>difficult? What would be the harm?
> >SYN flooding?
> from your clients?
Tomas L. Byrnes wrote:
-Original Message-
From: Tomas L. Byrnes
Sent: Saturday, August 09, 2008 9:01 PM
To: 'Chris Paul'
Subject: RE: maybe a dumb idea on how to fix the dns problems i don't
know
Actually, the RFCs (RFC-1034 3.7RFC-1035 4.2, ref RFC-793;
Impl
brett watson wrote:
Hey authority DNS server operators. Can you make a change to your
servers to always allow TCP client connections? Would this be
difficult? What would be the harm?
SYN flooding?
from your clients? We ways of knowing people on our local network are
doing this type of thin
> > actually, it does (need a bigger posse).
>
> Rhetoric aside, no it doesn't.
>
> Choosing not to implement (or permit, as an operational decision) TCP
> because of concerns about state is what you go on to talk about; what you
> were actually replying to was the wholesale denial of 53/tcp out
On 10 Aug 2008, at 11:56, Paul Vixie wrote:
(here we are discussing dns protocol details on nanog@ again. must
be sunday.)
(Or alternatively we could just be discussing DNS operations,
something that is entirely on-topic for this list, and conceivably of
interest to the many hundreds of
(here we are discussing dns protocol details on nanog@ again. must be sunday.)
> From: Joe Abley <[EMAIL PROTECTED]>
>
> It may be worth clarifying that "not considering TCP mandatory" above is
> an implementation/operational choice, and not something that seems to be
> clearly endorsed by RFC 10
On 10 Aug 2008, at 01:45, Paul Vixie wrote:
SYN flooding is a specific instance of "have to hold too much state"
whereas
the reason for not considering TCP mandatory is the general form of
"have to
hold too much state".
It may be worth clarifying that "not considering TCP mandatory" above
>> Paul Vixie wrote:
>>> because TCP is considered optional by many authority DNS server
>>> operators.
> On Aug 9, 2008, at 3:48 PM, Chris Paul wrote:
>> Hey authority DNS server operators. Can you make a change to your
>> servers to always allow TCP client connections? Would this be
>> dif
On Aug 9, 2008, at 3:48 PM, Chris Paul wrote:
Paul Vixie wrote:
because TCP is considered optional by many authority DNS server
operators.
Hey authority DNS server operators. Can you make a change to your
servers to always allow TCP client connections? Would this be
difficult? What wou
Randy Bush wrote:
Paul Vixie wrote:
hey are not occurring on nanog@, where they would be off-topic,
like this thread here
you may want to read the aup. by my read they are not off topic.
Also: given how serious the problem is, I'd think that far and wide
perspective
on this is ap
Paul Vixie wrote:
because TCP is considered optional by many authority DNS server operators.
Hey authority DNS server operators. Can you make a change to your
servers to always allow TCP client connections? Would this be difficult?
What would be the harm?
it's only required if you expect A
Paul Vixie wrote:
> hey are not occurring on nanog@, where they would be off-topic,
> like this thread here
you may want to read the aup. by my read they are not off topic.
randy
[EMAIL PROTECTED] (Matt F) writes:
> Why not just require TCP for a lookup if a response with an incorrect
> TXID is received? You could require TCP for just the one lookup or for
> some configured interval, say 1 hour. That should slow attackers down
> substantially.
because TCP is consider
On 9 Aug 2008, at 18:10, Matt F wrote:
Why not just require TCP for a lookup if a response with an
incorrect TXID is received? You could require TCP for just the one
lookup or for some configured interval, say 1 hour. That should
slow attackers down substantially.
That sounds like a go
Why not just require TCP for a lookup if a response with an incorrect
TXID is received? You could require TCP for just the one lookup or for
some configured interval, say 1 hour. That should slow attackers down
substantially.
Joe Abley wrote:
On 9 Aug 2008, at 17:22, Church, Charles wrote:
On 9 Aug 2008, at 17:22, Church, Charles wrote:
TCP would work, but it makes it more difficult to do Anycast, which
works well with UDP and DNS.
TCP works pretty well with anycast too, if you're careful. It's
helpful if your transactions are short-lived.
I've seen concern expressed that a
TCP would work, but it makes it more difficult to do Anycast, which
works well with UDP and DNS.
Chuck
-Original Message-
From: Chris Paul [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 09, 2008 5:18 PM
To: [EMAIL PROTECTED]
Subject: maybe a dumb idea on how to fix the dns problems i
36 matches
Mail list logo
