- Test - lists.nanog.org

Ameritech Security POC
by Richard Forno 05 Jan '03

05 Jan '03

Hi all - happy new year! Does anyone have a POC at Ameritech Security, particularly their abuse desk? Replies off line apprecited. Rick Infowarrior.org

1 0

FYI
by blitz 05 Jan '03

05 Jan '03

This was in my mailbox, might be old news to you, but a FYI >Coastal area silenced by cable break > > 01/04/03 Portland Oregonian > > JEFFREY KOSSEFF > > A fiber-optic line break cut off the southern Oregon coast from the >rest of the world for much of > Friday. > > After a state cleanup crew accidentally tore a > CenturyTel fiber-optic cable at 9:30 a.m., residents and > businesses from Reedsport to Brookings couldn't make > or receive phone calls outside of the area or connect to > the Internet. > > CenturyTel crews fixed the cable just before 5 p.m., > spokeswoman Carol Allen said. > > "I've been dying for my e-mail all day," Joseph Whitsett, > mayor-elect of Bandon, said after phone service was > restored. > > Most urban areas have more than one fiber line > connecting local phone systems to long-distance > networks, but less-populated regions typically depend > on one fiber route. The outage demonstrates the need > for companies to build multiple lines, creating backup > networks, telecommunications experts said. > > An Oregon Department of Transportation crew clearing > debris from a mudslide near Camas Valley on Friday > morning cut a cable that connects the south coast to a network hub in >Roseburg. > > Ted Paselk, an ODOT district manager, said before his workers dug >along Oregon 42, they gave > appropriate notice to a statewide utility hot line that locates >underground utilities. They weren't told of > the CenturyTel cable, he said. > > Neither Allen nor Paselk knew who would pay for the repair. > > "Usually, when a locate is called and they clear us in an area, then >we're not paying the bill," Paselk > said. > > Residents along the 135-mile stretch of the coast could call one >another, but they could not call > outside the area, said Melissa Barran, a spokeswoman for Verizon, the >local phone company for > most of the south coast region. Verizon connects its 50,000 area phone >lines to the long-distance > network over CenturyTel's cable. > > Calls to spots such as North Bend were met with a recorded message: >"Due to local telephone > company trouble in the area you are calling, your call cannot be >completed at this time. Please try > your call later." > > Besides blocking long-distance and Internet access for residents in >the region, the outage kept other > callers and Internet users from reaching phones or Web sites in the >area. > > Although cell phones don't require wires, long-distance cell-phone use >was out because cell towers > connect to the long-distance phone network over the CenturyTel cable. > > Unless residents had costly phone or Internet connections via >satellite, they were unable to > communicate with the rest of the state, nation and world. > > "We're just sitting at the mercy of the repair crews," said Joseph >Gayer, director of strategic > relations at Bend-based Edge Wireless, a rural cell-phone carrier >whose 9,000 customers in Coos > and Curry counties lost long-distance service as a result of the fiber >cut. > > Such outages have become more common since fiber-optic cable became >the main method of > transporting long-distance calls over the past decade, Gayer said. >Without more than one fiber line > in the same area, they will continue, he said. > > But laying fiber costs money, and many telecom carriers are reeling >from fiber-overbuilding in urban > areas. The largest investments in redundant loops came from the >state's largest local phone > company, Qwest Communications International. It spent $70 million on >network upgrades, including > five redundant fiber-optic loops throughout the state. > > In exchange for that improvement and investments in school technology, >the state deregulated > Qwest's profits. > > "Absent that kind of win-win situation for the company and the state, >it makes it very difficult to have > a business case (that will) pencil out that says, 'This is a good use >of capital dollars," said Judy > Peppler, Qwest's president for Oregon. "You're going to have some idle >capacity at all times. But on > the other hand, you don't have these outages." > > Qwest has completed construction of three of the fiber rings, and it >will finish the other two by > October. The backup networks have averted at least two outages in >rural areas. > > "It is obviously very valuable, especially when you have businesses >that rely on your network," > Peppler said. > > Irv Emmons, senior telecommunications engineer for the Oregon Public >Utility Commission, said > before Qwest built a backup network in Eastern Oregon, a farmer in >Madras cut the area's main fiber > cable a few times a year. > > "That used to isolate all of Eastern Oregon," Emmons said. > > Allen of CenturyTel said redundancy is "always of a high priority," >but she did not know whether > backup networks were in the works for the south coast area.

2 1

COM/NET informational message
by Verd, Brad 05 Jan '03

05 Jan '03

