- Test - lists.nanog.org

Re: Non-existing domain
by trall＠almaden.ibm.com 25 Apr '99

25 Apr '99

>Is there any way to see if people have tried to get to non-existing >domains? I mean, if someone requests doda.org and it does not exist, is >the request logged anywhere? The only ones to know about that request would be one of authoritative nameservers for "org." (which happens to be the A-K root nameservers). Would they log it? Almost assuredly not (at least not in a log that they would keep for very long). It would be just another request for an undefined domain. Tony Rall

1 0

Re: address spoofing
by sthaug＠nethelp.no 25 Apr '99

25 Apr '99

> > then, you can have (if you want) another bind listening on other > > interfaces for other stuff. like the "internal dns" server that you > > mentioned. or maybe a recursive, caching-only server that listens > > only on 127.0.0.1. of course...they can speak to each other if need > > be. :) > > I tried 2 instances of BIND and they didn't work right. One functioned > and the other played dead (very dead ... as in the process blocked and > would not wake up). One needs 2 separate machines to get it to actually > work right (times the amount of redundancy desired). If you know the > magic to make it work right, I'd sure like to know. Maybe some kind of > lock somewhere? Works great here. You need to make sure that each bind instance has its own set of named.conf/zone files/pid file/ndc channel, that they bind to different interfaces. I also like to force them to have different query ports, but this shouldn't be necessary as long as they are on different interfaces. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

OUTAGE: Central Florida
by Sean Donelan 24 Apr '99

24 Apr '99

MCI is reporting multiple circuits (DS3 and higher) have gone down somewhere in Florida. As of yet, they are unable to pinpoint the exact location or the extent of the outage. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Contact handles disappearing mysteriously from the whois database!
by John Fraizer 24 Apr '99

24 Apr '99

Everyone take a moment and check your NIC handles in the whois database. We have noted two that have vanished within the past week. ------------------------------------------------------------------ ML.ORG is gone. Check out http://www.EZ-IP.Net - It's *FREE* ------------------------------------------------------------------ Get your *FREE* Parked Domain account at http://www.EZ-Hosting.Com ------------------------------------------------------------------ John Fraizer | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation PGP Key fingerprint = 7DB6 1CA2 DAA6 43DA 3AAF 44CD 258C 3D7E B425 81A8

3 2

Re: address spoofing
by sthaug＠nethelp.no 24 Apr '99

24 Apr '99

> means that packets with source addresses from RFC 1918 space should not be > permitted on the global internet. While I agree that RFC 1918 addresses > should not be used on internet visible interfaces, I'm unaware of anywhere > in the RFC's where it says that "routers should be configured to reject > packets coming from RFC 1918 space." As others have pointed out, there are indeed RFC sections which seem to imply that packets coming from RFC 1918 space should not be visible on the global Internet. Furthermore, whether the RFC says so or not, I'm going to block these packets at *my* border routers, because: - I have absolutely *no* idea of where these packets might be coming from, - and I have no possibility of generating sensible replies to packets with RFC 1918 source addresses. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

8 7

Re: address spoofing
by sthaug＠nethelp.no 23 Apr '99

23 Apr '99

> > Furthermore, whether the RFC [1918] says so or not, I'm going to block > > these packets at *my* border routers, because: > > Curious as to the cost (added latency) in doing RFC 1918 source address > filtering on all packets in the context of cost-benfit analysis. Well, we added filtering of spoofed source addresses (ie. our own) at our border routers quite a while ago. Adding filters for the RFC 1918 source addresses was a complete no-brainer - three more lines in a filter that already had around 15 lines. *No* visible (to us) increased processor load or latency. (I'm sure it can be measured - but in our case it's completely lost in the noise.) Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

FIBER CUT: Fire in Houston damages fiber
by Sean Donelan 23 Apr '99

23 Apr '99

A fiber reported carrying 3 OC-48 systems was damaged by fire in Houston, TX. The fire was at Pinemont & Rankin. Time-Warner is repairing/patching around the damaged fiber now. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

The Cidr Report
by Tony Bates 23 Apr '99

23 Apr '99

