Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread Barrett Lyon
I thought I would chime in quickly, one of my customers has been one of the targets of this attack. The x.p.ctrc.cc DNS server was shut down on the 15th, the response itself had a 36 TTL so that should be expired by now. On this end of it, the largest traffic spike we received was ar

Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread Paul Vixie
# hum... i subscribed to this dns-operations@ list some days back as what? #in2.oarc:amd64# bin/list_members dns-operations | grep -i manning #in2.oarc:amd64# bin/list_members dns-operations | grep -i ep.net #in2.oarc:amd64# # and have yet to see any postings. i guess i'm not worth

Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread Paul Vixie
i'd writ: # > speaking of which, f-root has about 35 nodes world wide, and about a third # > to a half of them aren't reachable by udp/161, and the blockage is not in # > our immediate neighbors but rather on transit paths. this is due to the # > cisco snmp vulnerability five years or so ago. f

Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread bmanning
> i'm not following up on the dns related parts of this, since dns-operations@ > seems to be pulling some of the dns related load today and i don't want to > say the same thing in both places. see this URL for details: > > http://lists.oarci.net/pipermail/dns-operations/2006-February/author.html

Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread Paul Vixie
[EMAIL PROTECTED] ("Christopher L. Morrow") writes: > seems like global tcp/139|tcp/445 filters, or bogon filters... bits put > into configs 'now' and completely forgotten about 'tomorrow' :( speaking of which, f-root has about 35 nodes world wide, and about a third to a half of them aren't reac

Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread Christopher L. Morrow
On Sun, 26 Feb 2006, Joe Abley wrote: > As a temporary mitigation tool today, when the volume of legitimate, > large-packet EDNS0 traffic is near-zero, blocking big 53/udp packets > might *sound* reasonable. However, we all know how permanent how are you certain that the udp/53 1500 byte packet

Re: Transit LAN vs. Individual LANs

2006-02-26 Thread Owen DeLong
--On February 26, 2006 7:53:40 AM -0600 Pete Templin <[EMAIL PROTECTED]> wrote: > > >>> An argument could be made for individual VLANs to keep things like b- >>> cast storms isolated. But I think the additional complexity will >>> cause more problems than it will solve. > >> One must keep

Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread Joe Abley
On 25-Feb-2006, at 03:41, [EMAIL PROTECTED] wrote: Limit UDP queries to 512 bytes. This greatly decreases the amplification affect, though it doesn't stop it. Expanding on this slightly, since I think this merits more discussion -- if there was widespread filtering of 53/udp pa

Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread Jon Lewis
On Sat, 25 Feb 2006, Rob Thomas wrote: As many say, you own your network, and are free to run it as you see fit. :) That said, please be aware that if you leave your name servers open to recursive query requests from any source, you WILL unwittingly help to amplify these attacks. It's the sa

Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread Paul Vixie
[EMAIL PROTECTED] (Paul Vixie) (hey, that's me!) writes: > ... (There are > about 50 folks on that list, which I'm calling "critical mass" for the > purpose of starting the first real discussion over there.) oops. 154 as of this morning, i guess i wasn

Re: DNS deluge for x.p.ctrc.cc

2006-02-26 Thread Paul Vixie
I've taken the liberty of following up on this thread on a different mailing list ([EMAIL PROTECTED]), since I'd like to explore it at a depth and breadth that would seem overly obsessive on a general purpose ops list like nanog. is the entry point if yo

Re: Transit LAN vs. Individual LANs

2006-02-26 Thread Pete Templin
An argument could be made for individual VLANs to keep things like b- cast storms isolated. But I think the additional complexity will cause more problems than it will solve. One must keep in mind that human error is the dominant cause of outages, and since there's not likely to be backho