A strange one indeed, especially if you have no connectivity to Sprint
there.
Since your fix was layer 2 you might be onto something. And you have the
time it happened, and as we all know - somebody changed somethin' even
if they won't fess up.
I'm trying to think how you could cause somethi
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 hos
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
I am not sure about the loop, but wouldn't a static or default static route
specifying an outbound interface rather than a next hop router ip address on
a multi-access network like Ethernet, frame-relay or ATM with connections to
5 or more routers cause one router to output a stream of packets t
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
After all the messages recently about how to fix DNS, I was seriously
tempted to title this messsage "And now, for something completely
different", but impossible circuit is more descriptive.
Before you read further, I need everyone to put on their thinking WAY
outside the box hats. I've hear
> > 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;
Implementation spec in
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
-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;
Implementation spec in RFC-1035 4.2.2; RFC-2136 2.
> > 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
* Joe Greco:
> I am very, very, very disheartened to be shown to be wrong. As if 8 days
> wasn't bad enough, a concentrated attack has been shown to be effective in
> 10 hours. See http://www.nytimes.com/2008/08/09/technology/09flaw.html
Note that the actual bandwidth utilization on that GE lin
27 matches
Mail list logo