This is an auto-generated mail on Fri Apr 23 12:00:00 PDT 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 23Apr99 0) General Status Table History ------------- Date Prefixes 160499 58374 170499 58360 180499 58291 190499 58530 200499 58544 210499 58520 220499 58449 230499 58766 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 71.0.2.0/24 from AS1239 *** Bogus 221.43.160.0/19 from AS12323 AS Summary ---------- Number of ASes in routing system: 4930 Number of ASes announcing only one prefix: 2503 (1317 cidr, 1186 classful) Largest number of cidr routes: 375 announced by AS701 Largest number of classful routes: 801 announced by AS701 1) Gains by aggregating at the origin AS level --- 23Apr99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 360 148 212 58.9% BCnet Backbone AS577 291 181 110 37.8% Bell Canada Backbone AS4293 291 184 107 36.8% IMCI AS174 615 509 106 17.2% Performance Systems International AS4755 167 78 89 53.3% Videsh Sanchar Nigam Ltd. India AS2493 216 129 87 40.3% iSTAR Internet, Inc. AS3749 143 63 80 55.9% TECNET AS4200 175 100 75 42.9% AGIS (Apex Global Information Ser AS721 141 68 73 51.8% DLA-ASNBLOCK-AS AS1267 94 24 70 74.5% IUNET-AS AS7657 191 124 67 35.1% The Internet Group Limited AS7496 97 31 66 68.0% Power Up AS7545 110 46 64 58.2% TPG Internet Pty Ltd AS7046 261 198 63 24.1% UUNET-CUSTOMER AS1785 385 322 63 16.4% NYSERNet Backbone AS1221 449 387 62 13.8% AARNET-AS AS1239 527 467 60 11.4% SprintLink Backbone AS4740 331 274 57 17.2% Ozemail Pty Ltd (ASN-OZEMAIL) AS10928 110 53 57 51.8% UNKNOWN AS3493 238 184 54 22.7% INTERLINK AS719 470 417 53 11.3% LANLINK autonomous system AS72 92 40 52 56.5% Schlumberger Information Network AS803 79 35 44 55.7% SaskNet Backbone AS5674 80 36 44 55.0% PBI-NET-BLK AS3737 110 70 40 36.4% PenTeleData Inc. (ASN-PTD) AS1 508 473 35 6.9% BBNPLANET AS7122 109 77 32 29.4% MTS ADVANCED Network Policy AS9269 52 21 31 59.6% Hong Kong CTI AS4307 32 1 31 96.9% SVINET-1 AS11515 32 1 31 96.9% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: Peering Policies
by Sean Donelan 23 Apr '99

23 Apr '99

Why do these things always seem to happen in the spring time? tim(a)clipper.NET (Tim Wolfe) writes: >running over TCP seem to timeout with 2 second delays...) So in order to >maintain connectivity to both of these providers, one would need to buy >transit from each. How does this figure into the future political and >technical growth of the net? Wouldn't this type of apathy tend to push >toward government involvement in this industry? If the largest networks I don't see why. BT/Tymnet and GTE/Sprint/Telenet X.25 networks had miserable interconnectivity, and many people ended up buying connections to both. Or using the Internet instead, which killed both the x.25 network providers. Regulators did step into the telegraph business and require Western Union interconnect with its competitors, just about the time telegraphs ceased as a viable business. ILECs and CLECs are required to interconnect, but that doesn't seem to end problems with lack of inter-office trunks, restrooms, parking lots and other shenanigans. Government involvement doesn't seem to solve the problem. Settlements don't help either, because as we've seen in the ILEC/CLEC cases, one side just simply refuses to pay if it doesn't go the way they wanted. What has worked? Bad press, and customer reaction have stomped most of the peering battles in the past. After a big storm, both sides will issue non-specific press releases saying everything is hunky-dory again. As engineers, we might think there must be a better way. Sometimes the problems aren't technical, and don't have an engineering solution. Master tickets will get escalated to the seventh level senior network gods, and sit indefinitely. Ebbers and Esrey may not know a packet, but when the CEO's get asked about it on CNNfn, it will get fixed darn quick. If it doesn't get fixed? Well, does anyone even care what AGIS's peering policy is anymore? amb(a)gxn.NET (Alex Bligh) writes: >If you order the 5 largest IP networks by traffic profile, you >may get some surprises. Porn and Spam for $500! Traffic profiling will show there is a difference between where people say they go, and where they actually go. And the top 5 networks are not the ones you would expect. Of course, NDA's cover most of that information. >From a traffic engineering standpoint, the Internet is still very much a network of networks. I wouldn't sign any long term contracts with one provider just yet. Just look back 1, 3, 5 years at the changes in who's who. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: address spoofing
by Vern Paxson 23 Apr '99

23 Apr '99

> I actually have never seen a NAT box do this (but would like to hear > about such cases). I have traces of FTP PORT directives with Net 10 addresses in them, and even one in which a public address was included in the first PORT directive but a Net 10 address in a retransmission of the same directive! Vern

2 1