On Thu, 9 Aug 2007, Stephane Bortzmeyer wrote:
>
> On Wed, Aug 08, 2007 at 03:20:56PM -0700,
> william(at)elan.net <[EMAIL PROTECTED]> wrote
> a message of 23 lines which said:
>
> > How is that an "anti DoS" technique when you actually need to return
> > an answer via UDP in order to force n
I can add one more voice to the chorus, not that it will necessarily
change anyone's mind. :)
When I was at Yahoo! the question of whether to keep TCP open or not had
already been settled, since they had found that if they didn't have it
open there was some small percentage of users who coul
On Wed, 8 Aug 2007, David Conrad wrote:
How many bytes of shell code can you stuff in a 512 byte DNS UDP packet?
How many bytes of shell code can you stuff into a 4096 byte EDNS0 UDP
packet? :)
P.S. I still think blocking TCP/53 is stupid.
Agreed.
--
If you're never wrong, you
On Wed, Aug 08, 2007 at 03:20:56PM -0700,
william(at)elan.net <[EMAIL PROTECTED]> wrote
a message of 23 lines which said:
> How is that an "anti DoS" technique when you actually need to return
> an answer via UDP in order to force next request via TCP?
Because there is no amplification: the U
On Tue, 7 Aug 2007, Donald Stahl wrote:
All things being equal (which they're usually not) you could use the ACK
response time of the TCP handshake if they've got TCP DNS resolution
available. Though again most don't for security reasons...
Then most are incredibly stupid.
Several anti DoS u
> Date: Tue, 7 Aug 2007 23:32:21 -0600
> From: "Jason J. W. Williams" <[EMAIL PROTECTED]>
>
> > The answer is simple- because they are supposed to be allowed. By
> disallowing
> > them you are breaking the agreed upon rules for the protocol. Before
> > long it becomes impossible to implement new
On Aug 8, 2007, at 8:59 AM, Jamie Bowden wrote:
How is answering a query on TCP/53 any MORE dangerous than
answering it
on UDP/53? Really. I'd like to know how one of these security
nitwits
justifies it. It's the SAME piece of software answering the query
either way.
How many bytes of s
On Tue, 7 Aug 2007, [EMAIL PROTECTED] wrote:
>
> they *already* don't answer with the txt records if you try to do a
> 'dig aol.com any' because that 512 and the 497 returned on a 'dig aol.com mx'
> won't fit in one 512-byte packet.
Wrong! You're probably not getting the txt records because you d
On 8-Aug-2007, at 11:59, Jamie Bowden wrote:
I have a question related to what you posted below, and it's a pretty
simple one:
How is answering a query on TCP/53 any MORE dangerous than
answering it
on UDP/53? Really. I'd like to know how one of these security
nitwits
justifies it. It
On Wed, Aug 08, 2007, Jamie Bowden wrote:
>
> Forgive my broken formatting, but LookOut, it's Microsoft! Is what we
> use, period.
>
> I have a question related to what you posted below, and it's a pretty
> simple one:
>
> How is answering a query on TCP/53 any MORE dangerous than answering it
On Wed, 08 Aug 2007 10:33:56 EDT, "Patrick W. Gilmore" said:
> Paying $10 and registering a domain IN NOW WAY means I promised a
> bazillion people anything.
>
> What happened to: "You can run your network however you want"?
You're totally welcome to run your own network backbone as IPv6-only
D]>
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Steve Gibbard
Sent: Tuesday, August 07, 2007 6:10 PM
To: Nanog
Subject: Re: large organization nameservers sending icmp packets to dns
servers.
On Tue, 7 Aug 2007, Donald Stahl wrote:
> It has nothing
On Aug 8, 2007, at 2:11 AM, David Schwartz wrote:
On Aug 7, 2007, at 4:33 PM, Donald Stahl wrote:
If you don't like the rules- then change the damned protocol. Stop
just doing whatever you want and then complaining when other people
disagree with you.
I think this last part is the key.
R
> On Aug 7, 2007, at 4:33 PM, Donald Stahl wrote:
> > If you don't like the rules- then change the damned protocol. Stop
> > just doing whatever you want and then complaining when other people
> > disagree with you.
> I think this last part is the key.
> Remember the old adage: "My network, My
> The answer is simple- because they are supposed to be allowed. By
disallowing
> them you are breaking the agreed upon rules for the protocol. Before
> long it becomes impossible to implement new features because you can't
be
> sure if someone else hasn't broken something intentionally.
I don
On Tue, 7 Aug 2007, Donald Stahl wrote:
>
> > As for being "incredibly stupid", well, as I have said in private, calling a
> > bunch of people rude names without even asking them why they are doing what
> > you think is so stupid is .. uh .. probably not very bright. :) Unless, of
> > course,
Dear colleagues,
I apologise for replying twice in the same thread (especially as I
tend not to post here very much, on the grounds that I usually don't
know what I'm talking about). I feel compelled to object to the
below remark, however, because I think it gets at the heart of the
problem.
On
Hi,
On Aug 7, 2007, at 1:33 PM, Donald Stahl wrote:
Can someone, anyone, please explain to me why blocking TCP 53 is
considered such a security enhancement? It's a token gesture and
does nothing to really help improve security. It does, however,
cause problems.
It has been argued that it
On Aug 7, 2007, at 2:23 PM, Andrew Sullivan wrote:
On Tue, Aug 07, 2007 at 01:50:33PM -0700, Kevin Oberman wrote:
that security types (I mean those with a police/physical security
background) don't must care for these arguments. It usually comes
down to "lock and bar every door unless you
On Tue, 7 Aug 2007, Donald Stahl wrote:
It has nothing to do with judging how one runs their network or any other
such nonsense. The RFC's say TCP 53 is fine. If you don't want to follow the
rules, fine, but have the temerity to admit that it is stupid.
I don't want to wade into this particu
On Tue, Aug 07, 2007 at 01:50:33PM -0700, Kevin Oberman wrote:
> that security types (I mean those with a police/physical security
> background) don't must care for these arguments. It usually comes down
> to "lock and bar every door unless you can prove to them that there is a
> need to have the
On Tue, 07 Aug 2007 16:10:17 EDT, "Patrick W. Gilmore" said:
> The point is, if you are the authority, you know how big the packet
> is. If you know it ain't over 512, then you don't need TCP.
Right. But remember the discussion is that *we* (for some value of "we")
are querying some *other* n
> The point is, if you are the authority, you know how big the packet
> is. If you know it ain't over 512, then you don't need TCP.
>
> Or are you saying you do? Wouldn't it be 'incredibly stupid' for
> recursive servers to -require- TCP, even for < 512 byte packets?
A TCP query is just as val
> Date: Tue, 7 Aug 2007 16:33:22 -0400 (EDT)
> From: Donald Stahl <[EMAIL PROTECTED]>
>
> > This has been a pain for me for years. I have tried to reason with
> > security people about this and, while they don't dispute my reasoning,
> > they always end up saying that it is the "standard" practice
As for being "incredibly stupid", well, as I have said in private, calling a
bunch of people rude names without even asking them why they are doing what
you think is so stupid is .. uh .. probably not very bright. :) Unless, of
course, you want everyone else passing judgement on how you run y
This has been a pain for me for years. I have tried to reason with
security people about this and, while they don't dispute my reasoning,
they always end up saying that it is the "standard" practice and that,
lacking any evidence of what it might be breaking, it will continue to
be blocked. And
On Aug 7, 2007, at 3:45 PM, [EMAIL PROTECTED] wrote:
On Tue, 07 Aug 2007 14:38:06 EDT, "Patrick W. Gilmore" said:
In addition, any UDP truncated response needs to be retried via
TCP- blocking it would cause a variety of problems.
Since we are talking about authorities here, one can control
On Tue, 07 Aug 2007 14:38:06 EDT, "Patrick W. Gilmore" said:
>> In addition, any UDP truncated response needs to be retried via
>> TCP- blocking it would cause a variety of problems.
> Since we are talking about authorities here, one can control the size
> of ones responses.
Barely.
% dig ao
On 7-Aug-2007, at 14:38, Patrick W. Gilmore wrote:
On Aug 7, 2007, at 2:14 PM, Donald Stahl wrote:
All things being equal (which they're usually not) you could use
the ACK
response time of the TCP handshake if they've got TCP DNS resolution
available. Though again most don't for security r
On Aug 7, 2007, at 2:14 PM, Donald Stahl wrote:
All things being equal (which they're usually not) you could use
the ACK
response time of the TCP handshake if they've got TCP DNS resolution
available. Though again most don't for security reasons...
Then most are incredibly stupid.
Those a
L PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, August 06, 2007 11:35 AM
To: John Levine
Cc: nanog@nanog.org
Subject: Re: large organization nameservers sending icmp packets to dns
servers.
On Mon, 06 Aug 2007 17:21:49 -, John Levine said:
>
> >> Sounds like one of the
On 6-Aug-2007, at 16:31, Peter Dambier wrote:
John L wrote:
Um, unless I seriously misunderstand the client DNS cache wants to
know which server is closest. So it sends DNS queries to all
three NS at the same time. Then it waits for the answers.
Whichever one answers first is the clos
John L wrote:
Um, unless I seriously misunderstand the client DNS cache wants to know
which server is closest. So it sends DNS queries to all three NS at the
same time. Then it waits for the answers. Whichever one answers first
is the closest. What am I missing?
The bind_garbadge_col
On Mon, 6 Aug 2007, Patrick W. Gilmore wrote:
first I agree that in most cases the 'RTT to client cacheresolver'
probably works well enough. That said though...
> Owen said it worked well for his customers (in a past life), and he
> has operational experience with this. Can anyone give a ser
On Aug 6, 2007, at 1:47 PM, John L wrote:
Why would they ping rather than just sending the query to all of the
NS and see which one answers first? It's an IP round trip either
way.
If you have sites in San Fran, London, and Tokyo, and you launch a
ping from
all 3 and see which one gets t
On Aug 6, 2007, at 10:21 AM, John Levine wrote:
Sounds like one of the global-scale load balancers - when you do a
(presumably) recursive DNS lookup of one of their hosts, they'll
ping
the nameserver from several locations and see which one gets an
answer the fastest.
Why would they pin
On Mon, 6 Aug 2007, John Levine said:
Why would they ping rather than just sending the query to all of the
NS and see which one answers first? It's an IP round trip either way.
ping targets are of the caching nameserver type, not the authoritative
nameserver type.
Duane W.
On Mon, 06 Aug 2007 17:21:49 -, John Levine said:
>
> >> Sounds like one of the global-scale load balancers - when you do a
> >> (presumably) recursive DNS lookup of one of their hosts, they'll ping
> >> the nameserver from several locations and see which one gets an
> >> answer the fastest.
>
>> Sounds like one of the global-scale load balancers - when you do a
>> (presumably) recursive DNS lookup of one of their hosts, they'll ping
>> the nameserver from several locations and see which one gets an
>> answer the fastest.
Why would they ping rather than just sending the query to all of
39 matches
Mail list logo
