February 2004 - NANOG - lists.nanog.org

Road Runner refusing us, others?
by Mark Jeftovic 04 Feb '04

04 Feb '04

Road Runner is refusing our email forwarders again, according to one of customers they are also refusing yahoo as well, maybe a few others. Anyone else? Can somebody from RoadRunner contact us off list? > > Final-Recipient: rfc822; > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Postfix; host nymx-1.nyroc.rr.com[24.92.226.159] > said: 550 > 5.7.1 Mail Refused - 216.220.40 - See > http://security.rr.com/mail_blocks.htm#security - 20040203 >

1 0

Re: Poor connectivity to new b.root-servers.net address?
by sthaug＠nethelp.no 04 Feb '04

04 Feb '04

> the problem seems to be in the level3/cenic/losnettos path. > > juniper -ge- gsr -ge- foundary -ge- foundary -ge- foundary -100m- 7513 > > the IP path is: > > juniper - 7513 > > more as we unearth the problems... What I didn't mention in my original post is that this problem has existed, as far as I can see, since B was moved to a new address. Anyway - it seems things are fixed now. DNS lookup, traceroute and ping work from AS 2116 (source address 193.71.2.2) and AS 3307 (source address 194.19.15.2). There are still timeouts at the router hop before 130.152.181.66, which looks like it should be 67.30.130.66, traceroute'ing from 193.71.2.2 and 194.19.15.2: 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 188.092 ms so-9-0.hsa1.Tustin1.Level3.net (209.244.27.174) 188.118 ms 187.955 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 177.112 ms 177.141 ms 177.202 ms and 13 so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 188.861 ms 188.604 ms so-8-0.hsa1.Tustin1.Level3.net (209.244.27.166) 188.947 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 187.970 ms 187.573 ms 187.399 ms The missing hop here is visible as 67.30.130.66 coming from 129.241.1.16 (AS 224). I'm not going to worry too much about the traceroute timeouts, even if it would be nice if that could also be fixed. The main point is that DNS lookups are now working as they should. Thanks! Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

antivirus in smtp, good or bad?
by Stephen J. Wilcox 04 Feb '04

04 Feb '04

Hi, When investigating our mail queue it seems we have quite a lot of mails which are stuck in transit... Whats happening is we're accepting the mail as the primary MX for the domain but the user has setup a forwarding to another account at another ISP, they have antivirus service on that other account. So we get the mail, spool it and try to forward it but then we get a "550 Error: Suspected W32/MyDoom@MM virus" after DATA and our server freezes the mail. Surely this is an incorrect way to do this as there will be lots of similar MXs like ours backing this mail up? They should accept the mail and then bounce it? Thoughts? Steve

4 5

Re: Unbelievable Spam.
by Michael.Dillon＠radianz.com 04 Feb '04

04 Feb '04

>> Spam Hosting - from 20$ per mounth. >> Fraud Hosting - from 30$ per mounth. >> Stoln Credit Cards, Fake ID, DL's. >This is known as "Rule #3" on n.a.n-a.e... Spammers are stupid. Stupid!? These spammers are not stupid. There are very few legitimate businesses which can actually turn a profit from spamming. Most of the money to be made is in selling spam related software and services to suckers. The problem is, how do you identify people who are dumb enough to think that spam services are worth paying for? Simple. You send lots of spam which, by definition, only goes to people who know something about the Internet and might be willing to spend money on an Internet-related service. Then you wait for responses which, by definition, are only going to come from grade A suckers. Then you pounce on these hapless marks, rip them off and move on. Spammers are not stupid. They are smart criminal gangs which have not only managed to keep their schemes running for several years in the face of great public animosity, they have also managed to sabotage the efforts that supposedly work against them. A favorite trick is for them to go into a forum like NANAE and support a flawed anti-spam effort because they know that it keeps people from focusing on real solutions. The net effect of all of these flawed technical attacks on spam is that it has filtered out the naive spammers from the spamming community and left spamming in the control of criminal gangs. When will we realize that SPAM is a social problem and it needs a social solution? When will the major email providers sit down around a table and agree to some guidelines for email exchange that make it impossible for rogue users to inject large volumes of email into the system? The existing non-hierarchical email exchange network is not scalable. I hope that everyone on this list can understand what the email exchange overlay network is and recognize that it is subject to similar scaling rules as the underlying IP network. --Michael Dillon

7 6

Latest IE patch breaking non username:password@encoded websites?
by Herman Harless 04 Feb '04

04 Feb '04

We're starting to take complaints from folks who have installed the latest IE patch about various broken website functionality. The complaints are not related to folks trying to use the username:password@ functionality that was removed by the patch. Is anyone taking similar calls / seeing similar issues? Herman Harless Director, Advanced Data Network Engineering and Operations NTELOS, Inc. herman(a)ntelos.net

9 8