-----BEGIN PGP SIGNED MESSAGE----- This message explains an upcoming change in certain behavior of the com and net authoritative name servers related to internationalized domain names (IDNs). VeriSign Global Registry Services (VGRS) has been a longtime advocate of IDNs. Our IDN Test Bed has been active for over two years and we have followed and supported IETF developments in the IDN area. The protocol for IDNs developed by the IETF's IDN Working Group has been approved by the IESG and we anticipate that RFCs will be published soon. That protocol, Internationalizing Domain Names in Applications (IDNA), calls for changes to individual applications to support IDNs. VGRS has developed a plug-in, called i-Nav, for Microsoft's Internet Explorer browser to support IDNs in a manner consistent with IDNA. i-Nav is free and more information about it is available at <<http://www.idnnow.com>>. Before IDNA, some application developers had developed proprietary mechanisms designed to support IDNs. The Internet Explorer browser, for example, sends a DNS query in UTF-8 or another, local encoding when a user types a domain name with characters other than letters, digits and the hypen in the address bar. These efforts, however, were not entirely successful. For example, if such a domain name ends in com or net these queries reach the com/net name servers and fail. Our research indicates that the average user expects IDNs to work but does not understand the need for additional software to support this functionality. Such users attempt to enter IDNs in their browsers, but when the queries fail, they become frustrated and do not know what action to take to enable IDNs. They are unaware that downloading a browser plug-in such as i-Nav would enable IDN resolution. To improve this user experience and to encourage the adoption of an application that supports IDNA, VGRS is announcing a measure intended to stimulate widespread distribution of the i-Nav plug-in. Starting on January 3, 2003, some queries to the com/net name servers that previously failed with a DNS Name Error (NXDOMAIN) response will instead return an address (A) record. Any queries for A records with at least one octet greater than decimal 127 in the second-level label will trigger this A record response. For example, a query for the A record for "foo?.com", where "?" represents an octet with a value greater than 127, would return an A record rather than NXDOMAIN response. The goal is to match unrecognized domain names generated by browsers attempting to resolve IDNs. Since browsers construct DNS queries for such IDNs using UTF-8 or a local encoding, and since these encodings use octets with all possible values (i.e., from 0 through 255), the presence of octets with values greater than 127 as described above can indicate a web browser's failed IDN resolution attempt. The A record that will be returned by VGRS points to a farm of web servers that will attempt to resolve the query. The browser that sent the original DNS query will connect to one of these web servers and its HTTP request will contain a Host header with the representation of the IDN originally entered by the user in the address bar. The web servers will attempt to interpret the contents of the Host header. If the Host header corresponds to an IDN registered in VeriSign's IDN Test Bed, the web server will return a page that gives the user an opportunity to download the free i-Nav plug-in. The page will also allow the user to navigate to the corresponding IDN web site via an HTTP redirect. If the contents of the Host header cannot be matched to an IDN registered in the Testbed, the web server will return an HTTP 404 response. If a user downloads and installs the i-Nav plug-in, his or her browser will convert any IDNs entered to ASCII compatible encoding (ACE) format, according to the method described in IDNA. As a result, subsequent DNS queries will use ASCII characters only. The user experience for web browsing will change only slightly from the current experience if the contents of the Host header cannot be interpreted. If the web farm cannot match the Host header to an IDN, the user will see an error page resulting from the HTTP 404 error returned, rather than an error page resulting from a DNS NXDOMAIN response. The web servers refuse connections on all other UDP and TCP ports, so other network services are minimally affected. The overriding goal is to improve Internet navigation by encouraging widespread adoption of software supporting the emerging IETF standards for IDNs. These measures allow distribution of such software. - -------- Brad Verd Resolution Systems Operations Manager VeriSign Global Registry Services <<http://www.verisign-grs.com>> Email: bverd(a)verisign.com - -------- -----BEGIN PGP SIGNATURE----- Version: PGP 7.1 iQEVAwUBPhXOL/Al8hAO5uPhAQFASQgAuu9y0LF5/2SuddtdRNDbyUd9ccNkPwnw fip2bSh1EW7+b2jykw2tDxIAl2iejg2GVwhXmMiGOdm+FBOyBPtbQaM/DMCXHJ3r JlaEmKgqKwjyVHVxxEmNYHQ0uU5V8khskWorhsobjDb+l5bPumkUaGsVnRvTMFGR CZTrHdn1bo1Q0IvfD1IBCq5qUugRimLc47TZdibYccCty8TmdtL/8jz4r6W90JPL KxXdjMpk6SOQj1SqErV/S6ypd5TFpXi1fEv6QEIrsqVoMCdELjFRZbmDTAMObvcR MpS75jUWbNmO7KENJCyacWzLTkh951+dszszwYig9jGIIXEpmrYGFA== =g2df -----END PGP SIGNATURE-----

12 15

PowerDNS open source since 25th of November
by bert hubert 04 Jan '03

04 Jan '03

