- NANOG - lists.nanog.org

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

Re: antivirus in smtp, good or bad?
by Daniel Senie 03 Feb '04

03 Feb '04

At 08:58 AM 2/3/2004, you wrote: >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. Hmmm, well, we certainly kick back virus-laden stuff this way. The alternatives are: 1) kick it back during SMTP. 2) drop it on the floor. or, the third option, which is EXCEEDINGLY BROKEN, 3) send a bounce to the From: address in the email. Because of spoofed sender addresses, this then goes to the wrong person, freaks out innocent, non-infected people and raises everyone's support costs. >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? Why must systems accept mail that's virus laden or otherwise not desired at a site? The "bounce" you refer to invariably ends up going to the wrong person(s), so that's an exceptionally BAD idea. Many viruses (most of the recent ones) forge the sender information. So either accepting and silently dropping, or rejecting the SMTP session with a 55x are the only viable choices.

5 8

Re: [OT] Need Comcast Contact
by Tim Wesemann 03 Feb '04

03 Feb '04

> Well sure, they are sent on a date that doesn't exist. Feb 31 can never > happen. Pardon, that should have read Sunday, Feb 01 2004 AD (Chinese year of the monkey). =] -- Tim Wesemann Voicenet Systems Administration

1 0

does your ISP need more peering?
by Matthew Kaufman 03 Feb '04

03 Feb '04

A nationwide ISP I work with has decided to switch to all-transit, no-peering. They are interested in finding someone to buy or take over: an AS number, routers (and in some cases rack space) at MAE ATM East, PAIX Virginia, NYIIX, AADS NAP, MAE ATM West, and PAIX Palo Alto, along with the existing peering that is up at those (close to 200 BGP sessions total). If you're interested, please contact me directly and I will forward your inquiry in the correct direction. Note that my mailbox is protected by TMDA. Matthew Kaufman matthew(a)eeph.com ps. Please also direct flames about this being non-operational content directly to me as well... there's just not a lot of lists where names of NAPs and the concept of existing peers makes sense to anyone.

1 0

[OT] Need Comcast Contact
by Tim Wesemann 03 Feb '04

03 Feb '04

Emails sent *from residential comcast subscribers* to any '@voicenet.com' address have been disappearing in the Comcast network since Sunday, Feb 31. There are no bounces or errors of any kind. Mail sent directly to other domains with the same MX record and even to individual machines within the MX record themselves work fine, it is only when the envelope recipient states /^.*(a)voicenet\.com$/ does the mail simply disappear (i.e. mail sent to "someuser(a)voicenet.com" disappears while mail sent to "someuser(a)mail##.voicenet.com" goes through fine as well as "someuser(a)voicenet.net"). My company as well as our customers and Comcast customers have together made many, many phone calls and sent many emails and we cannot get ahold of anyone with any semblance of a clue and nobody seeems to have the ability to put us in contact with anyone in your systems and/or network admins (level 1-3 techs, managers and even "case resolution specialists"). Can someone please contact me off-list in regards to this situation? Has anyone else had similar problems? Thanks. -- Tim Wesemann Voicenet Systems Administration

1 0

RE: Strange public traceroutes return private RFC1918 addresses
by Michael.Dillon＠radianz.com 03 Feb '04

03 Feb '04

>> A more important question is what will happen as we move out >> of the 1500 byte Ethernet world into the jumbo gigE world. It's >> only a matter of time before end users will be running gigE >> networks and want to use jumbo MTUs on their Internet links. >The performance gain achieved by using jumbo frames outside of very >specific LAN scenarios is highly questionable, Did I say anything about performance? In any case, a lot of packets on the Internet have to traverse LANs at either edge and if jumbo packets can help on the LAN then people will use them. >and they're still not standardized. Precisely my point. We can do jumbo MTUs of various sizes today but we need to discuss some standard ways of setting these MTUs so that we avoid MTU bottlenecks in the core. That way PMTUD will continue to be a non-issue. > Are "jumbo" Internet MTUs seen as a pressing issue by >ISPs and vendors these days? Some people like to do forward planning instead of waiting until an issue hits them in the face. By definition, forward planning will never be dealing with pressing issues. --Michael Dillon