RE: Latest IE patch breaking non username:password@encoded websites?
by Herman Harless 04 Feb '04

04 Feb '04

Sorry - Mostly non-password encoded forms that don't refresh when you hit submit. After Submitting 3 or 4 times they seem to work. Like most ISP's, we take calls when somebody's web site doesn't work, even if we don't even host it. On Tue, 2004-02-03 at 12:24, Conrad Golightly wrote: > Can you give us some more detail about what they ARE seeing? > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Herman Harless > Sent: Tuesday, February 03, 2004 11:27 AM > To: nanog > Subject: Latest IE patch breaking non username:password@encoded > websites? > > > > We're starting to take complaints from folks who have installed the > latest IE patch about various broken website functionality. The > complaints are not related to folks trying to use the username:password@ > functionality that was removed by the patch. > > Is anyone taking similar calls / seeing similar issues? > > Herman Harless > Director, Advanced Data Network Engineering and Operations NTELOS, Inc. > herman(a)ntelos.net > > > > > --- > [This E-mail scanned for viruses] > > >

2 1

Re: Poor connectivity to new b.root-servers.net address?
by Simon Waters 03 Feb '04

03 Feb '04

NANOG Digest wrote: > > 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 178.710 ms 178.529 ms 178.500 ms > 14 * * * > 15 130.152.181.66 (130.152.181.66) 177.340 ms 177.246 ms 177.298 ms > 16 * * * I see something similar to this coming out of Level3 from Demon's direction. The was mentioned in comp.protocols.dns.bind, where some additional traceroutes and information is available, although it is clearly(?) a routing issue and I suggested here was a good place to ask for help. Still we have enough root servers to be going on with while it is fixed, lets just hope no one hijacked it.

5 7

Re: Strange public traceroutes return private RFC1918 addresses
by Kevin Oberman 03 Feb '04

03 Feb '04