I humbly & grovelingly like to point out here that PowerDNS, the database (and ldap, perl, 'pipe' and bind zonefile) driven nameserver is open source. I think it may be useful for many operators here, especially as PDNS is well suited for 'BGP DNS' trickery. It is GPL licensed and is BIND compatible for the majority of authoritative setups. Many do not know this yet, probably in part due to the helpful moderators of comp.protocols.dns.bind, the DNS operators newsgroup on usenet, who drop messages about PowerDNS. BIND compatible means that you can point PDNS at your named.conf and have a working nameserver. It goes beyond BIND in adding cool commands such as 'pdns_control bind-list-rejects' that list all rejected zones, and the reason for their rejection, and at which time this happened. 'bind-domain-status' is the command that can tell you at which point in time all (or specific) zones were loaded, or a specific zone. 'bind-reload-now' tells PowerDNS to reload a zone from disk NOW. BIND mode is fast too, a Dutch ISP tested it with 56000 zones, some of which with 100.000 records, and it launched in 75 seconds on commodity hardware. Notably, PowerDNS answers questions while loading zones! It only answers about those zones that have been loaded, however. In database mode (PostgreSQL, MySQL, Oracle, DB2, ODBC) or in table mode ('XDB' -> tridge DB, dbm, berkely db2) or in LDAP mode, there is no startup time to speak of. In that case, the tool 'zone2sql' is provided to help with migration, which you can simply point at your named.conf. Other cool features, which are non-bin-dmode specific, include 'retrieve', which causes PDNS to retrieve a domain from its master *immediately*. Conversely, 'notify' causes PDNS to send out an immediate notification, whether PDNS considers the domain changed or not. 'notify-host' can be used to send a notification to a specific IP address, whether it is a master or not. The pipe-backend allows a coprocess (which accepts questions on stdin and provides answers on stdout) written in any language to do dynamic resolution, which is great for failover, loadbalancing or BGP DNS style tricks. See http://doc.powerdns.com/pipebackend-dynamic-resolution.html I invite you to check out http://doc.powerdns.com and http://www.powerdns.com/downloads and http://www.powerdns.org. Sample BIND-compatible pdns.conf is: launch=bind bind-config=/etc/bind/named.conf master slave Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting

3 2

Re: COM/NET informational message
by brandon＠rd.bbc.co.uk 03 Jan '03

03 Jan '03

> Am I the only one that finds this perversion of the DNS protocol > abhorrent and scary? Sounds like a fine interweb kludge It'll just be annoying until other applications aquire similar bodgery as the users will not understand why they can't use it for mail and all brandon

3 2

Re: COM/NET informational message
by Steven M. Bellovin 03 Jan '03

03 Jan '03

In message <Pine.LNX.4.44.0301031853520.19798-100000(a)www.everquick.net>, "E.B. Dreger" writes: > >EL> Date: Fri, 3 Jan 2003 13:44:53 -0500 >EL> From: Edward Lewis > > >EL> The DNS protocol is not 8-bit safe, much less any >EL> implementations of it. This is because ASCII upper case >EL> characters are down cased in comparisons. I.e., the > >My point is there's no need to force chars <= 0x7f if DNS servers >are properly implemented. If they're not properly implemented, >why not, and whose fault is that? Catering to bad or broken >implementations instead of following standards is not a good way >to ensure interoperability. > >DNS labels are encoded by a one-octet length representation >followed by that number of octets, with no restrictions on the >content of the octets. Show me where an RFC says something to >the extent of "labels and <any type of> RR MUST NOT contain >characters >= 0x7f" that rescinds 1035. > >Yes, comparisons are case-insensitive. So what? strcasecmp() >works on ASCII strings. Now it must work on <new encoding x>. >Why not let <new encoding x> be UTF-8, something programmers >should support already? Maybe MS-style Unicode encoding? Why >add yet another encoding?! > I'm sorry, but this is incorrect in many different dimensions. The subject was discussed exhaustively in the IETF's IDN working group; I refer you to its archive for detailed discussions. Among many other things, your assertion about the simplicity of name comparisons is wrong; see draft-hoffman-stringprep-07.txt for a discussion of that issue. As for 8-bit clean DNS -- well, apart from the many possible ways to encode things, there's the issue of the many applications that aren't 8-bit clean, including (per the RFC 822 spec) SMTP. If "just use 8-bit clean DNS" were sufficient, we'd have been there several years ago. See http://www.ietf.org/html.charters/idn-charter.html for many more pointers. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

2 1

Dutch translation needed
by James-lists 03 Jan '03

03 Jan '03

