Re: GoDaddy.com shuts down entire data center?
Here's the story on the big outage. http://marc.perkel.com/index.html Here's another recorded conversation. (Can you do this in NJ?) http://marc.perkel.com/audio/godaddy2.mp3 The GoDaddy folks are well trained. Kudos. -M<
Re: GoDaddy.com shuts down entire data center?
I think the main thing I learned from that is that there are a surprising number of hosting companies and self-professed data centre operators who really don't know much about the DNS. Or even what the word "datacenter" means. Sounds to me like a rack of servers or a cage was suspended, not "an entire datacenter" which was claimed several times. The recorded phone call was basically a lesson in how NOT to escalate a call, from both sides involved. From the customer's side if he'd not been so confrontational, he probably would have gotten his problem solved. From the operator's side, they should have a procedure for dealing with abuse and critical escalations 7/24. Just my perception. --chuck
Re: GoDaddy.com shuts down entire data center?
> > > > > The way a policy is enforced - how, in what situations etc - is what > > matters. Most if not all ISP AUPs say basically the same mom and > > apple pie thing (no net abuse or we'll shut you down) > > > > If what this guy says is right, his domain was taken down just because > > one of his servers was broken into and spammed through.I havent > > heard godaddy's side of the story yet - might be better to reserve > > judgement till they comment. > > > > Godaddy (from what I can gather) generates a surprising number of these > shut downs on weekends. The fact that their enforcement and > reinstatement rules are not publicly available on their website > (anywhere) and have no guarantees or assurances on time-to-respond > smacks of something that could get very nasty and seems highly > reactionary Would they suspend comcast.com or mcdonalds.com or > ge.com if _one_ of their servers or services was hijacked? Highly doubtful. > > In the long run, if this is a trend, those big enough will just become > registrars themselves -- even if its just for their own operations. Its > a silly thing for a domain registrar to take on enforcement operations > that network operators aren't. Abusers don't care about domains, or > domain names. Most abuse (spam aside) can operate perfectly well with > just an IP address. By the time the DNS system pulls a domain the damage > has already been done and the potential for high collateral damage is > significant. Restoration time for good-eggs (say those who fix the > problem once properly alerted) is several days in the best of cases with > the bad result of acrimony and huge financial/reputation impact > > The only medium term impact is that Godaddy will lose the bad business > and some good business and create some more competitors. The only point I am trying to make is operational WRT the command structure of a NOC. Several of us here have built many of the large NOC's in operation of the Internet today and if you put us all in the same room we'd all agree that we already know how to build NOC's that respond and get the job done for the most part. It ain't that hard anymore. Question: Do people really think waking up Bob Parsons at 0400 is a good idea for a $9.00 domain only account? He already got a roughly ~$50.00 response with all the time he had GoDaddy on the phone and the out supervisor call. I think if Parkel does, he needs to sign up with VeriSign, UltraDNS, or anyone else who is running DNS assurance products. Note: Please refrain from inferring an endorsement for DNS assurance products. -M<
Re: GoDaddy.com shuts down entire data center?
On 1/16/06, Martin Hannigan <[EMAIL PROTECTED]> wrote: > Operationally, not having someone on the shift who can make > decisions is not a good thing. It's like having a NOC with > no shift supervisor. If you're big enough - a manager. > > Disclaimer: In now way, shape, or form, should that be inferred as > a plug for or against GoDaddy. I'm nuetral. The way a policy is enforced - how, in what situations etc - is what matters. Most if not all ISP AUPs say basically the same mom and apple pie thing (no net abuse or we'll shut you down) If what this guy says is right, his domain was taken down just because one of his servers was broken into and spammed through.I havent heard godaddy's side of the story yet - might be better to reserve judgement till they comment. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: GoDaddy.com shuts down entire data center?
> > > > On 15-Jan-2006, at 18:15, Elijah Savage wrote: > > > Any validatity to this and if so I am suprised that our team has > > got no calls on not be able to get to certain websites. > > > > http://webhostingtalk.com/showthread.php?t=477562 > > I think the main thing I learned from that is that there are a > surprising number of hosting companies and self-professed data centre > operators who really don't know much about the DNS. > The GoDaddy guy didn't do such a bad job. It sounds like they had some procedures and they followed them. http://marc.perkel.com/audio/godaddy.mp3 Operationally, not having someone on the shift who can make decisions is not a good thing. It's like having a NOC with no shift supervisor. If you're big enough - a manager. Disclaimer: In now way, shape, or form, should that be inferred as a plug for or against GoDaddy. I'm nuetral. Best! -M<
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
> > > Hi Randy, > > On Sun, 15 Jan 2006 11:10:04 -1000 > Randy Bush <[EMAIL PROTECTED]> wrote: > > > > > > You are using a crossover cable right? > > >> I'm having a right mare trying to get a Foundry BigIron to > > >> connect up to a cisco 2950T, via Gigabit copper. > > > > i was under the impression that gige spec handled crossover > > automagically > > > > According to "Ethernet, The Definitive Guide", that feature is an > optional part of the spec. > > One thing I've heard people encounter is that if they use a cross-over > cable, which probably really implies a 100BASE-TX cross-over, then the > ports only go to 100Mbps. A Gig-E rated straight through, in conjunction And a GE rated cable is CAT5. Non transmission is using multi mode and all long haul transmission uses single mode. If you review the gig spec, it was designed for CAT5. Regardless, I always use CAT6 and I stick with the standard ethernet caps although I tend to go upscale on the caps and the compresssion tools i.e. calibrateable and matching to caps. For example, at mumble carrier, we spent weeks in the labs qualifying cable, caps, and crimpers - copper and coax - and then making it a systemwide standard for techs and vendors. Funny story though. Mumblecarrier had people walking by tugging on the new ds3 installations and they started falling out. The center managers started mailing each other and then all of a sudden the freakin' things were falling out all over the country. I went out to one of the datacenters, jacked up the test gear, and started looking at it. While I was sitting there being stumped as to what was happening, I watched no less than ten people walk by and tug on the cross connects. The next day, same thing and they'd look at me and go "SEE!!! THEY FALL OUT!". What had happened was mass cable hysteria. Once the center managers started telling each other to "pull on the xcons" they all started being stressed and then they had every tech pulling on them and if you pull on it enough - it will fall out. Thank you for allowing me that off topic spew. :-) -M<
Re: GoDaddy.com shuts down entire data center?
On 15-Jan-2006, at 18:15, Elijah Savage wrote: Any validatity to this and if so I am suprised that our team has got no calls on not be able to get to certain websites. http://webhostingtalk.com/showthread.php?t=477562 I think the main thing I learned from that is that there are a surprising number of hosting companies and self-professed data centre operators who really don't know much about the DNS. Joe
RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T
Hopefully the cisco copper GBIC supports Auto-MDI though, so a straight cable should be good. S On Sun, 15 Jan 2006, David Prall wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 GigE 1000Base-T requires all 4 pairs of wire. Auto-MDI is not supported on the 2950 series, so it won't handle this automagically. I would test with speed set to 100 if the foundry can support 10/100/1000 with the Copper GBIC. Put the two next to each other and test with 1000Base-T crossover cable, removing all the extra stuff if that doesn't work. 1000Base-T requires that pairs 1 and 4 are also crossed along with 2 and 3. http://en.wikipedia.org/wiki/Crossover_cable David - -- David C Prall [EMAIL PROTECTED] http://dcp.dcptech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith Sent: Sunday, January 15, 2006 5:44 PM To: Randy Bush Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T Hi Randy, On Sun, 15 Jan 2006 11:10:04 -1000 Randy Bush <[EMAIL PROTECTED]> wrote: You are using a crossover cable right? I'm having a right mare trying to get a Foundry BigIron to connect up to a cisco 2950T, via Gigabit copper. i was under the impression that gige spec handled crossover automagically According to "Ethernet, The Definitive Guide", that feature is an optional part of the spec. One thing I've heard people encounter is that if they use a cross-over cable, which probably really implies a 100BASE-TX cross-over, then the ports only go to 100Mbps. A Gig-E rated straight through, in conjunction with the automatic crossover feature, was necessary to get to GigE. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear" -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.0.3 (Build 2932) iQEVAwUBQ8rlb4YwPzEDHVgLAQjCAQgAnb36uEi0T6NuJZj7bu2vJXPgr7Y0rFK8 TjDip2kT1DYwf3mF2j0ZPCWIh7eKM4skx431VB9C8nq5glUwtOv7LYxnyMHCsyTo W6aixupMiDA2l4po1pxzoNaw1p2CVvdTxhVBEG/AP73+Ls9k2lgJii59X+4BF8qw ChmZwGdQ8GDOIWKjvax63hbsprBhf1ORUwP2qZPcg2p8P4M0yqznhrk84VpSipGU itdv/juvrFmfkGyPSozBqErpYx4hmVzBz6uLPQ2cF6ux48sPIUDz3+ta49xKlMwY zhON0whXxZA49YlwZZV5CzbjAmp8/zJWfMnl76kYkISxOqgX0Xo9dg== =D7cE -END PGP SIGNATURE-
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
Thanks Mark - just found the same thing out myself :) S On Mon, 16 Jan 2006, Mark Smith wrote: On Mon, 16 Jan 2006 00:24:35 + (GMT Standard Time) Sam Stickland <[EMAIL PROTECTED]> wrote: On Mon, 16 Jan 2006, Mark Smith wrote: On Sun, 15 Jan 2006 23:50:07 + (GMT Standard Time) Sam Stickland <[EMAIL PROTECTED]> wrote: Hi, The cabling arrangement is: Foundry -- Straight -- Patch -- Underfloor -- Patch -- Crossover -- Cisco GBIC Cable Panel Straight Panel Cable If I replace the final crossover cable with a straight, Just do that ^^^ and give it a try. Will do. Having done a bit more looking into this myself, one thing that might be a cause is the cross-over, in the sense that if it is a 100BASE-T crossover, only two of the pairs will be crossed, and the other two pairs are usually wired straight. A GigE cross over, assuming you need one if you're ports don't support automatic cross over, has all four pairs crossed over (1-3,2-6,3-1,6-2,4-7,5-8,7-4,8-5). My guess would be that if a device only detects two of the four pairs crossed, it drops back to 100BASE-T. In other words, GigE cross overs are backwards compatible with 10/100BASE-T, but 10/100BASE-T crossovers aren't forward compatible with GigE. A GigE rated straight through path would be the first thing I'd test, after that, possibly try a GigE crossover somewhere between the devices. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
Wikipedia reveals all. http://en.wikipedia.org/wiki/Crossover_cable Turns out that for 1000Base-T crossovers pairs 2 and 3, and 1 and 4 have to swapped. Standard TIA-568B to TIA-568A over swaps 2 and 3. Auto MDI/MDI-X is optional in the 1000Base-T spec so the way forward is to try a straight cable and if that fails I'll have to make up a 1000Base-T crossover cable. Thanks for all the help people, S On Mon, 16 Jan 2006, Sam Stickland wrote: On Mon, 16 Jan 2006, Mark Smith wrote: On Sun, 15 Jan 2006 23:50:07 + (GMT Standard Time) Sam Stickland <[EMAIL PROTECTED]> wrote: Hi, The cabling arrangement is: Foundry -- Straight -- Patch -- Underfloor -- Patch -- Crossover -- Cisco GBIC Cable Panel Straight Panel Cable If I replace the final crossover cable with a straight, Just do that ^^^ and give it a try. Will do. If that fails I might have to dig out a non-passive 1000SX to 1000-BaseT media convertor that's on one of the other sites and give that a try. Btw, several people have suggested "speed nonegotiate" on the cisco speed. This command is only supported on GBIC slots on cisco, not on fixed 1000Base-T interfaces (at least not a Sup720/WS-X6748-GE-TX). I also found this reference about the clock signals in use on 1000Base-T: "Synchronous transmission 1000BASE-T is based on synchronous transmission to facilitate the cancelation of Echo/NEXT/FEXT interferences at the receivers. To achieve synchronous transmission between the two PHYs at the ends of a link, a master-slave clocking relationship is established by the PHYs. The master-slave relationship between two stations sharing a link segment is established during auto-negotiation. The master PHY uses an external clock to determine the timing of transmitter and receiver operations. This master clock is also provided to the other stations in the network. The slave PHY recovers the clock from the received signal and uses it to determine the timing of transmitter operations. In a typical network, the PHY at the repeater will become the master and the PHY at the data terminal equipment (DTE) will become the slave." So it would appear that auto-negotiation is a requirement in 1000Base-T. Sam
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
On Mon, 16 Jan 2006 00:24:35 + (GMT Standard Time) Sam Stickland <[EMAIL PROTECTED]> wrote: > > On Mon, 16 Jan 2006, Mark Smith wrote: > > > On Sun, 15 Jan 2006 23:50:07 + (GMT Standard Time) > > Sam Stickland <[EMAIL PROTECTED]> wrote: > > > >> > >> Hi, > > > > > > > >> > >> The cabling arrangement is: > >> > >> Foundry -- Straight -- Patch -- Underfloor -- Patch -- Crossover -- Cisco > >> GBIC Cable Panel Straight Panel Cable > >> > >> If I replace the final crossover cable with a straight, > > Just do that ^^^ and give it a try. > > Will do. > Having done a bit more looking into this myself, one thing that might be a cause is the cross-over, in the sense that if it is a 100BASE-T crossover, only two of the pairs will be crossed, and the other two pairs are usually wired straight. A GigE cross over, assuming you need one if you're ports don't support automatic cross over, has all four pairs crossed over (1-3,2-6,3-1,6-2,4-7,5-8,7-4,8-5). My guess would be that if a device only detects two of the four pairs crossed, it drops back to 100BASE-T. In other words, GigE cross overs are backwards compatible with 10/100BASE-T, but 10/100BASE-T crossovers aren't forward compatible with GigE. A GigE rated straight through path would be the first thing I'd test, after that, possibly try a GigE crossover somewhere between the devices. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
On Mon, 16 Jan 2006, Mark Smith wrote: On Sun, 15 Jan 2006 23:50:07 + (GMT Standard Time) Sam Stickland <[EMAIL PROTECTED]> wrote: Hi, The cabling arrangement is: Foundry -- Straight -- Patch -- Underfloor -- Patch -- Crossover -- Cisco GBIC Cable Panel Straight Panel Cable If I replace the final crossover cable with a straight, Just do that ^^^ and give it a try. Will do. If that fails I might have to dig out a non-passive 1000SX to 1000-BaseT media convertor that's on one of the other sites and give that a try. Btw, several people have suggested "speed nonegotiate" on the cisco speed. This command is only supported on GBIC slots on cisco, not on fixed 1000Base-T interfaces (at least not a Sup720/WS-X6748-GE-TX). I also found this reference about the clock signals in use on 1000Base-T: "Synchronous transmission 1000BASE-T is based on synchronous transmission to facilitate the cancelation of Echo/NEXT/FEXT interferences at the receivers. To achieve synchronous transmission between the two PHYs at the ends of a link, a master-slave clocking relationship is established by the PHYs. The master-slave relationship between two stations sharing a link segment is established during auto-negotiation. The master PHY uses an external clock to determine the timing of transmitter and receiver operations. This master clock is also provided to the other stations in the network. The slave PHY recovers the clock from the received signal and uses it to determine the timing of transmitter operations. In a typical network, the PHY at the repeater will become the master and the PHY at the data terminal equipment (DTE) will become the slave." So it would appear that auto-negotiation is a requirement in 1000Base-T. Sam
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
On Jan 15, 2006, at 6:02 PM, Sam Stickland wrote: Replying to my own email.. I've found some sites that suggest it's not possible to disable auto-negotiation on 1000Base-T since other operational parameters are negotiated including selection of the master clock signal. I was aware that flow control was negotiated, but not the clock signal. Can anyone elaborate? Sam 802.3ab claims that you can't disable autonegotiation on 1000Base-T, but lots of vendors allow you to anyway. In 100 and 10Base-T, autonegotiation decides speed, phy type and duplex. In 1000Base-T, you add in a master/slave clock source negotiation. If autonegotiation is working, the master/slave thing just 'works'. If autonegotiation is disabled and your gear allows you to force 1000mbps, you also need to manually set which is the master and which is the slave. If you do nothing, most PC/server NICs force themselves into "slave" mode, and most switches force themselves into "master" mode. For the most part, this is correct and will result in it working fine. If it isn't, you have to hope your gear supports being able to toggle it. For example, in the BSD drivers for some Broadcomm and SysKonnect cards, setting the "link0" flag on the device will flip it. For Intel chips, there's a define in the driver source. Personally, I'd look at the copper GBIC first. Many vendors have had trouble with supporting them, and have been the cause for problems for me in the past. Make sure the version of the OS on your device claims to actually support copper GBICs.
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
On Sun, 15 Jan 2006 23:50:07 + (GMT Standard Time) Sam Stickland <[EMAIL PROTECTED]> wrote: > > Hi, > > The cabling arrangement is: > > Foundry -- Straight -- Patch -- Underfloor -- Patch -- Crossover -- Cisco > GBIC Cable Panel Straight Panel Cable > > If I replace the final crossover cable with a straight, Just do that ^^^ and give it a try. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
Sam Stickland wrote: Replying to my own email.. I've found some sites that suggest it's not possible to disable auto-negotiation on 1000Base-T since other operational parameters are negotiated including selection of the master clock signal. I was aware that flow control was negotiated, but not the clock signal. Can anyone elaborate? Sam On Sun, 15 Jan 2006, Sam Stickland wrote: Hi, On Sun, 15 Jan 2006, Paul G wrote: - Original Message - From: "Farrell,Bob" <[EMAIL PROTECTED]> To: "Randy Bush" <[EMAIL PROTECTED]>; "David Hubbard" <[EMAIL PROTECTED]> Cc: "Sam Stickland" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, January 15, 2006 4:45 PM Subject: RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T Cisco commands- speed 1000 duplex full the bigiron wants (iirc): spe 1000-full i strongly suggest you peruse the cli reference for both devices. On the foundry GBIC blades you can't configure the speed and duplex settings, they only support 1000-full. (config-if-e1000-1/2)#speed-duplex 1000-full Error - can't change speed and duplex mode I've dug through as much information as I can about the cisco 2950T and 802.3z/802.3ab and disabling the auto-negiation. There appears to be no command at all available to do this. The cabling arrangement is: Foundry -- Straight -- Patch -- Underfloor -- Patch -- Crossover -- Cisco GBIC Cable Panel Straight Panel Cable If I replace the final crossover cable with a straight, change the foundry to a 10/100 port, and plug the final end into a host NIC instead of the cisco I get a connection. Crossover cable has been changed twice now, and the RJ45 GBIC was previously working in a cisco 6500. I am extensively familar (at least I believe I am) with both these models, and this one has me stumped. If nobody else can see any configuration errors I guess I'm down to hardware issues. Sam Cisco Infrastructure Port Recommendation Configuring auto-negotiation is much more critical in a GE environment than in a 10/100 environment. In fact, auto-negotiation should only be disabled on switch ports that attach to devices not capable of supporting negotiation, or where connectivity issues arise from interoperability issues. Cisco recommends that Gigabit negotiation be enabled (default) on all switch-to-switch links and generally all GE devices. The default value on Gigabit interfaces it auto-negotiation, but is still a good general practice to issue the following command to insure that auto-negotiation is enabled: switch(config)#interface switch(config-If)#no speed !--- Sets the port to auto-negotiate Gigabit parameters. I have not looked at the RFC in a while but I thought when it first came out that auto negotiation had to be used on GigE. -- http://www.digitalrage.org/ The Information Technology News Center
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
Replying to my own email.. I've found some sites that suggest it's not possible to disable auto-negotiation on 1000Base-T since other operational parameters are negotiated including selection of the master clock signal. I was aware that flow control was negotiated, but not the clock signal. Can anyone elaborate? Sam On Sun, 15 Jan 2006, Sam Stickland wrote: Hi, On Sun, 15 Jan 2006, Paul G wrote: - Original Message - From: "Farrell,Bob" <[EMAIL PROTECTED]> To: "Randy Bush" <[EMAIL PROTECTED]>; "David Hubbard" <[EMAIL PROTECTED]> Cc: "Sam Stickland" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, January 15, 2006 4:45 PM Subject: RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T Cisco commands- speed 1000 duplex full the bigiron wants (iirc): spe 1000-full i strongly suggest you peruse the cli reference for both devices. On the foundry GBIC blades you can't configure the speed and duplex settings, they only support 1000-full. (config-if-e1000-1/2)#speed-duplex 1000-full Error - can't change speed and duplex mode I've dug through as much information as I can about the cisco 2950T and 802.3z/802.3ab and disabling the auto-negiation. There appears to be no command at all available to do this. The cabling arrangement is: Foundry -- Straight -- Patch -- Underfloor -- Patch -- Crossover -- Cisco GBIC Cable Panel Straight Panel Cable If I replace the final crossover cable with a straight, change the foundry to a 10/100 port, and plug the final end into a host NIC instead of the cisco I get a connection. Crossover cable has been changed twice now, and the RJ45 GBIC was previously working in a cisco 6500. I am extensively familar (at least I believe I am) with both these models, and this one has me stumped. If nobody else can see any configuration errors I guess I'm down to hardware issues. Sam
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
Hi, On Sun, 15 Jan 2006, Paul G wrote: - Original Message - From: "Farrell,Bob" <[EMAIL PROTECTED]> To: "Randy Bush" <[EMAIL PROTECTED]>; "David Hubbard" <[EMAIL PROTECTED]> Cc: "Sam Stickland" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, January 15, 2006 4:45 PM Subject: RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T Cisco commands- speed 1000 duplex full the bigiron wants (iirc): spe 1000-full i strongly suggest you peruse the cli reference for both devices. On the foundry GBIC blades you can't configure the speed and duplex settings, they only support 1000-full. (config-if-e1000-1/2)#speed-duplex 1000-full Error - can't change speed and duplex mode I've dug through as much information as I can about the cisco 2950T and 802.3z/802.3ab and disabling the auto-negiation. There appears to be no command at all available to do this. The cabling arrangement is: Foundry -- Straight -- Patch -- Underfloor -- Patch -- Crossover -- Cisco GBIC Cable Panel Straight Panel Cable If I replace the final crossover cable with a straight, change the foundry to a 10/100 port, and plug the final end into a host NIC instead of the cisco I get a connection. Crossover cable has been changed twice now, and the RJ45 GBIC was previously working in a cisco 6500. I am extensively familar (at least I believe I am) with both these models, and this one has me stumped. If nobody else can see any configuration errors I guess I'm down to hardware issues. Sam
Re: DOS attack against DNS?
In article <[EMAIL PROTECTED]> you write:
>
># > class "ANY" has no purpose in the real world, not even for debugging. if
># > you see it in a query, you can assume malicious intent. if you hear it in
># > a query, you can safely ignore that query, or at best, map it to class
># > "IN".
>#
># er... i guess that is true, although the DNS does work for
># things other than IP based networks... dispite our respective
># best efforts to cripple it.
>
>i'm not trying to cripple it. i'm saying RFC 1034/1035 was wrong about class
>"ANY". all answer/authority/additional data where OP=QUERY and QR=1 will have
>the same class as the QCLASS (of which, in spite of the QDCOUNT field, there
>can be only one). nodes do not have classes. not even zones have classes.
>each class has a hierarchy of NS RRs making a "namespace". each class needs
>its own root name servers. there are less-coherent / more-useful ways to
>interpret "the spec", and one such way could give meaning to class "ANY", but
>no dns implementation i'm aware of follows those alternate interpretations.
>
>since nanog isn't a protocol-fine-points mailing list, at least for the DNS
>protocol, one could ask "why are we discussing this?" and my answer is, there
>is an operational tie-in. if you see QCLASS=ANY in a firewall, that is prima
>facie evidence of malfeasance, not merely misconfiguration or
>misinterpretation.
And if you want to refuse class ANY queries in BIND 9 create a view
like the following.
view "blackhole" any {
allow-query { none; };
};
Note: all zones have to be in a view once you start using views.
Again this really is only a stop gap measure as the attack
can quite easily morph into something this won't catch.
Mark
Re: GoDaddy.com shuts down entire data center?
On Sun, 15 Jan 2006, Elijah Savage wrote: Any validatity to this and if so I am suprised that our team has got no calls on not be able to get to certain websites. http://webhostingtalk.com/showthread.php?t=477562 I for one applaud godaddy's response. If more piddling "Hosting Providers" with "Datacenters" got turned off when they started spewing abusive traffic, the net would be a much nicer place. Whoever the heck "nectartech" is, I guess they might act a little more responsibly in the future. Or, more probably, they'll just change to another DNS registrar who doesn't care as much about abuse. matto [EMAIL PROTECTED]< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: GoDaddy.com shuts down entire data center?
Elijah Savage wrote: Any validatity to this and if so I am suprised that our team has got no calls on not be able to get to certain websites. http://webhostingtalk.com/showthread.php?t=477562 WOW trying to do to many things at once. What a horrible email LOL. Any validity to this? Because I am suprised that we have not received any phone calls/tickets of customers complaining that they can't get to any of these domains. LOL -- http://www.digitalrage.org/ The Information Technology News Center
GoDaddy.com shuts down entire data center?
Any validatity to this and if so I am suprised that our team has got no calls on not be able to get to certain websites. http://webhostingtalk.com/showthread.php?t=477562 -- http://www.digitalrage.org/ The Information Technology News Center
Re: DOS attack against DNS?
# > class "ANY" has no purpose in the real world, not even for debugging. if # > you see it in a query, you can assume malicious intent. if you hear it in # > a query, you can safely ignore that query, or at best, map it to class # > "IN". # # er... i guess that is true, although the DNS does work for # things other than IP based networks... dispite our respective # best efforts to cripple it. i'm not trying to cripple it. i'm saying RFC 1034/1035 was wrong about class "ANY". all answer/authority/additional data where OP=QUERY and QR=1 will have the same class as the QCLASS (of which, in spite of the QDCOUNT field, there can be only one). nodes do not have classes. not even zones have classes. each class has a hierarchy of NS RRs making a "namespace". each class needs its own root name servers. there are less-coherent / more-useful ways to interpret "the spec", and one such way could give meaning to class "ANY", but no dns implementation i'm aware of follows those alternate interpretations. since nanog isn't a protocol-fine-points mailing list, at least for the DNS protocol, one could ask "why are we discussing this?" and my answer is, there is an operational tie-in. if you see QCLASS=ANY in a firewall, that is prima facie evidence of malfeasance, not merely misconfiguration or misinterpretation.
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
Hi Randy, On Sun, 15 Jan 2006 11:10:04 -1000 Randy Bush <[EMAIL PROTECTED]> wrote: > > > You are using a crossover cable right? > >> I'm having a right mare trying to get a Foundry BigIron to > >> connect up to a cisco 2950T, via Gigabit copper. > > i was under the impression that gige spec handled crossover > automagically > According to "Ethernet, The Definitive Guide", that feature is an optional part of the spec. One thing I've heard people encounter is that if they use a cross-over cable, which probably really implies a 100BASE-TX cross-over, then the ports only go to 100Mbps. A Gig-E rated straight through, in conjunction with the automatic crossover feature, was necessary to get to GigE. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
Re: DOS attack against DNS?
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --enig8BD22DF9AD3BC6F2B19E8B12
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> Mark Andrews wrote:
> > In article <[EMAIL PROTECTED]> you write:
> >> I just started seeing thousands of DNS queries that look like some sor=
> t=20
> >> of DOS attack. One log entry is below with the IP obscured.
> >>
> >> client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
> >>
> >> When you look at z.tn.co.za you see a huge TXT record.
> >>
> >> Is anyone else seeing this attack or am I the lucky one? Is this a=20
> >> known attack?
> >>
> >> Roy
> >=20
> > You are being used as a DoS amplifier. The queries will be
> > spoofed. Someone needs to learn about BCP 38.
>
> Next to not running a $world recursive/caching service ;)
> Which is where the OP can actually do something about this problem.
> Folks who don't do ingress filtering will not be bothered to get it
> going unfortunately...
>
> Greets,
> Jeroen
Configure the server to serve z.tn.co.za and set
"allow-query { none; };". This will stop the server
amplifying the attack.
Black-hole the spoofed address. This works fine for purely
recursive servers as they shouldn't be getting queries from
the given address anyway.
On could hack the servers to identify particular tuples and
black-hole them. This however is a not a long term solution
to the problem and requires a lot of maintenance.
Trace the spoofed traffic streams and get the offending
sites turned off recommending that BCP 38 be depoloyed.
For repeat offenders create a list of networks that won't
implement BCP 38 and collectively de-peer with them telling
them why you are de-peering and what is required to
re-establish connectivity. It is in everyones interests
to do the right thing here.
Shunning works if you have the collective gumption to do it.
Alternatively create a list of networks that agree to
implement BCP 38 and don't carry traffic from anyone else.
Advertise that you are BCP 38 compliant.
Either way, lack of BCP 38 compliance is a collective problem
and needs to dealt with in a collective manner.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: DOS attack against DNS?
On Sun, Jan 15, 2006 at 05:27:40PM +, Paul Vixie wrote: > > > client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E > > class "ANY" has no purpose in the real world, not even for debugging. if > you see it in a query, you can assume malicious intent. if you hear it in > a query, you can safely ignore that query, or at best, map it to class "IN". > -- > Paul Vixie er... i guess that is true, although the DNS does work for things other than IP based networks... dispite our respective best efforts to cripple it. --bill
Re: Problems connectivity GE on Foundry BigIron to Cisco 2950T
- Original Message - From: "Farrell,Bob" <[EMAIL PROTECTED]> To: "Randy Bush" <[EMAIL PROTECTED]>; "David Hubbard" <[EMAIL PROTECTED]> Cc: "Sam Stickland" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, January 15, 2006 4:45 PM Subject: RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T Cisco commands- speed 1000 duplex full the bigiron wants (iirc): spe 1000-full i strongly suggest you peruse the cli reference for both devices. -p
RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T
Possibly a bad cable ? Cisco commands- speed 1000 duplex full to set back to auto speed auto duplex auto -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randy Bush Sent: Sunday, January 15, 2006 4:10 PM To: David Hubbard Cc: Sam Stickland; [EMAIL PROTECTED] Subject: RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T > You are using a crossover cable right? >> I'm having a right mare trying to get a Foundry BigIron to >> connect up to a cisco 2950T, via Gigabit copper. i was under the impression that gige spec handled crossover automagically randy
RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T
> You are using a crossover cable right? >> I'm having a right mare trying to get a Foundry BigIron to >> connect up to a cisco 2950T, via Gigabit copper. i was under the impression that gige spec handled crossover automagically randy
RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T
Hi, Yup, it's definately a cross-over cable. ;) I had already tried this suggestion but the cisco 2950T doesn't appear to have the "no nego auto" command :/ (config)#int Gi0/2 (config-if)#no n? % Unrecognized command (config-if)#no n (config-if)#no neg auto ^ % Invalid input detected at '^' marker. Sam On Sun, 15 Jan 2006, David Hubbard wrote: You are using a crossover cable right? If that's all set, you do need to have neg-off on the Foundry and "no nego auto" on the Cisco. I haven't used the rj-45 gbics in the Foundry equipment before, not sure if that could be an issue. I would go with the hard set 1000-full on both sides. David From: Sam Stickland Hi, I'm having a right mare trying to get a Foundry BigIron to connect up to a cisco 2950T, via Gigabit copper. The Foundry BigIron is using a cisco RJ45/copper GBIC that was pulled from a live cisco 6500, where it was working fine. The cisco 2950T has two fixed 10/100/1000 RJ45 ports. The cables between the equipment have been tested and are fine. The Foundry has three different types of the gigabit negiation modes: auto-gigAutonegotiation neg-full-auto Autonegotiation first, if failed try non-autonegotiation neg-off Non-autonegotiation I've tried all three, complete with all the other possibilities with the cisco 2950T (which has fixed full duplex operation, but can be set to 'speed auto' or 'speed 1000'). None of these combinations bring up the link. The cisco 2950 never gets a link light. The Foundry gets a link light regardless when it's mode is set to 'gig-default neg-off'. I'm at a bit of a loss to explain this. Does anyone know of any configuration issues that can explain this, or is it time to start swapping out hardware components? Sam
RE: Problems connectivity GE on Foundry BigIron to Cisco 2950T
You are using a crossover cable right? If that's all set, you do need to have neg-off on the Foundry and "no nego auto" on the Cisco. I haven't used the rj-45 gbics in the Foundry equipment before, not sure if that could be an issue. I would go with the hard set 1000-full on both sides. David From: Sam Stickland > > Hi, > > I'm having a right mare trying to get a Foundry BigIron to > connect up to a cisco 2950T, via Gigabit copper. > > The Foundry BigIron is using a cisco RJ45/copper GBIC that > was pulled from a live cisco 6500, where it was working > fine. The cisco 2950T has two fixed 10/100/1000 RJ45 ports. > > The cables between the equipment have been tested and are fine. > > The Foundry has three different types of the gigabit negiation modes: > >auto-gigAutonegotiation >neg-full-auto Autonegotiation first, if failed try > non-autonegotiation >neg-off Non-autonegotiation > > I've tried all three, complete with all the other > possibilities with the cisco 2950T (which has fixed full > duplex operation, but can be set to 'speed auto' or > 'speed 1000'). > > None of these combinations bring up the link. The cisco 2950 > never gets a link light. The Foundry gets a link light > regardless when it's mode is set to 'gig-default neg-off'. > > I'm at a bit of a loss to explain this. Does anyone know of any > configuration issues that can explain this, or is it time to start > swapping out hardware components? > > Sam > >
Problems connectivity GE on Foundry BigIron to Cisco 2950T
Hi, I'm having a right mare trying to get a Foundry BigIron to connect up to a cisco 2950T, via Gigabit copper. The Foundry BigIron is using a cisco RJ45/copper GBIC that was pulled from a live cisco 6500, where it was working fine. The cisco 2950T has two fixed 10/100/1000 RJ45 ports. The cables between the equipment have been tested and are fine. The Foundry has three different types of the gigabit negiation modes: auto-gigAutonegotiation neg-full-auto Autonegotiation first, if failed try non-autonegotiation neg-off Non-autonegotiation I've tried all three, complete with all the other possibilities with the cisco 2950T (which has fixed full duplex operation, but can be set to 'speed auto' or 'speed 1000'). None of these combinations bring up the link. The cisco 2950 never gets a link light. The Foundry gets a link light regardless when it's mode is set to 'gig-default neg-off'. I'm at a bit of a loss to explain this. Does anyone know of any configuration issues that can explain this, or is it time to start swapping out hardware components? Sam
Re: DOS attack against DNS?
> client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E class "ANY" has no purpose in the real world, not even for debugging. if you see it in a query, you can assume malicious intent. if you hear it in a query, you can safely ignore that query, or at best, map it to class "IN". -- Paul Vixie
Re: DOS attack against DNS?
Mark Andrews wrote: > In article <[EMAIL PROTECTED]> you write: >> I just started seeing thousands of DNS queries that look like some sort >> of DOS attack. One log entry is below with the IP obscured. >> >> client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E >> >> When you look at z.tn.co.za you see a huge TXT record. >> >> Is anyone else seeing this attack or am I the lucky one? Is this a >> known attack? >> >> Roy > > You are being used as a DoS amplifier. The queries will be > spoofed. Someone needs to learn about BCP 38. Next to not running a $world recursive/caching service ;) Which is where the OP can actually do something about this problem. Folks who don't do ingress filtering will not be bothered to get it going unfortunately... Greets, Jeroen signature.asc Description: OpenPGP digital signature