> From: "Terry Baranski" <tbaranski(a)mail.com> > Date: Tue, 3 Feb 2004 16:42:55 -0600 > Sender: owner-nanog(a)merit.edu > > > Leo Bicknell wrote: > > > Since most POS is 4470, adding a jumbo frame GigE edge makes > > this application work much more efficiently, even if it doesn't > > enable jumbo (9k) frames end to end. The interesting thing > > here is it means there absolutely is a PMTU issue, a 9K edge > > with a 4470 core. > > This brings up the question of what other MTUs are common on the > Internet, as well as which ones are simply defaults (i.e., could easily > be increased) and which ones are the result of device/protocol > limitations. > > And why 4470 for POS? Did everyone borrow a vendor's FDDI-like default > or is there a technical reason? PPP seems able to use 64k packets (as > can the frame-based version of GFP, incidentally, POS's likely > replacement). 4470 was, as you surmised, to allow a full sized FDDI packet to be packed into a single POS packet. At the time FDDI was using larger packets than anything else. Now the recommendation for research and education networks (Abilene, ESnet, NASA, and many Asian and European R&Es) is 9000 and, within that community, is almost universally adopted when the hardware will support it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634

1 0

Re: B.root-servers renumbering
by Daniel Kerr 03 Feb '04

03 Feb '04

On Jan 30, 2004, at 4:26 AM, John L Crain wrote: <snip> > New Hints files can be found at: > > ftp://rs.internic.net/domain/db.cache > ftp://rs.internic.net/domain/named.cache > ftp://rs.ineternic.net/domain/named.root neophyte@afi:~$ whois ineternic.net Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. No match for "INETERNIC.NET". Cheers, -- Daniel Kerr

2 1

Poor connectivity to new b.root-servers.net address?
by sthaug＠nethelp.no 03 Feb '04

03 Feb '04

I have two sites (in AS 2116 and 3307) here in Norway which cannot reach the new b.root-servers.net address, 192.228.79.201. No answers to DNS requests, no ping replies, traceroute times out. Everything works normally from a third site, in AS 224. Both prefixes (193.71.0.0/16 and 194.19.0.0/17) of the problem addresses are visible on route-views.oregon-ix.net, via multiple paths. Any suggestions why this is happening? Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no --------------------------------------------------- traceroute from AS 2116 (source address 193.71.2.2): 1 vortex-e1 (193.69.2.1) 0.211 ms 0.168 ms 0.148 ms 2 v560.rs1.osl-sand.inet.catchcom.no (193.75.4.117) 0.364 ms 0.376 ms 0.324 ms 3 ge-0-2-0-202.br3.gaus.no.catchbone.net (193.75.3.61) 0.831 ms 0.991 ms 0.718 ms 4 so-0-3-0.ar1.OSL1.gblx.net (64.213.23.65) 0.728 ms 0.717 ms 0.824 ms 5 pos12-0-2488M.cr2.HAM1.gblx.net (67.17.74.185) 18.857 ms 18.855 ms 19.101 ms 6 so0-0-0-2488M.cr2.LON3.gblx.net (67.17.64.38) 43.637 ms 43.511 ms 43.546 ms 7 so7-0-0-2488M.ar2.LON3.gblx.net (67.17.66.30) 43.604 ms 43.869 ms 43.626 ms 8 Level-3public-peering.ge-5-0-0.ar2.LON3.gblx.net (208.51.239.162) 43.768 ms 43.852 ms 43.923 ms 9 ae-0-55.mp1.London1.Level3.net (212.187.131.161) 44.186 ms 44.197 ms 44.149 ms 10 so-1-0-0.mp1.London2.Level3.net (212.187.128.49) 44.388 ms 44.417 ms 44.245 ms 11 so-1-0-0.bbr1.Washington1.Level3.net (212.187.128.138) 117.160 ms 117.296 ms 116.990 ms 12 so-3-0-0.mpls1.Tustin1.Level3.net (209.247.8.121) 178.607 ms 178.837 ms 178.576 ms 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 178.710 ms 178.529 ms 178.500 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 177.340 ms 177.246 ms 177.298 ms 16 * * * traceroute from AS 3307 (source address 194.19.15.2): 1 nethelp-gw.banetele.net (194.19.15.1) 0.987 ms 0.891 ms 0.882 ms 2 oslo-a2.banetele.net (194.19.80.13) 6.389 ms 6.234 ms 6.205 ms 3 sand.osl.banetele.net (194.19.81.45) 6.498 ms 6.337 ms 6.332 ms 4 if-1-2.core2.Oslo.teleglobe.net (80.231.89.21) 7.128 ms 6.739 ms 6.796 ms 5 if-5-0.core1.Oslo.teleglobe.net (80.231.88.5) 119.151 ms 119.004 ms 119.184 ms 6 if-4-11.core2.London2.teleglobe.net (80.231.88.14) 210.376 ms 199.959 ms 206.017 ms 7 if-9-0.core2.Newark.Teleglobe.net (66.110.8.141) 118.323 ms 118.300 ms 118.073 ms 8 if-7-0.core1.Newark.Teleglobe.net (207.45.222.161) 117.308 ms 117.072 ms 116.978 ms 9 if-5-0.core2.Ashburn.Teleglobe.net (66.110.8.17) 116.370 ms 116.979 ms 116.195 ms 10 so-1-2-0.e1.Washington1.Level3.net (65.59.88.209) 113.998 ms 113.905 ms 113.767 ms 11 so-2-1-0.bbr1.Washington1.Level3.net (209.244.11.9) 114.371 ms 113.935 ms 113.795 ms 12 so-1-0-0.mpls2.Tustin1.Level3.net (209.247.8.117) 183.813 ms 183.557 ms 183.711 ms 13 so-8-0.hsa1.Tustin1.Level3.net (209.244.27.166) 183.242 ms 183.647 ms so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 183.154 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 182.641 ms 182.046 ms 185.201 ms 16 * * * traceroute from AS 224 (source address 129.241.1.16): 1 runit-sw1.runit.no (129.241.1.1) 5.753 ms 2.719 ms 0.953 ms 2 runit-gw.runit.no (129.241.249.77) 15.607 ms 13.284 ms 16.016 ms 3 trd-gw (129.241.249.14) 14.025 ms 14.839 ms 10.817 ms 4 oslo-gw1 (128.39.46.1) 22.427 ms 18.854 ms 20.827 ms 5 no-gw.nordu.net (193.10.68.101) 18.472 ms 20.159 ms 21.216 ms 6 se-kth.nordu.net (193.10.68.29) 29.554 ms 29.238 ms 29.233 ms 7 so-1-0.hsa2.Stockholm1.Level3.net (213.242.69.21) 28.094 ms 27.161 ms 29.325 ms 8 so-4-1-0.mp2.Stockholm1.Level3.net (213.242.68.205) 30.072 ms 27.242 ms 25.611 ms 9 so-0-0-0.mp1.London2.Level3.net (212.187.128.61) 61.408 ms 59.909 ms 65.957 ms 10 so-1-0-0.bbr1.Washington1.Level3.net (212.187.128.138) 137.661 ms 134.997 ms 136.561 ms 11 so-1-0-0.mpls2.Tustin1.Level3.net (209.247.8.117) 196.734 ms 198.486 ms 202.194 ms 12 so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 201.479 ms 199.805 ms so-8-0.hsa1.Tustin1.Level3.net (209.244.27.166) 198.810 ms 13 67.30.130.66 (67.30.130.66) 216.913 ms 215.330 ms 214.481 ms 14 130.152.181.66 (130.152.181.66) 214.449 ms 217.795 ms 211.176 ms 15 b.root-servers.net (192.228.79.201) 216.927 ms 211.889 ms 213.429 ms

3 2