I am not getting through to speed.planet.nl in English, can anyone give me a decent translation of in Dutch (The Netherlands): "Here are our logs, indicating your host is attempting to access formmail on our web servers. We have been seeing at least 1,000 attempts a day for weeks from this host. Please look into this matter. The logs are in Mountain US time zone and sync'ed to NTP. Thank you for your attention to this matter" James Edwards Routing and Security noc(a)cybermesa.com

3 2

RE: Google Crawler
by Mike Damm 03 Jan '03

03 Jan '03

http://www.google.com/bot.html for issues with the crawler. mailto:googlebot@google.com will get you a human bean to talk to. Normally when there is a problem with their robot, they are pretty responsive. -Mike --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com -----Original Message----- From: Andy Ellifson [mailto:andy@ellifson.com] Sent: Friday, January 03, 2003 8:45 AM To: nanog(a)merit.edu Subject: Google Crawler We are a domain registrar and we host/park over 750,000 domain names. Every now and then the Google Crawler decides to bury the machines that host our 'parked' domain pages. We use robots.txt but that doesn't help under these circumstances. I have tried sending a message to Google using their web site. They don't have a NOC entry on puck.nether.net either. Our only alternative right now is to block the crawler at the router level. Does anbody have a contact at Google or is anyone at Google listening? Thanks! Andy Ellifson

2 1

Google Crawler
by Andy Ellifson 03 Jan '03

03 Jan '03

We are a domain registrar and we host/park over 750,000 domain names. Every now and then the Google Crawler decides to bury the machines that host our 'parked' domain pages. We use robots.txt but that doesn't help under these circumstances. I have tried sending a message to Google using their web site. They don't have a NOC entry on puck.nether.net either. Our only alternative right now is to block the crawler at the router level. Does anbody have a contact at Google or is anyone at Google listening? Thanks! Andy Ellifson

1 0

The Cidr Report
by cidr-report＠potaroo.net 03 Jan '03

03 Jan '03

This report has been generated at Fri Jan 3 21:45:27 2003 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 27-12-02 117120 84759 28-12-02 117172 84857 29-12-02 117391 84760 30-12-02 117247 84955 31-12-02 117450 85024 01-01-03 117552 85059 02-01-03 117648 85132 03-01-03 117672 85168 AS Summary 14290 Number of ASes in routing system 5618 Number of ASes announcing only one prefix 1610 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73047040 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 03Jan03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 117812 85155 32657 27.7% All ASes AS3908 1173 689 484 41.3% SUPERNETASBLK SuperNet, Inc. AS701 1610 1195 415 25.8% ALTERNET-AS UUNET Technologies, Inc. AS18566 414 5 409 98.8% COVAD Covad Communications AS7018 1430 1029 401 28.0% ATT-INTERNET4 AT&T WorldNet Services AS4323 532 188 344 64.7% TW-COMM Time Warner Communications, Inc. AS7843 622 301 321 51.6% ADELPHIA-AS Adelphia Corp. AS1221 1146 829 317 27.7% ASN-TELSTRA Telstra Pty Ltd AS6197 455 150 305 67.0% BATI-ATL BellSouth Network Solutions, Inc AS1239 976 687 289 29.6% SPRINTLINK Sprint AS6347 368 85 283 76.9% DIAMOND SAVVIS Communications Corporation AS4355 407 136 271 66.6% ERMS-EARTHLNK EARTHLINK, INC AS22927 289 22 267 92.4% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS7046 552 291 261 47.3% UUNET-CUSTOMER UUNET Technologies, Inc. AS705 422 188 234 55.5% ASN-ALTERNET UUNET Technologies, Inc. AS4814 246 15 231 93.9% CHINANET-BEIJING-AP China Telecom (Group) AS6198 423 200 223 52.7% BATI-MIA BellSouth Network Solutions, Inc AS1 659 437 222 33.7% GNTY-1 Genuity AS17676 231 26 205 88.7% GIGAINFRA XTAGE CORPORATION AS22291 226 29 197 87.2% CHARTER-LA Charter Communications AS690 513 319 194 37.8% MERIT-AS-27 Merit Network Inc. AS4151 325 134 191 58.8% USDA-1 USDA AS6140 315 125 190 60.3% IMPSAT-USA ImpSat AS209 517 335 182 35.2% ASN-QWEST Qwest AS4134 290 108 182 62.8% ERX-CHINALINK Data Communications Bureau AS852 627 446 181 28.9% ASN852 Telus Advanced Communications AS2048 254 84 170 66.9% LANET-1 State of Louisiana AS2386 387 229 158 40.8% INS-AS AT&T Data Communications Services AS6327 185 34 151 81.6% SHAWFIBER Shaw Fiberlink Limited AS17557 324 179 145 44.8% PKTELECOM-AS-AP Pakistan Telecom AS3215 313 174 139 44.4% AS3215 France Telecom Transpac Total 16231 8669 7562 46.6% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0