nanog@nanog.org
> Cisco's problem seems to be have been resolved. > > Also see: > > http://blogs.cisco.com/news/2007/08/update_ciscocom_site.html > > Thanks to everyone for their verification. :-) > I heard, from incredibly unreliable sources, that Cisco was testing a new router that included a flywheel, clutch and diesel engine all on the same shaft. I also understand the DDEC failed which caused major routing instability. But take it with a mine of salt. Tuc/TBOH
RE: SBC Issues/Contact?
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9029698 > "We have traced the cause of the issue to an accident during maintenance of a > San Jose data center that resulted in a power outage in that facility," the > spokeswoman said. > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - -- "Koch, Christian" <[EMAIL PROTECTED]> wrote: > > >Just confirmed w/ Cisco, apparently there was a power outage in San > >Jose > > I'm only a few blocks from Cisco, and we have two data centers in the > immediate San Jose area -- first _I've_ heard of any powerloss on San > Jose. > > Must be specific to Cisco... > > - - ferg > > -BEGIN PGP SIGNATURE- > Version: PGP Desktop 9.6.2 (Build 2014) > > wj8DBQFGuijcq1pz9mNUZTMRAjMSAKDAJ/0C7xSQGp9KS6FOJrJxd0ClFgCcCRuZ > oU8/3Bovfc4Qa/hZDwVnoiQ= > =GOrX > -END PGP SIGNATURE- > > > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(at)netzero.net > ferg's tech blog: http://fergdawg.blogspot.com/ >
RE: large organization nameservers sending icmp packets to dns servers.
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 utilities force unknown hosts to initiate a query via TCP in order to be whitelisted. If the host can't perform a TCP query then they get blacklisted. 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? Or is this techinque based on premise that an attacker will not spoof packets and thus will send flood of DNS requests to server from same IP (set of ips)? If so the result would be that attacker could in fact use TCP just as well as UDP. -- William Leibzon Elan Networks [EMAIL PROTECTED]
nanog@nanog.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Michael Airhart <[EMAIL PROTECTED]> wrote: >I can't speak for Cisco or Cisco IT, but as evidenced by this email, at least part of our connectivity is up. > >No doubt someone official is looking at it as we speak. (I'll just lurk Nanog to get the skinny).. > Cisco's problem seems to be have been resolved. Also see: http://blogs.cisco.com/news/2007/08/update_ciscocom_site.html Thanks to everyone for their verification. :-) - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGujLsq1pz9mNUZTMRAu7pAJ4s2GtvR24DNGyLwGmEeaz6sLQx7gCfZW/J ALFp5DbrxnvdxL9Qfl8OyHk= =0gF2 -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Problems with either Cisco.com or AT&T? [POWER UPDATE]
http://infiltrated.net/ciscoOutage.jpg -- J. Oquendo "Excusatio non petita, accusatio manifesta" http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF684C42E sil . infiltrated @ net http://www.infiltrated.net smime.p7s Description: S/MIME Cryptographic Signature
RE: SBC Issues/Contact?
Yeah , same here Regards, -Original Message- From: Paul Ferguson [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 08, 2007 4:35 PM To: Koch, Christian Cc: nanog@nanog.org Subject: RE: SBC Issues/Contact? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- "Koch, Christian" <[EMAIL PROTECTED]> wrote: >Just confirmed w/ Cisco, apparently there was a power outage in San >Jose I'm only a few blocks from Cisco, and we have two data centers in the immediate San Jose area -- first _I've_ heard of any powerloss on San Jose. Must be specific to Cisco... - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGuijcq1pz9mNUZTMRAjMSAKDAJ/0C7xSQGp9KS6FOJrJxd0ClFgCcCRuZ oU8/3Bovfc4Qa/hZDwVnoiQ= =GOrX -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
RE: SBC Issues/Contact?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- "Koch, Christian" <[EMAIL PROTECTED]> wrote: >Just confirmed w/ Cisco, apparently there was a power outage in San Jose I'm only a few blocks from Cisco, and we have two data centers in the immediate San Jose area -- first _I've_ heard of any powerloss on San Jose. Must be specific to Cisco... - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGuijcq1pz9mNUZTMRAjMSAKDAJ/0C7xSQGp9KS6FOJrJxd0ClFgCcCRuZ oU8/3Bovfc4Qa/hZDwVnoiQ= =GOrX -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
nanog@nanog.org
Yep; when I sent my previous note, AS109 was still originating routes. But packets seemed to die at the border router. Now I'm also seeing routes via AS701 (UU/Verizon Biz) and AS1239 (Sprint) as well as AT&T, but still no connectivity. A few moments ago I was getting a response from the www.cisco.com website, but it was a 403 Forbidden response. Thus I suspect that it's not even a network problem so much as a website (LB, server, etc) issue, or a DDoS attack, etc. (Perhaps operators are changing route policy, trying to "fix" the wrong issue?) -Benson > -Original Message- > From: Michael Airhart [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 08, 2007 3:06 PM > To: Schliesser, Benson > Cc: nanog@nanog.org > Subject: RE: Problems with either Cisco.com or AT&T? > > I can't speak for Cisco or Cisco IT, but as evidenced by this email, > at least part of our connectivity is up. > > No doubt someone official is looking at it as we speak. (I'll just > lurk Nanog to get the skinny).. > > > > > > >A brief look at routeviews shows www.cisco.com (198.133.219.25) > >originating from AS109 (Cisco) and transiting via AS7132 > (AT&T/SBC) and > >AS7018 (AT&T). Thus I suspect this is an issue with AS109 (Cisco) and > >not with their providers. Though, I do feel wrong using the plural > >"providers" in this case... > > > >-Benson > > > >
nanog@nanog.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Ferguson wrote: > No idea -- maybe just a hiccup? > No, the outage is real and affecting network and systems for internal and external services. - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGuiMZE1XcgMgrtyYRAmqXAJ49T9qynoNTigAJoWTNDs47gGm+fwCg1r5U UBMuGr0jH0mh0iBXRh+BPrw= =NHKE -END PGP SIGNATURE-
nanog@nanog.org
I can't speak for Cisco or Cisco IT, but as evidenced by this email, at least part of our connectivity is up. No doubt someone official is looking at it as we speak. (I'll just lurk Nanog to get the skinny).. A brief look at routeviews shows www.cisco.com (198.133.219.25) originating from AS109 (Cisco) and transiting via AS7132 (AT&T/SBC) and AS7018 (AT&T). Thus I suspect this is an issue with AS109 (Cisco) and not with their providers. Though, I do feel wrong using the plural "providers" in this case... -Benson >
RE: SBC Issues/Contact?
Just confirmed w/ Cisco, apparently there was a power outage in San Jose Regards, -- Christian J. Koch Network Engineer Quality Technology Services Direct: 212.334.8551 Mobile: 646.300.3387 [EMAIL PROTECTED] Key Fingerprint: A8F1 2265 DD05 EC8C 2F3C 1556 51B1 F193 D2DA DED3 -Original Message- From: Elijah Savage [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 08, 2007 2:56 PM To: Koch, Christian Cc: nanog@nanog.org Subject: Re: SBC Issues/Contact? See Paul's previous email I do not think it was just SBC becuase I was having problems on my Sprint link as well as my time warner telecom link. It is resolved for me nowe though. - Original Message - From: Christian Koch <[EMAIL PROTECTED]> To: nanog@nanog.org Sent: Wednesday, August 8, 2007 2:19:31 PM GMT-0500 Auto-Detected Subject: SBC Issues/Contact? Anyone have a contact for sbc? They are preventing me from getting to cisco.com P:\>tracert cisco.com Tracing route to cisco.com [198.133.219.25] over a maximum of 30 hops: 1<1 ms<1 ms<1 ms 10.5.7.254 2<1 ms<1 ms<1 ms 209.10.21.253 328 ms28 ms28 ms 209.10.9.37 428 ms27 ms27 ms 209.10.9.25 528 ms27 ms27 ms g-1-0-0.core2.nyc15.qualitytech.com [209.10.10.186] 628 ms28 ms28 ms so-1-0-0.core1.cgx2.globix.net [209.10.10.161] 728 ms28 ms28 ms pos-2-0.peer1.cgx3.globix.net [209.10.12.82] 8 451 ms 455 ms 450 ms ex1-g1-0.eqchil.sbcglobal.net [206.223.119.79] 9 513 ms 499 ms 501 ms ded4-g8-3-0.sntc01.pbi.net [151.164.41.165] 10 *** Request timed out. 11 *** Request timed out. 12 *** Request timed out. 13 *** Request timed out. 14 *** Request timed out. 15 *** Request timed out. 16 *** Request timed out. 17 *** Request timed out. 18 *** Request timed out. 19 *** Request timed out. 20 *** Request timed out. 21 *** Request timed out. 22 **
RE: SBC Issues/Contact?
Same from comcast in NJ, through att as well christian$ traceroute cisco.com traceroute to cisco.com (198.133.219.25), 64 hops max, 40 byte packets 1 c-3-0-ubr02.tomsriver.nj.panjde.comcast.net (73.187.160.1) 10.146 ms 8.465 ms 7.789 ms 2 ge-6-3-sr01.tomsriver.nj.panjde.comcast.net (68.86.223.253) 8.223 ms 8.598 ms 9.799 ms 3 ge-2-24-ur01.dover.nj.panjde.comcast.net (68.86.210.85) 10.688 ms 10.301 ms 8.676 ms 4 te-1-1-ur02.dover.nj.panjde.comcast.net (68.86.210.62) 10.727 ms 10.454 ms 9.871 ms 5 te-1-1-ur01.brick2.nj.panjde.comcast.net (68.86.210.66) 11.213 ms 10.364 ms 11.415 ms 6 te-1-1-ur01.brick1.nj.panjde.comcast.net (68.86.210.70) 9.916 ms 10.859 ms 11.698 ms 7 te-1-1-ur01.eatontown.nj.panjde.comcast.net (68.86.210.74) 10.080 ms 10.954 ms 10.054 ms 8 te-1-1-ur02.eatontown.nj.panjde.comcast.net (68.86.210.78) 10.563 ms 9.920 ms 9.839 ms 9 te-2-1-ar01.eatontown.nj.panjde.comcast.net (68.86.210.82) 10.175 ms 11.745 ms 12.049 ms 10 po-90-ar01.verona.nj.panjde.comcast.net (68.86.208.9) 15.755 ms 12.065 ms 16.057 ms 11 po-10-ar01.plainfield.nj.panjde.comcast.net (68.86.208.5) 14.958 ms 14.316 ms 17.811 ms 12 ge-2-0-cr01.plainfield.nj.core.comcast.net (68.86.211.2) 14.115 ms 14.604 ms 13.343 ms 13 12.118.102.17 (12.118.102.17) 35.661 ms 36.602 ms 34.957 ms 14 tbr1.n54ny.ip.att.net (12.123.3.82) 81.193 ms 80.138 ms 81.954 ms 15 12.122.16.153 (12.122.16.153) 80.224 ms 76.693 ms 78.115 ms 16 cr1.cgcil.ip.att.net (12.122.1.190) 80.754 ms 80.302 ms 79.854 ms 17 12.122.17.138 (12.122.17.138) 80.818 ms 82.913 ms 81.352 ms 18 tbr1.sffca.ip.att.net (12.122.10.6) 81.334 ms 81.121 ms 82.318 ms 19 gbr5.sffca.ip.att.net (12.122.11.74) 80.030 ms 82.585 ms 78.627 ms 20 gar1.sj2ca.ip.att.net (12.122.2.253) 81.704 ms 80.848 ms 81.740 ms 21 * * * 22 * * * 23 * * * Regards, -- Christian J. Koch Network Engineer Quality Technology Services Direct: 212.334.8551 Mobile: 646.300.3387 [EMAIL PROTECTED] Key Fingerprint: A8F1 2265 DD05 EC8C 2F3C 1556 51B1 F193 D2DA DED3 -Original Message- From: Elijah Savage [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 08, 2007 2:56 PM To: Koch, Christian Cc: nanog@nanog.org Subject: Re: SBC Issues/Contact? See Paul's previous email I do not think it was just SBC becuase I was having problems on my Sprint link as well as my time warner telecom link. It is resolved for me nowe though. - Original Message - From: Christian Koch <[EMAIL PROTECTED]> To: nanog@nanog.org Sent: Wednesday, August 8, 2007 2:19:31 PM GMT-0500 Auto-Detected Subject: SBC Issues/Contact? Anyone have a contact for sbc? They are preventing me from getting to cisco.com P:\>tracert cisco.com Tracing route to cisco.com [198.133.219.25] over a maximum of 30 hops: 1<1 ms<1 ms<1 ms 10.5.7.254 2<1 ms<1 ms<1 ms 209.10.21.253 328 ms28 ms28 ms 209.10.9.37 428 ms27 ms27 ms 209.10.9.25 528 ms27 ms27 ms g-1-0-0.core2.nyc15.qualitytech.com [209.10.10.186] 628 ms28 ms28 ms so-1-0-0.core1.cgx2.globix.net [209.10.10.161] 728 ms28 ms28 ms pos-2-0.peer1.cgx3.globix.net [209.10.12.82] 8 451 ms 455 ms 450 ms ex1-g1-0.eqchil.sbcglobal.net [206.223.119.79] 9 513 ms 499 ms 501 ms ded4-g8-3-0.sntc01.pbi.net [151.164.41.165] 10 *** Request timed out. 11 *** Request timed out. 12 *** Request timed out. 13 *** Request timed out. 14 *** Request timed out. 15 *** Request timed out. 16 *** Request timed out. 17 *** Request timed out. 18 *** Request timed out. 19 *** Request timed out. 20 *** Request timed out. 21 *** Request timed out. 22 **
nanog@nanog.org
Useless also from Sprint (via AT&T in the middle) & Cogent - Dies at the pbi.net address. Koch, Christian wrote: Im seeing issues at sbc as well P:\>tracert cisco.com Tracing route to cisco.com [198.133.219.25] over a maximum of 30 hops: 1<1 ms<1 ms<1 ms 10.5.7.254 2<1 ms<1 ms<1 ms 209.10.21.253 328 ms28 ms28 ms 209.10.9.37 428 ms27 ms27 ms 209.10.9.25 528 ms27 ms27 ms g-1-0-0.core2.nyc15.qualitytech.com [209.10.10.186] 628 ms28 ms28 ms so-1-0-0.core1.cgx2.globix.net [209.10.10.161] 728 ms28 ms28 ms pos-2-0.peer1.cgx3.globix.net [209.10.12.82] 8 316 ms 330 ms 326 ms ex1-g1-0.eqchil.sbcglobal.net [206.223.119.79] 9 368 ms 352 ms 333 ms ded4-g8-3-0.sntc01.pbi.net [151.164.41.165] 10 *** Request timed out. 11 *** Request timed out. 12 *** Request timed out. 13 *** Request timed out. 14 *** Request timed out. 15 *** Request timed out. 16 *** Request timed out. 17 *** Request timed out. 18 *** Request timed out. 19 *** Request timed out. 20 *** Request timed out. 21 *** Request timed out. 22 *** Request timed out. 23 *** Request timed out. 24 *** Request timed out. 25 *** Request timed out. 26 *** Request timed out. 27 *** Request timed out. 28 *** Request timed out. 29 *** Request timed out. 30 *** Request timed out. Regards, -- Christian J. Koch Network Engineer Quality Technology Services Direct: 212.334.8551 Mobile: 646.300.3387 [EMAIL PROTECTED] Key Fingerprint: A8F1 2265 DD05 EC8C 2F3C 1556 51B1 F193 D2DA DED3 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Ferguson Sent: Wednesday, August 08, 2007 2:17 PM To: nanog@nanog.org Subject: Problems with either Cisco.com or AT&T? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No idea -- maybe just a hiccup? - From my office in San Jose: %traceroute www.cisco.com Tracing route to www.cisco.com [198.133.219.25] over a maximum of 30 hops: [snip] 7 3 ms 3 ms 3 ms so-3-0-0.mpr2.sjc7.us.above.net [64.125.30.173] 8 3 ms 3 ms 3 ms above-att.sjc7.us.above.net [64.125.13.50] 9 7 ms 7 ms 7 ms tbr1.sffca.ip.att.net [12.123.12.2] 10 6 ms 6 ms 6 ms gbr5.sffca.ip.att.net [12.122.11.74] 11 6 ms 6 ms 6 ms gar1.sj2ca.ip.att.net [12.122.2.253] 12 *** Request timed out. 13 *** Request timed out. 14 * ^C - From MIT: Tracing to: www.cisco.com 1 legacy26-0.default.csail.mit.edu (18.26.0.1) [AS3] 0 ms 0 ms 0 ms 2 kalgan.trantor.csail.mit.edu (128.30.0.245) [AS40] 0 ms 0 ms 0 ms 3 B24-RTR-2-CSAIL.MIT.EDU (18.4.7.1) [AS3] 0 ms 0 ms 0 ms 4 EXTERNAL-RTR-1-BACKBONE.MIT.EDU (18.168.0.18) [AS3] 1 ms 4 ms 2 ms 5 ge-6-23.car2.Boston1.Level3.net (4.79.2.1) [AS3356] 0 ms * 0 ms 6 * * ae-5-5.ebr1.NewYork1.Level3.net (4.69.132.250) [AS3356] 8 ms 7 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) [AS3356] 10 ms 5 ms 16 ms 8 ae-13-69.car3.NewYork1.Level3.net (4.68.16.5) [AS3356] 67 ms 59 ms 58 ms 9 att-level3-oc192.NewYork1.Level3.net (4.68.127.150) [AS3356] 17 ms 127 ms 12 ms 10 tbr1.n54ny.ip.att.net (12.123.3.57) [] [MPLS: Label 31537 Exp 0] 80 ms 79 ms 79 ms 11 12.122.16.153 (12.122.16.153) [] [MPLS: Label 19 Exp 0] 76 ms 77 ms 77 ms 12 cr1.cgcil.ip.att.net (12.122.1.190) [] [MPLS: Label 1188 Exp 0] 77 ms 76 ms 77 ms 13 12.122.17.146 (12.122.17.146) [] [MPLS: Label 31051 Exp 0] 77 ms 78 ms 78 ms 14 tbr1.sffca.ip.att.net (12.122.10.6) [] [MPLS: Label 31320 Exp 0] 78 ms 78 ms 78 ms 15 gbr5.sffca.ip.att.net (12.122.11.74) [] [MPLS: Label 323 Exp 0] 72 ms 71 ms 71 ms 16 gar1.sj2ca.ip.att.net (12.122.2.253) [] 76 ms 76 ms 77 ms 17 * * * 18 * * * 19 * * * 20 * * * - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGugixq1pz9mNUZTMRAnY3AKCIeE2oiRKl11ZRgsOLs/q6J5TyLwCgi/SQ mnTSn9TJY+yB2cjZSeKaulM= =DGbM -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
nanog@nanog.org
A brief look at routeviews shows www.cisco.com (198.133.219.25) originating from AS109 (Cisco) and transiting via AS7132 (AT&T/SBC) and AS7018 (AT&T). Thus I suspect this is an issue with AS109 (Cisco) and not with their providers. Though, I do feel wrong using the plural "providers" in this case... -Benson > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Marcus H. Sachs > Sent: Wednesday, August 08, 2007 1:33 PM > To: 'Paul Ferguson' > Cc: nanog@nanog.org > Subject: RE: Problems with either Cisco.com or AT&T? > > > Ditto. We've had a few folks contact the Internet Storm > Center about this. > First report came in at 2 pm ET. > > Marc > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Paul > Ferguson > Sent: Wednesday, August 08, 2007 2:17 PM > To: nanog@nanog.org > Subject: Problems with either Cisco.com or AT&T? > > > *** PGP SIGNATURE VERIFICATION *** > *** Status: Good Signature from Invalid Key > *** Alert:Please verify signer's key before trusting signature. > *** Signer: Paul Ferguson <[EMAIL PROTECTED]> > (0x63546533) > *** Signed: 8/8/2007 2:17:21 PM > *** Verified: 8/8/2007 2:31:04 PM > *** BEGIN PGP VERIFIED MESSAGE *** > > No idea -- maybe just a hiccup? > > From my office in San Jose: > > %traceroute www.cisco.com > > Tracing route to www.cisco.com [198.133.219.25] over a > maximum of 30 hops: > > [snip] > > 7 3 ms 3 ms 3 ms so-3-0-0.mpr2.sjc7.us.above.net > [64.125.30.173] > > 8 3 ms 3 ms 3 ms above-att.sjc7.us.above.net > [64.125.13.50] > 9 7 ms 7 ms 7 ms tbr1.sffca.ip.att.net [12.123.12.2] > 10 6 ms 6 ms 6 ms gbr5.sffca.ip.att.net [12.122.11.74] > 11 6 ms 6 ms 6 ms gar1.sj2ca.ip.att.net [12.122.2.253] > 12 *** Request timed out. > 13 *** Request timed out. > 14 * ^C > > > From MIT: > > Tracing to: www.cisco.com > > 1 legacy26-0.default.csail.mit.edu (18.26.0.1) [AS3] 0 ms > 0 ms 0 ms > 2 kalgan.trantor.csail.mit.edu (128.30.0.245) [AS40] 0 ms > 0 ms 0 ms > 3 B24-RTR-2-CSAIL.MIT.EDU (18.4.7.1) [AS3] 0 ms 0 ms 0 ms > 4 EXTERNAL-RTR-1-BACKBONE.MIT.EDU (18.168.0.18) [AS3] 1 ms > 4 ms 2 ms > 5 ge-6-23.car2.Boston1.Level3.net (4.79.2.1) [AS3356] 0 ms * 0 ms > 6 * * ae-5-5.ebr1.NewYork1.Level3.net (4.69.132.250) [AS3356] 8 ms > 7 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) [AS3356] > 10 ms 5 ms > 16 ms > 8 ae-13-69.car3.NewYork1.Level3.net (4.68.16.5) [AS3356] > 67 ms 59 ms > 58 ms > 9 att-level3-oc192.NewYork1.Level3.net (4.68.127.150) > [AS3356] 17 ms > 127 ms 12 ms > 10 tbr1.n54ny.ip.att.net (12.123.3.57) [] [MPLS: Label 31537 > Exp 0] 80 ms > 79 ms 79 ms > 11 12.122.16.153 (12.122.16.153) [] [MPLS: Label 19 Exp 0] > 76 ms 77 ms > 77 ms > 12 cr1.cgcil.ip.att.net (12.122.1.190) [] [MPLS: Label 1188 > Exp 0] 77 ms > 76 ms 77 ms > 13 12.122.17.146 (12.122.17.146) [] [MPLS: Label 31051 Exp > 0] 77 ms 78 ms > 78 ms > 14 tbr1.sffca.ip.att.net (12.122.10.6) [] [MPLS: Label 31320 > Exp 0] 78 ms > 78 ms 78 ms > 15 gbr5.sffca.ip.att.net (12.122.11.74) [] [MPLS: Label 323 > Exp 0] 72 ms > 71 ms 71 ms > 16 gar1.sj2ca.ip.att.net (12.122.2.253) [] 76 ms 76 ms 77 ms > 17 * * * > 18 * * * > 19 * * * > 20 * * * > > > > > - ferg > > > *** END PGP VERIFIED MESSAGE *** > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(at)netzero.net ferg's > tech blog: http://fergdawg.blogspot.com/ > >
Re: SBC Issues/Contact?
See Paul's previous email I do not think it was just SBC becuase I was having problems on my Sprint link as well as my time warner telecom link. It is resolved for me nowe though. - Original Message - From: Christian Koch <[EMAIL PROTECTED]> To: nanog@nanog.org Sent: Wednesday, August 8, 2007 2:19:31 PM GMT-0500 Auto-Detected Subject: SBC Issues/Contact? Anyone have a contact for sbc? They are preventing me from getting to cisco.com P:\>tracert cisco.com Tracing route to cisco.com [198.133.219.25] over a maximum of 30 hops: 1<1 ms<1 ms<1 ms 10.5.7.254 2<1 ms<1 ms<1 ms 209.10.21.253 328 ms28 ms28 ms 209.10.9.37 428 ms27 ms27 ms 209.10.9.25 528 ms27 ms27 ms g-1-0-0.core2.nyc15.qualitytech.com [209.10.10.186] 628 ms28 ms28 ms so-1-0-0.core1.cgx2.globix.net [209.10.10.161] 728 ms28 ms28 ms pos-2-0.peer1.cgx3.globix.net [209.10.12.82] 8 451 ms 455 ms 450 ms ex1-g1-0.eqchil.sbcglobal.net [206.223.119.79] 9 513 ms 499 ms 501 ms ded4-g8-3-0.sntc01.pbi.net [151.164.41.165] 10 *** Request timed out. 11 *** Request timed out. 12 *** Request timed out. 13 *** Request timed out. 14 *** Request timed out. 15 *** Request timed out. 16 *** Request timed out. 17 *** Request timed out. 18 *** Request timed out. 19 *** Request timed out. 20 *** Request timed out. 21 *** Request timed out. 22 **
nanog@nanog.org
Now that you have mentioned it I am having problems reaching Cisco from Sprint as well and Time Warner Telecom. - Original Message - From: Paul Ferguson <[EMAIL PROTECTED]> To: nanog@nanog.org Sent: Wednesday, August 8, 2007 2:17:29 PM GMT-0500 Auto-Detected Subject: Problems with either Cisco.com or AT&T? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No idea -- maybe just a hiccup? - From my office in San Jose: %traceroute www.cisco.com Tracing route to www.cisco.com [198.133.219.25] over a maximum of 30 hops: [snip] 7 3 ms 3 ms 3 ms so-3-0-0.mpr2.sjc7.us.above.net [64.125.30.173] 8 3 ms 3 ms 3 ms above-att.sjc7.us.above.net [64.125.13.50] 9 7 ms 7 ms 7 ms tbr1.sffca.ip.att.net [12.123.12.2] 10 6 ms 6 ms 6 ms gbr5.sffca.ip.att.net [12.122.11.74] 11 6 ms 6 ms 6 ms gar1.sj2ca.ip.att.net [12.122.2.253] 12 *** Request timed out. 13 *** Request timed out. 14 * ^C - From MIT: Tracing to: www.cisco.com 1 legacy26-0.default.csail.mit.edu (18.26.0.1) [AS3] 0 ms 0 ms 0 ms 2 kalgan.trantor.csail.mit.edu (128.30.0.245) [AS40] 0 ms 0 ms 0 ms 3 B24-RTR-2-CSAIL.MIT.EDU (18.4.7.1) [AS3] 0 ms 0 ms 0 ms 4 EXTERNAL-RTR-1-BACKBONE.MIT.EDU (18.168.0.18) [AS3] 1 ms 4 ms 2 ms 5 ge-6-23.car2.Boston1.Level3.net (4.79.2.1) [AS3356] 0 ms * 0 ms 6 * * ae-5-5.ebr1.NewYork1.Level3.net (4.69.132.250) [AS3356] 8 ms 7 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) [AS3356] 10 ms 5 ms 16 ms 8 ae-13-69.car3.NewYork1.Level3.net (4.68.16.5) [AS3356] 67 ms 59 ms 58 ms 9 att-level3-oc192.NewYork1.Level3.net (4.68.127.150) [AS3356] 17 ms 127 ms 12 ms 10 tbr1.n54ny.ip.att.net (12.123.3.57) [] [MPLS: Label 31537 Exp 0] 80 ms 79 ms 79 ms 11 12.122.16.153 (12.122.16.153) [] [MPLS: Label 19 Exp 0] 76 ms 77 ms 77 ms 12 cr1.cgcil.ip.att.net (12.122.1.190) [] [MPLS: Label 1188 Exp 0] 77 ms 76 ms 77 ms 13 12.122.17.146 (12.122.17.146) [] [MPLS: Label 31051 Exp 0] 77 ms 78 ms 78 ms 14 tbr1.sffca.ip.att.net (12.122.10.6) [] [MPLS: Label 31320 Exp 0] 78 ms 78 ms 78 ms 15 gbr5.sffca.ip.att.net (12.122.11.74) [] [MPLS: Label 323 Exp 0] 72 ms 71 ms 71 ms 16 gar1.sj2ca.ip.att.net (12.122.2.253) [] 76 ms 76 ms 77 ms 17 * * * 18 * * * 19 * * * 20 * * * - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGugixq1pz9mNUZTMRAnY3AKCIeE2oiRKl11ZRgsOLs/q6J5TyLwCgi/SQ mnTSn9TJY+yB2cjZSeKaulM= =DGbM -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
nanog@nanog.org
Ditto. We've had a few folks contact the Internet Storm Center about this. First report came in at 2 pm ET. Marc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Ferguson Sent: Wednesday, August 08, 2007 2:17 PM To: nanog@nanog.org Subject: Problems with either Cisco.com or AT&T? *** PGP SIGNATURE VERIFICATION *** *** Status: Good Signature from Invalid Key *** Alert:Please verify signer's key before trusting signature. *** Signer: Paul Ferguson <[EMAIL PROTECTED]> (0x63546533) *** Signed: 8/8/2007 2:17:21 PM *** Verified: 8/8/2007 2:31:04 PM *** BEGIN PGP VERIFIED MESSAGE *** No idea -- maybe just a hiccup? >From my office in San Jose: %traceroute www.cisco.com Tracing route to www.cisco.com [198.133.219.25] over a maximum of 30 hops: [snip] 7 3 ms 3 ms 3 ms so-3-0-0.mpr2.sjc7.us.above.net [64.125.30.173] 8 3 ms 3 ms 3 ms above-att.sjc7.us.above.net [64.125.13.50] 9 7 ms 7 ms 7 ms tbr1.sffca.ip.att.net [12.123.12.2] 10 6 ms 6 ms 6 ms gbr5.sffca.ip.att.net [12.122.11.74] 11 6 ms 6 ms 6 ms gar1.sj2ca.ip.att.net [12.122.2.253] 12 *** Request timed out. 13 *** Request timed out. 14 * ^C >From MIT: Tracing to: www.cisco.com 1 legacy26-0.default.csail.mit.edu (18.26.0.1) [AS3] 0 ms 0 ms 0 ms 2 kalgan.trantor.csail.mit.edu (128.30.0.245) [AS40] 0 ms 0 ms 0 ms 3 B24-RTR-2-CSAIL.MIT.EDU (18.4.7.1) [AS3] 0 ms 0 ms 0 ms 4 EXTERNAL-RTR-1-BACKBONE.MIT.EDU (18.168.0.18) [AS3] 1 ms 4 ms 2 ms 5 ge-6-23.car2.Boston1.Level3.net (4.79.2.1) [AS3356] 0 ms * 0 ms 6 * * ae-5-5.ebr1.NewYork1.Level3.net (4.69.132.250) [AS3356] 8 ms 7 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) [AS3356] 10 ms 5 ms 16 ms 8 ae-13-69.car3.NewYork1.Level3.net (4.68.16.5) [AS3356] 67 ms 59 ms 58 ms 9 att-level3-oc192.NewYork1.Level3.net (4.68.127.150) [AS3356] 17 ms 127 ms 12 ms 10 tbr1.n54ny.ip.att.net (12.123.3.57) [] [MPLS: Label 31537 Exp 0] 80 ms 79 ms 79 ms 11 12.122.16.153 (12.122.16.153) [] [MPLS: Label 19 Exp 0] 76 ms 77 ms 77 ms 12 cr1.cgcil.ip.att.net (12.122.1.190) [] [MPLS: Label 1188 Exp 0] 77 ms 76 ms 77 ms 13 12.122.17.146 (12.122.17.146) [] [MPLS: Label 31051 Exp 0] 77 ms 78 ms 78 ms 14 tbr1.sffca.ip.att.net (12.122.10.6) [] [MPLS: Label 31320 Exp 0] 78 ms 78 ms 78 ms 15 gbr5.sffca.ip.att.net (12.122.11.74) [] [MPLS: Label 323 Exp 0] 72 ms 71 ms 71 ms 16 gar1.sj2ca.ip.att.net (12.122.2.253) [] 76 ms 76 ms 77 ms 17 * * * 18 * * * 19 * * * 20 * * * - ferg *** END PGP VERIFIED MESSAGE *** -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
nanog@nanog.org
Im seeing issues at sbc as well P:\>tracert cisco.com Tracing route to cisco.com [198.133.219.25] over a maximum of 30 hops: 1<1 ms<1 ms<1 ms 10.5.7.254 2<1 ms<1 ms<1 ms 209.10.21.253 328 ms28 ms28 ms 209.10.9.37 428 ms27 ms27 ms 209.10.9.25 528 ms27 ms27 ms g-1-0-0.core2.nyc15.qualitytech.com [209.10.10.186] 628 ms28 ms28 ms so-1-0-0.core1.cgx2.globix.net [209.10.10.161] 728 ms28 ms28 ms pos-2-0.peer1.cgx3.globix.net [209.10.12.82] 8 316 ms 330 ms 326 ms ex1-g1-0.eqchil.sbcglobal.net [206.223.119.79] 9 368 ms 352 ms 333 ms ded4-g8-3-0.sntc01.pbi.net [151.164.41.165] 10 *** Request timed out. 11 *** Request timed out. 12 *** Request timed out. 13 *** Request timed out. 14 *** Request timed out. 15 *** Request timed out. 16 *** Request timed out. 17 *** Request timed out. 18 *** Request timed out. 19 *** Request timed out. 20 *** Request timed out. 21 *** Request timed out. 22 *** Request timed out. 23 *** Request timed out. 24 *** Request timed out. 25 *** Request timed out. 26 *** Request timed out. 27 *** Request timed out. 28 *** Request timed out. 29 *** Request timed out. 30 *** Request timed out. Regards, -- Christian J. Koch Network Engineer Quality Technology Services Direct: 212.334.8551 Mobile: 646.300.3387 [EMAIL PROTECTED] Key Fingerprint: A8F1 2265 DD05 EC8C 2F3C 1556 51B1 F193 D2DA DED3 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Ferguson Sent: Wednesday, August 08, 2007 2:17 PM To: nanog@nanog.org Subject: Problems with either Cisco.com or AT&T? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No idea -- maybe just a hiccup? - From my office in San Jose: %traceroute www.cisco.com Tracing route to www.cisco.com [198.133.219.25] over a maximum of 30 hops: [snip] 7 3 ms 3 ms 3 ms so-3-0-0.mpr2.sjc7.us.above.net [64.125.30.173] 8 3 ms 3 ms 3 ms above-att.sjc7.us.above.net [64.125.13.50] 9 7 ms 7 ms 7 ms tbr1.sffca.ip.att.net [12.123.12.2] 10 6 ms 6 ms 6 ms gbr5.sffca.ip.att.net [12.122.11.74] 11 6 ms 6 ms 6 ms gar1.sj2ca.ip.att.net [12.122.2.253] 12 *** Request timed out. 13 *** Request timed out. 14 * ^C - From MIT: Tracing to: www.cisco.com 1 legacy26-0.default.csail.mit.edu (18.26.0.1) [AS3] 0 ms 0 ms 0 ms 2 kalgan.trantor.csail.mit.edu (128.30.0.245) [AS40] 0 ms 0 ms 0 ms 3 B24-RTR-2-CSAIL.MIT.EDU (18.4.7.1) [AS3] 0 ms 0 ms 0 ms 4 EXTERNAL-RTR-1-BACKBONE.MIT.EDU (18.168.0.18) [AS3] 1 ms 4 ms 2 ms 5 ge-6-23.car2.Boston1.Level3.net (4.79.2.1) [AS3356] 0 ms * 0 ms 6 * * ae-5-5.ebr1.NewYork1.Level3.net (4.69.132.250) [AS3356] 8 ms 7 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) [AS3356] 10 ms 5 ms 16 ms 8 ae-13-69.car3.NewYork1.Level3.net (4.68.16.5) [AS3356] 67 ms 59 ms 58 ms 9 att-level3-oc192.NewYork1.Level3.net (4.68.127.150) [AS3356] 17 ms 127 ms 12 ms 10 tbr1.n54ny.ip.att.net (12.123.3.57) [] [MPLS: Label 31537 Exp 0] 80 ms 79 ms 79 ms 11 12.122.16.153 (12.122.16.153) [] [MPLS: Label 19 Exp 0] 76 ms 77 ms 77 ms 12 cr1.cgcil.ip.att.net (12.122.1.190) [] [MPLS: Label 1188 Exp 0] 77 ms 76 ms 77 ms 13 12.122.17.146 (12.122.17.146) [] [MPLS: Label 31051 Exp 0] 77 ms 78 ms 78 ms 14 tbr1.sffca.ip.att.net (12.122.10.6) [] [MPLS: Label 31320 Exp 0] 78 ms 78 ms 78 ms 15 gbr5.sffca.ip.att.net (12.122.11.74) [] [MPLS: Label 323 Exp 0] 72 ms 71 ms 71 ms 16 gar1.sj2ca.ip.att.net (12.122.2.253) [] 76 ms 76 ms 77 ms 17 * * * 18 * * * 19 * * * 20 * * * - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGugixq1pz9mNUZTMRAnY3AKCIeE2oiRKl11ZRgsOLs/q6J5TyLwCgi/SQ mnTSn9TJY+yB2cjZSeKaulM= =DGbM -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
SBC Issues/Contact?
Anyone have a contact for sbc? They are preventing me from getting to cisco.com P:\>tracert cisco.com Tracing route to cisco.com [198.133.219.25] over a maximum of 30 hops: 1<1 ms<1 ms<1 ms 10.5.7.254 2<1 ms<1 ms<1 ms 209.10.21.253 328 ms28 ms28 ms 209.10.9.37 428 ms27 ms27 ms 209.10.9.25 528 ms27 ms27 ms g-1-0-0.core2.nyc15.qualitytech.com [209.10.10.186] 628 ms28 ms28 ms so-1-0-0.core1.cgx2.globix.net [209.10.10.161] 728 ms28 ms28 ms pos-2-0.peer1.cgx3.globix.net [209.10.12.82] 8 451 ms 455 ms 450 ms ex1-g1-0.eqchil.sbcglobal.net [206.223.119.79] 9 513 ms 499 ms 501 ms ded4-g8-3-0.sntc01.pbi.net [151.164.41.165] 10 *** Request timed out. 11 *** Request timed out. 12 *** Request timed out. 13 *** Request timed out. 14 *** Request timed out. 15 *** Request timed out. 16 *** Request timed out. 17 *** Request timed out. 18 *** Request timed out. 19 *** Request timed out. 20 *** Request timed out. 21 *** Request timed out. 22 **
nanog@nanog.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No idea -- maybe just a hiccup? - From my office in San Jose: %traceroute www.cisco.com Tracing route to www.cisco.com [198.133.219.25] over a maximum of 30 hops: [snip] 7 3 ms 3 ms 3 ms so-3-0-0.mpr2.sjc7.us.above.net [64.125.30.173] 8 3 ms 3 ms 3 ms above-att.sjc7.us.above.net [64.125.13.50] 9 7 ms 7 ms 7 ms tbr1.sffca.ip.att.net [12.123.12.2] 10 6 ms 6 ms 6 ms gbr5.sffca.ip.att.net [12.122.11.74] 11 6 ms 6 ms 6 ms gar1.sj2ca.ip.att.net [12.122.2.253] 12 *** Request timed out. 13 *** Request timed out. 14 * ^C - From MIT: Tracing to: www.cisco.com 1 legacy26-0.default.csail.mit.edu (18.26.0.1) [AS3] 0 ms 0 ms 0 ms 2 kalgan.trantor.csail.mit.edu (128.30.0.245) [AS40] 0 ms 0 ms 0 ms 3 B24-RTR-2-CSAIL.MIT.EDU (18.4.7.1) [AS3] 0 ms 0 ms 0 ms 4 EXTERNAL-RTR-1-BACKBONE.MIT.EDU (18.168.0.18) [AS3] 1 ms 4 ms 2 ms 5 ge-6-23.car2.Boston1.Level3.net (4.79.2.1) [AS3356] 0 ms * 0 ms 6 * * ae-5-5.ebr1.NewYork1.Level3.net (4.69.132.250) [AS3356] 8 ms 7 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) [AS3356] 10 ms 5 ms 16 ms 8 ae-13-69.car3.NewYork1.Level3.net (4.68.16.5) [AS3356] 67 ms 59 ms 58 ms 9 att-level3-oc192.NewYork1.Level3.net (4.68.127.150) [AS3356] 17 ms 127 ms 12 ms 10 tbr1.n54ny.ip.att.net (12.123.3.57) [] [MPLS: Label 31537 Exp 0] 80 ms 79 ms 79 ms 11 12.122.16.153 (12.122.16.153) [] [MPLS: Label 19 Exp 0] 76 ms 77 ms 77 ms 12 cr1.cgcil.ip.att.net (12.122.1.190) [] [MPLS: Label 1188 Exp 0] 77 ms 76 ms 77 ms 13 12.122.17.146 (12.122.17.146) [] [MPLS: Label 31051 Exp 0] 77 ms 78 ms 78 ms 14 tbr1.sffca.ip.att.net (12.122.10.6) [] [MPLS: Label 31320 Exp 0] 78 ms 78 ms 78 ms 15 gbr5.sffca.ip.att.net (12.122.11.74) [] [MPLS: Label 323 Exp 0] 72 ms 71 ms 71 ms 16 gar1.sj2ca.ip.att.net (12.122.2.253) [] 76 ms 76 ms 77 ms 17 * * * 18 * * * 19 * * * 20 * * * - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGugixq1pz9mNUZTMRAnY3AKCIeE2oiRKl11ZRgsOLs/q6J5TyLwCgi/SQ mnTSn9TJY+yB2cjZSeKaulM= =DGbM -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: large organization nameservers sending icmp packets to dns servers.
> 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 features because you can't > be > > sure if someone else hasn't broken something intentionally. > > I don't really have a dog in this fight about TCP 53. It does seem to me > that it's a bit black and white to treat the RFCs as religious texts. > It's important to follow them wherever possible, but frankly they don't > foresee the bulk of the future security issues that usually materialize. > So if a feature of the RFC isn't working for you security-wise, I > believe it's your call to break with it there. As someone else said, > don't complain when it breaks other things as well however. It is worth noting that we are not talking about just RFCs here, but STD or "Internet Standards". RFCs are a variety of things, but when they become Internet Standards, they are supposed to be mandatory. That said, the STD makes opening TCP/53 non-mandatory as it is labeled as a "SHOULD", not a "MUST". Those blocking tcp/53 maybe stupid to do so, but they are only violating a strong recommendation and not a requirement. As is often pointed out, blocking port 53 will eventually almost certainly break something and I have yet to see a good argument for blocking TCP/53. > > > 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 its possible to disagree without calling other folks stupid... While the folks blocking or suggesting blocking TCP/53 may not be stupid, the act blocking it is. (Intelligent people do stupid things.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpZyICi3QW2r.pgp Description: PGP signature
Re: large organization nameservers sending icmp packets to dns servers.
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 shell code can you stuff in a 512 byte DNS UDP packet? How many bytes of shell code can you stuff in a TCP DNS connection? Rgds, -drc P.S. I still think blocking TCP/53 is stupid.
Re: large organization nameservers sending icmp packets to dns servers.
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 don't have them in your cache. See the following four queries for an example. (First three from my cache, fourth from AOL.) ; <<>> DiG 9.3.1 <<>> aol.com any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15075 ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;aol.com. IN ANY ;; ANSWER SECTION: aol.com.1790IN NS dns-06.ns.aol.com. aol.com.1790IN NS dns-07.ns.aol.com. aol.com.1790IN NS dns-01.ns.aol.com. aol.com.1790IN NS dns-02.ns.aol.com. aol.com.2802IN MX 15 mailin-04.mx.aol.com. aol.com.2802IN MX 15 mailin-01.mx.aol.com. aol.com.2802IN MX 15 mailin-02.mx.aol.com. aol.com.2802IN MX 15 mailin-03.mx.aol.com. ;; AUTHORITY SECTION: aol.com.1790IN NS dns-02.ns.aol.com. aol.com.1790IN NS dns-06.ns.aol.com. aol.com.1790IN NS dns-07.ns.aol.com. aol.com.1790IN NS dns-01.ns.aol.com. ;; ADDITIONAL SECTION: dns-01.ns.aol.com. 115155 IN A 64.12.51.132 dns-02.ns.aol.com. 115817 IN A 205.188.157.232 dns-06.ns.aol.com. 12385 IN A 149.174.54.153 dns-07.ns.aol.com. 116305 IN A 64.236.1.107 ;; Query time: 7 msec ;; SERVER: 131.111.8.42#53(131.111.8.42) ;; WHEN: Wed Aug 8 16:18:21 2007 ;; MSG SIZE rcvd: 339 ; <<>> DiG 9.3.1 <<>> aol.com. txt ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17924 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 2 ;; QUESTION SECTION: ;aol.com. IN TXT ;; ANSWER SECTION: aol.com.300 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" aol.com.300 IN TXT "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" ;; AUTHORITY SECTION: aol.com.1679IN NS dns-06.ns.aol.com. aol.com.1679IN NS dns-07.ns.aol.com. aol.com.1679IN NS dns-01.ns.aol.com. aol.com.1679IN NS dns-02.ns.aol.com. ;; ADDITIONAL SECTION: dns-01.ns.aol.com. 115044 IN A 64.12.51.132 dns-02.ns.aol.com. 115706 IN A 205.188.157.232 ;; Query time: 80 msec ;; SERVER: 131.111.8.42#53(131.111.8.42) ;; WHEN: Wed Aug 8 16:20:12 2007 ;; MSG SIZE rcvd: 512 ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.3.1 <<>> aol.com. any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1265 ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;aol.com. IN ANY ;; ANSWER SECTION: aol.com.298 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" aol.com.298 IN TXT "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" aol.com.1677IN NS dns-07.ns.aol.com. aol.com.1677IN NS dns-01.ns.aol.com. aol.com.1677IN NS dns-02.ns.aol.com. aol.com.1677IN NS dns-06.ns.aol.com. aol.com.2689IN MX 15 mailin-02.mx.aol.com. aol.com.2689IN MX 15 mailin-03.mx.aol.com. aol.com.2689IN MX 15 mailin-04.mx.aol.com. aol.com.2689IN MX 15 mailin-01.mx.aol.com. ;; AUTHORITY SECTION: aol.com.1677IN NS dns-06.ns.aol.com. aol.com.1677IN NS dns-07.ns.aol.com. aol.com.1677IN NS dns-01.ns.aol.com. aol.com.1677IN NS dns-02.ns.aol.com. ;; ADDITIONAL SECTION: dns-01.ns.aol.com. 115042 IN A 64.12.51.132 dns-02.ns.aol.com.
Re: large organization nameservers sending icmp packets to dns servers.
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's the SAME piece of software answering the query either way. There are people (I believe; this is a little rumour-laden) who take the approach that 53/tcp is actually safer than 53/udp, since the handshake makes it easier to believe the query's source address. The approach I heard about was to reply to UDP-transport queries with some minimal answer set with TC set, and serve a more useful set of information over TCP once the re-query arrives. [I realise that the state involved in handing TCP queries on a busy server is non-trivial, and that there are many aspects to this approach which deserve raised eyebrows.] However, my point is that "TCP is more secure than UDP" also has a posse. Joe
Re: large organization nameservers sending icmp packets to dns servers.
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 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. I'd hazard a guess and say something like "TCP state complexity > UDP state complexity" and that possibly leading to a potential DoS. But then, there's also stuff like stateful firewalls which can more aggressively timeout UDP flows (and not break DNS ones, since they're not exactly long-living!) but die under large TCP loads. And TCP takes CPU to setup/teardown, and requires client-side state. Adrian
Re: large organization nameservers sending icmp packets to dns servers.
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 or X.25/CLNP. However, if you actually want to talk to the outside world, a higher level of cooperation is required. The hard-to-answer question is where the "best" tradeoff of "however you want" and "industry standards and best practices" lies for a given provider, because the answer is of course different for each site. pgpTBS6A7NTU4.pgp Description: PGP signature
RE: large organization nameservers sending icmp packets to dns servers.
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 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. Jamie Bowden -- "It was half way to Rivendell when the drugs began to take hold" Hunter S Tolkien "Fear and Loathing in Barad Dur" Iain Bowen <[EMAIL PROTECTED]> -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 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 particular argument, which doesn't seem to be going anywhere useful. But I think the style of the argument causes some problems that trickle into network operations, and should be addressed. The problem with this argument is that, while it may be entirely correct, it's unlikely to convince the people who matter. The people who matter are the people who write the checks for the networks we work on. Successful managers (and successful engineers) generally get pretty good at doing cost benefit analyses. Since there are many decisions where there isn't one obvious answer, they learn instead to think in terms of each choice providing some benefits and having some costs, and doing the things where the benefits outweigh the costs. In the firewall case, as Kevin said, there are probably people going to the decision makers and talking about the importance of keeping things closed up. Every open firewall rule, they'll say, creates the potential for an attack. Any attack could cause down time, unauthorized sharing of confidential data, loss of files people have spent the last several years working on, and more. Therefore, the cost of an open firewall rule could potentially be millions of dollars. The value of any service enabled by a hole in the firewall had better be more than that. Is this argument valid? Maybe not. But the money people who make the decisions probably don't have the technical expertise to analyse it. Even if they suspect that the case for the policy is overstated, they'll associate some cost with ignoring the advice of their security people, as they probably should. So, what's somebody who objects to such an argument to do? You could go to management and say, "the security people are wrong. The standard says we must open more ports. To not do so would be wrong." But you may not like the choice this presents management with. On one side, they've got you telling them to follow an arbitrary standard, because not doing so would be wrong. On the other side, they're being told that taking your advice could cost millions of dollars. Losing millions of dollars as a result of a refusal to heed warnings would probably get them fired, or worse. Pointing at an arbitrary standard after things had gone wrong probably wouldn't get them very far. Alternatively, you too could start speaking their cost benefit language. You could assail the security peoples' cost figures, although at that point you'd be asking them to distrust other employees and they might wonder if they should distrust you instead. Or you could point out the costs of leaving the port closed, or possible benefits of leaving it open. If you can tell them that some fraction of their customers aren't able to get to them because of the closed port, and that those would be customers represent some large amount of revenue, you'll show that there's actual benefit to having the port open. If that benefit is greater than the potential loss they're being told about, you might actually win the argument. If you have some evidence to back up your numbers, you may have more credibility, and be able to win the argument with lower numbers. Or, you may find that you're not as right as you thought you were. You may find that what you were advocating doesn't seem to have any concrete benefit, and that what the other side was saying has some merit. That may not happen in this case, but sooner or later you'll probably find one where it does. -Steve
Re: large organization nameservers sending icmp packets to dns servers.
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. Remember the old adage: "My network, My rules"? Have we forgotten that? No, that's the point. The Internet is based on cooperation. You can run your network however you want, but if you fail to cooperate, other people will exercise their right to run their network how they want by blacklisting you. So we are in violent agreement. IOW: Your first word is incorrect. It _IS_ my network, and you agree it is my network, and you agree I am allowed to run it as I please. In return, I agree you can run your network as you please, even if that includes blacklisting me. Should I not block ports for MS protocols when a new worm spreads because it would break the E-2-E principal? What about spam filtering? Or a myriad of other things. Everyone here is breaking some RFC somehow. And most of us don't give a rats ass. Which is the way it should be. Fine, so long as you don't break the promises you make to other networks. If you do that, you wreck the cooperation fabric the Internet is based on. 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"? But when you decide that YOUR violation is MY problem to fix, then you are just being silly. And worse, annoying. Let's all just agree to run our own networks the way we damned well please, as long as we are not hurting anyone else. We just have to define "omplaining to you about things I b0rk'ed by myself" as "hurting you". Which isn't a stretch, support costs money, and costing me money because you screwed up is definitely hurtful. When you promise to provide a service to anyone who asks for it and then fail to, you impose costs on other people. Failing to resolve names that you claim you will resolve is just such a failure. It forces other people's resolvers to do extra work to get the information they need or they just can't get it. This is, IMO, the type of cooperation failure that justifies blacklisting. You are very, very confused. When you ask me to resolve a name, _I_ did not cost _you_ anything - just the opposite. This is true whether I send you an A record or not. The idea that you can force me to provide service for you without payment, contract, service in trade, etc., has not been true for a couple decades. The idea that I might, out of the goodness of my heart, provide services for others is still alive and well. But to expect it is only going to cause you all kinds of problems, even from the people who have goodness in their hearts. But hey, feel free to disagree and blacklist away. Your network, your decision. :) -- TTFN, patrick
