- Test - lists.nanog.org

SDH on the cheap
by Kerplunkity Moo 03 Jul '08

03 Jul '08

Hello. Anyone have a suggestion or recommendation on a vendor for some cheap, but reliable, SDH gear? I don't need anything as powerful as the Ciena Core or Cisco 15454 and I'm wondering if there are alternatives to the alternatives? I need something to aggregate STM-4 and above to STM-64 client signal. Anything out there? Moo

3 4

Charter nntp administrator
by Chris Scheller 02 Jul '08

02 Jul '08

Could someone at charter please contact me off list. mutliple calls with various support groups yeilds nothing. thanks.

1 0

Possible explanations for a large hop in latency
by Frank Bulk 02 Jul '08

02 Jul '08

Our upstream provider has a connection to AT&T (12.88.71.13) where I relatively consistently measure with a RTT of 15 msec, but the next hop (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending that traffic over a cable modem or to Europe and back, I can't see a reason why there is a consistent ~70 msec jump in RTT. Hops farther along the route are just a few msec more each hop, so it doesn't appear that 12.122.112.22 has some kind of ICMP rate-limiting. Is this a real performance issue, or is there some logical explanation? Frank

12 17

what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
by Scott Francis 01 Jul '08

01 Jul '08

On Thu, Jun 26, 2008 at 9:01 PM, Jean-François Mezei <jfmezei(a)vaxination.ca> wrote: [snip conflict examples] > Finally, will there be any performance impact on DNS servers around the > world (thinking of caching issues) ? more to the point ... what problem is ICANN trying to solve with this proposal? What about the current system that's broken, does this new system fix? It looks like a lot of thought went into the process (thanks for the PDF link, DRC), and most of the issues raised here are addressed (conflicts, abuse/phishing grabs, etc.) - I'm just still unclear what the motivation for this new system was in the first place. I'm not opposed to it if it solves a legitimate technical/operational issue that's germaine to either the operators of the Internet or the users of the Internet, but so far I can't see that this serves either of those communities. In fact, it could very well be argued that a slew of new TLDs (whether a few dozen or a few hundred) will only serve to increase complexity and add additional confusion to a system that the standard user has just now come to grips with ("www.company.com will get me Company's official, legitimate page"). perhaps somebody with more insight can explain the rationale to me (DRC?) - is there a purpose served here aside from corporate/legal interests? thanks, -- darkuncle(a){gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key

33 79

can all current nanog threads move to nanog-ot@ plz?
by Paul Vixie 01 Jul '08

01 Jul '08

here's how it looks just before i hit the "catch up" button. [ 23: mailman-owner@nanog.] nanog.org mailing list memberships reminder [ 90: "James Hess" ] Re: DNS and potential energy < 155: Marshall Eubanks > [ 22: John Levine ] < 35: "Jay R. Ashworth" > < 119: Rob Pickering > < 21: Tony Finch > Y -[ 82: Jeroen Massar ] REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's [ 15: Roland Perry ] Re: what problem are we solving? (was Re: ICANN opens [ 10: Roland Perry ] Re: what problem are we solving? (was Re: ICANN opens up [ 12: Stephane Bortzmeyer ] Re: ICANN opens up Pandora's Box of new TLDs < 23: Tony Finch > < 50: Phil Regnauld > [ 36: David Conrad ] TLDs and file extensions (Re: DNS and potential energy) Y - [ 30: michael.dillon(a)bt.co] [ 31: "Jay R. Ashworth" ] Re: what problem are we solving? (was Re: ICANN opens up Pandora's [ 19: Joe Greco ] [ 135: "Jay R. Ashworth" ] RFC 1480 - does it generalize (was What Problem; was ICANN/Pandora) [ 60: Chris Owen ] Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: [ 26: "Jay R. Ashworth" ] Re: Mail Server best practices - was: Pandora's Box of new TLDs -- Paul Vixie

2 1

RE: what problem are we solving? (was Re: ICANN opens upPandora's Box of
by Gregory Hicks 01 Jul '08

01 Jul '08

> Subject: RE: what problem are we solving? (was Re: ICANN opens upPandora's Box of > Date: Tue, 1 Jul 2008 12:25:38 -0700 > From: "Tomas L. Byrnes" <tomb(a)byrneit.net> > To: "Jay R. Ashworth" <jra(a)baylink.com>, <nanog(a)nanog.org> > > Shouldn't we take all the ICANNt and DNS Related stuff to > dns-operations? Seems more "on-topic" there... > > > -----Original Message----- > From: Jay R. Ashworth [mailto:jra@baylink.com] > Sent: Tuesday, July 01, 2008 11:48 AM > To: nanog(a)nanog.org > Subject: Re: what problem are we solving? (was Re: ICANN opens > upPandora's Box of > > On Tue, Jul 01, 2008 at 12:04:57PM +0100, Roland Perry wrote: > > In article <20080630212216.GJ8195(a)cgi.jachomes.com>, Jay R. Ashworth > > <jra(a)baylink.com> writes > > >The Domain Name System is not now, and never has been, away to *find* > > > >things, anymore than 123 Elm St, Worcester MA is a way to *find* a > > >house. > > > > What about "1 Microsoft Way, Redmond, WA" ? > > Or 1 Tech Data Drive, Largo, or 1 Infinite Loop; yeah, there are lots of > good examples of why addresses are random and shouldn't be used to > *locate* things... except as keys into directories. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra(a)baylink.com > Designer The Things I Think > RFC 2100 > Ashworth & Associates http://baylink.pitas.com > '87 e24 > St Petersburg FL USA http://photo.imageinc.us +1 727 > 647 1274 > > Those who cast the vote decide nothing. > Those who count the vote decide everything. > -- (Joseph Stalin) > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.101 / Virus Database: 270.4.3/1528 - Release Date: 7/1/2008 > 7:26 AM > > --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 9B1 San Jose, CA 95134 I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

1 0

Packetloss while transiting as7018
by Brad Tarno 01 Jul '08

01 Jul '08

Any AT&T engineers willing to help me out? I'm seeing some significant packet loss but only when using our AT&T circuit. (USING AT&T) Source: 67.192.51.58 Destination: 24.73.68.114 traceroute to 24.73.68.114 (24.73.68.114), 30 hops max, 46 byte packets 1 72.3.242.2 (72.3.242.2) 0.569 ms 0.566 ms 0.606 ms 2 core3-120.dfw1.rackspace.net (72.3.129.128) 0.359 ms 0.338 ms 0.366 ms 3 vlan903.edge4.dfw1.rackspace.com (72.3.128.52) 0.484 ms 0.476 ms 0.366 ms 4 12.87.41.177 (12.87.41.177) 2.111 ms 1.980 ms 1.864 ms 5 tbr1.dlstx.ip.att.net (12.122.100.42) 2.485 ms 2.474 ms 2.613 ms MPLS Label=32334 CoS=0 TTL=127 S=0 6 * ggr3.dlstx.ip.att.net (12.123.16.193) 2.091 ms 1.962 ms 7 * 192.205.35.142 (192.205.35.142) 2.210 ms 2.212 ms 8 vlan89.csw3.Dallas1.Level3.net (4.68.19.190) 2.483 ms 12.595 ms * 9 ae-81-81.ebr1.Dallas1.Level3.net (4.69.136.129) 15.869 ms * 6.799 ms 10 ae-1-12.bar2.Tampa1.Level3.net (4.69.137.117) 59.553 ms 33.089 ms 33.075 ms 11 * * * 12 ROADRUNNER.car2.Tampa1.Level3.net (4.79.146.2) 33.198 ms 33.463 ms 33.288 ms 13 gig14-0.tampfledc-rtr2.tampflrdc.rr.com (65.32.13.34) 33.341 ms 33.190 ms * 14 gig14-1-0.tampflc03-ar41.tampflrdc.rr.com (65.32.24.113) 36.223 ms 35.200 ms * 15 rrcs-24-73-68-114.se.biz.rr.com (24.73.68.114) 46.048 ms * * --- 24.73.68.114 ping statistics --- 374 packets transmitted, 193 received, 48% packet loss, time 373296ms rtt min/avg/max/mdev = 42.010/44.140/65.817/2.757 ms, pipe 2 (NOT USING AT&T) traceroute to 24.73.68.114 (24.73.68.114), 30 hops max, 46 byte packets 1 72.3.242.2 (72.3.242.2) 0.598 ms 0.972 ms 0.606 ms 2 core3-120.dfw1.rackspace.net (72.3.129.128) 0.504 ms 0.468 ms 0.441 ms 3 vlan903.edge3.dfw1.rackspace.com (72.3.128.51) 1.914 ms 1.954 ms 1.992 ms 4 xe-8-1.r02.dllstx09.us.bb.gin.ntt.net (157.238.225.221) 2.098 ms 2.138 ms 1.986 ms 5 4.68.63.221 (4.68.63.221) 60.079 ms 2.060 ms 2.120 ms 6 vlan89.csw3.Dallas1.Level3.net (4.68.19.190) 2.419 ms 15.234 ms 2.244 ms 7 ae-81-81.ebr1.Dallas1.Level3.net (4.69.136.129) 2.758 ms 14.855 ms 2.995 ms 8 ae-1-12.bar2.Tampa1.Level3.net (4.69.137.117) 33.125 ms 32.968 ms 33.334 ms 9 ae-7-7.car2.Tampa1.Level3.net (4.69.133.41) 32.984 ms 32.956 ms 33.192 ms 10 ROADRUNNER.car2.Tampa1.Level3.net (4.79.146.2) 33.161 ms 33.068 ms 33.343 ms 11 gig10-0.tampfledc-rtr2.tampflrdc.rr.com (65.32.13.65) 33.213 ms gig14-0.tampfledc-rtr2.tampflrdc.rr.com (65.32.13.34) 33.085 ms 32.954 ms 12 gig14-1-0.tampflc03-ar41.tampflrdc.rr.com (65.32.24.113) 34.965 ms 35.080 ms 34.845 ms 13 rrcs-24-73-68-114.se.biz.rr.com (24.73.68.114) 42.830 ms 43.941 ms 44.589 ms --- 24.73.68.114 ping statistics --- 122 packets transmitted, 122 received, 0% packet loss, time 121191ms rtt min/avg/max/mdev = 41.699/43.900/46.118/1.060 ms, pipe 2 ============================ Brad Tarno Backbone Network Engineer Rackspace IT Hosting ============================ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse(a)rackspace.com, and delete the original message. Your cooperation is appreciated.

1 0

Re: ICANN opens up Pandora's Box of new TLDs
by Roger Marquis 01 Jul '08

01 Jul '08

Stephane Bortzmeyer bortzmeyer(a)nic.fr wrote: > I am very curious of what tests a "security-aware programmer" can do, > based on the domain name, which will not be possible tomorrow, should > ICANN allow a few more TLDs. The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}' and '[a-z0-9\-\.]*\.[a-z\-]*' is substantial from a security perspective. Aside from the IP issues it effectively precludes anyone from defining a hostname that cannot also be someone else's domain name. It's not too hard to see the problems with that. An analogous network scenario would be IP addresses of varying length and without a netmask. > If you test that the TLD exists... it will still work. Only if A) you are always online with B) reliable access to the tld's nameserver/s, and C) can deal with the latency. In practice this is often not the case. > If you test that the name matches (com|net|org|[a-z]{2}), then you are > not what I would call a "security-aware programmer". Will you still think that when someone buys the right to the .nic tld and starts harvesting your queries and query related traffic? Not that that doesn't happen now, to a far lesser degree. But it's the extent to which this presents new opportunities for black hats that should have given ICANN pause. Odds are that RBLs will be among the first targets. Bottom line is the decision was made for it's _monetization_ value, not security, and customer service was just a pretense. Roger Marquis

14 24

Re: DNS and potential energy
by Daniel Hagerty 01 Jul '08

01 Jul '08

Rob Pickering <rob(a)pickering.org> writes: > Or .com. Oddly enough I just now found a Windows box and typed > "command.com" in a browser URL bar and it did what I expected, when I > typed the same thing at a cmd prompt it did something different and I > expected that too. 1. Copy \windows\system32\cmd.exe to the desktop. 2. Run internet exploder. 3. Type "cmd.exe" in the address bar and observe what happens. I don't know about you, but given ie's default download location, and your (apparently common) erroneous expectation, this looks ripe for social engineering to me.

1 0

Re: ICANN opens up Pandora's Box of new TLDs
by Roger Marquis 01 Jul '08

01 Jul '08

Phil Regnauld wrote: > As business models go, it's a fine example of how to build demand > without really servicing the community. Of all the ways new tlds could have been implemented this has to be the most poorly thought out. Security-aware programmers will now be unable to apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts. The core problem seems to be financial, as this is likely the most revenue generating plan (both over and under the table) ICANN bean-counters could have dreamed up. It certainly was not the foreseen outcome when non-profit status was mandated. I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community. Roger Marquis

9 18