1 0

Strange public traceroutes return private RFC1918 addresses
by Brian (nanog-list) 03 Feb '04

03 Feb '04

Any ideas how (or why) the following traceroutes are leaking private RFC1918 addresses back to me when I do a traceroute? Maybe try from your side of the internet and see if you get the same types of responses. It's really strange to see 10/8's and 192.168/16 addresses coming from the public internet. Has this phenomenon been documented anywhere? Connectivity to the end-sites is fine, it's just the traceroutes that are strange. (initial few hops sanitized) [brian@testbox1 /]# traceroute www.ibm.com traceroute: Warning: www.ibm.com has multiple addresses; using 129.42.17.99 traceroute to www.ibm.com (129.42.17.99), 30 hops max, 38 byte packets 1 (---.---.---.---) 2.481 ms 2.444 ms 2.379 ms 2 (---.---.---.---) 17.964 ms 17.529 ms 17.632 ms 3 so-1-2.core1.Chicago1.Level3.net (209.0.225.1) 17.891 ms 17.985 ms 18.026 ms 4 so-11-0.core2.chicago1.level3.net (4.68.112.194) 18.272 ms 18.109 ms 17.795 ms 5 so-4-1-0.bbr2.chicago1.level3.net (4.68.112.197) 17.851 ms 17.859 ms 18.094 ms 6 so-3-0-0.mp1.stlouis1.level3.net (64.159.0.49) 23.095 ms 22.975 ms 22.998 ms 7 ge-7-1.hsa2.stlouis1.level3.net (64.159.4.130) 23.106 ms 23.237 ms 22.977 ms 8 unknown.level3.net (63.20.48.6) 24.264 ms 24.099 ms 24.154 ms 9 10.16.255.10 (10.16.255.10) 24.164 ms 24.108 ms 24.105 ms 10 * * * [brian@testbox1 /]# traceroute www.att.net traceroute: Warning: www.att.net has multiple addresses; using 204.127.166.135 traceroute to www.att.net (204.127.166.135), 30 hops max, 38 byte packets 1 (---.---.---.---) 2.404 ms 2.576 ms 2.389 ms 2 (---.---.---.---) 17.953 ms 18.170 ms 17.435 ms 3 500.pos2-1.gw10.chi2.alter.net (63.84.96.9) 18.077 ms * 18.628 ms 4 0.so-6-2-0.xl1.chi2.alter.net (152.63.69.170) 18.238 ms 18.321 ms 18.213 ms 5 0.so-6-1-0.BR6.CHI2.ALTER.NET (152.63.64.49) 18.269 ms 18.396 ms 18.329 ms 6 204.255.169.146 (204.255.169.146) 19.231 ms 19.042 ms 18.982 ms 7 tbr2-p012702.cgcil.ip.att.net (12.122.11.209) 20.530 ms 20.542 ms 23.033 ms 8 tbr2-cl7.sl9mo.ip.att.net (12.122.10.46) 26.904 ms 27.378 ms 27.320 ms 9 tbr1-cl2.sl9mo.ip.att.net (12.122.9.141) 27.194 ms 27.673 ms 26.677 ms 10 gbr1-p10.bgtmo.ip.att.net (12.122.4.69) 26.606 ms 28.026 ms 26.246 ms 11 12.122.248.250 (12.122.248.250) 27.296 ms 28.321 ms 28.997 ms 12 192.168.254.46 (192.168.254.46) 28.522 ms 30.111 ms 27.439 ms 13 * * * 14 * * *

7 7

Re: updated root hints file
by Doug Barton 03 Feb '04

03 Feb '04

Randy Bush wrote: > let's face it. we should be looking at the front page > of the <http://iana.org/> site to find root hints. there > we find <http://www.iana.org/domain-names.htm>, which seems > to be missing a link to the signed root hints. > > iana, could you please fix that? thanks. Good idea. I had that in mind along with some other changes for later this quarter, but given the amount of attention this topic is generating, I'll try to get something up asap. Thanks, Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority

1 0

wildly successful
by bill 03 Feb '04

03 Feb '04

so... funding found. nanog bound. ... hotel sold out? wow! --bill

1 0