- Test - lists.nanog.org

South America NOG ?
by Pascal Gloor 07 Oct '03

07 Oct '03

Is anyone aware of a South America NOG? or do they mainly use nanog? Pascal

4 3

RE: CCO/cisco.com issues.
by Hank Nussbacher 07 Oct '03

07 Oct '03

On Mon, 6 Oct 2003, Matt wrote: The nsp-security list coordinates the interaction between ISPs and NSPs in near real-time. The list has helped mitigate attacks and will continue to do so. Those interested in being members and that fulfill the requirements should review: https://puck.nether.net/mailman/listinfo/nsp-security Regards Hank on behalf of the nsp-security moderators > > As the bandwidth ramps up on the access side, this problem is only > going > > to become more and more prevalent (as if it's not already enough of a > > problem).While I don't think filtering is the silver bullet, it can > > certainly help at times.Ithink some of the larger watch sites (eg > > SANS, etc.) out there have the right idea - even though reactive in > > nature, almost real-time dissemination of attack vectors and trending > of > > methods goes a long way towards slowing down some of these attacks. > > Unfortunately, these single target attacks, such as attacks on Cisco, > > Ebay, Yahoo, etc. cannot be entirely thwarted if the attacker(s) > is/are > > determined enough.We could go down the client side discussion (you > > know, the one about certain software vendors, etc.) but that topic has > > already been covered in great length. Hank Nussbacher

1 0

Re: Reverse DNS problem - ARIN changes last week
by Trent Arsenault 07 Oct '03

07 Oct '03

Hi Brad, Paul, I received the below note from ARIN yesterday evening regarding their NS changes on Thursday. This should explain what we're seeing. It appears some older versions of BIND and some os-bundled resolver libraries may be affected. Trent -------- Original Message -------- Subject: Re: [ARIN-20031003.584] response to reverse PTR queries Date: Mon, 06 Oct 2003 17:14:29 -0400 (EDT) From: Cathy Murphy <cathym(a)arin.net> To: Trent Arsenault We've isolated the problem you've been experiencing to how the earlier BIND resolvers work. It appears that they do not properly follow referrals. The upshot is to get newer versions of your resolver software. Here is what is happening: dig -x 129.159.39.15 * Assuming no cache, a query goes to the root servers, which return no answer but give the name servers for 129.in-addr.arpa (referral) to [chia,dill,...indigo].arin.net * A query then goes to the .net name servers [a,b...m].gtld-servers.net for [chia,dill...indigo].arin.net This is where the problem arises. There is no A record (glue) for [chia...indigo].arin.net on the .net nameservers. Previously, our zones were also served by arrowroot.arin.net and buchu.arin.net, which had (inappropriate) glue records in .net. (You can still see them by doing "dig @a.gtld-servers.net arrowroot.arin.net".) We are phasing out these servers. On Thursday, we removed arrowroot and buchu from the delegations for our in-addr.arpa zones. Although the change was done correctly it uncovered a hidden misconfiguration which enabled older BIND resolvers to work. The return of arrowroot's A record in this way violated DNS rules on authority and credibility of data, facets better enforced in newer versions of BIND. Apparently older versions of BIND resolvers rely on this A record to descend the tree towards the answer and are unable to handle the referral that should have been returned. So now, instead of responding with an A resource record, the .net name servers are correctly responding with a referral to the arin.net name servers: [a3,b3...].nstld.com. What the resolver should do is follow this referral to get the A record of the [chia,dill,etc].arin.net name servers. Instead, it appears to time out. We haven't figured out what versions of BIND do and do not work with our changes. We also haven't dug deeply enough to know why the older resolvers fail to pursue the referral messages. I apologize if this seems like it's another case of "we're making a change and you have to live with it." All of the options we've identified for avoiding this were kludges and hacks. We couldn't come up with a way to help older resolvers without otherwise risking some other misconfiguration. Regards, Cathy Murphy ARIN Trent Arsenault trent(a)trent.us At 04:58 PM 10/6/2003, Brad Knowles wrote: >At 4:09 PM -0700 2003/10/06, Trent Arsenault wrote: > >> I've been in touch with ARIN on the same issue noticed at a different site. >> >> According to ARIN, some older BIND resolvers aren't handling the >> referrals that they get back from the gtld-servers for some of ARIN's >> name servers. The problem started Thursday when ARIN changed the list >> of NS's for the ARIN in-addr.arpa zones. >> >> ARIN is still investigating and I'm waiting to hear back. > > From what I can tell, the responses are being handed back > authoritatively. From my reading of RFC 2821, for a delegation this > shouldn't happen. The root nameservers don't do this for .com, and they > should do the same for in-addr.arpa (they delegate .arpa to themselves, > so that would be okay). > > Note that k.root-servers.net does not return any glue. I'm > guessing they might now be running on nsd instead of BIND -- yup, looks > like they're running nsd 1.2.2, at least according to the following: > >% dig @k.root-servers.net. chaos txt version.server > >; <<>> DiG 9.2.2 <<>> @k.root-servers.net. chaos txt version.server >;; global options: printcmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64350 >;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > >;; QUESTION SECTION: >;version.server. CH TXT > >;; ANSWER SECTION: >version.server. 0 CH TXT "NSD 1.2.2" > >;; Query time: 35 msec >;; SERVER: 193.0.14.129#53(k.root-servers.net.) >;; WHEN: Tue Oct 7 01:32:54 2003 >;; MSG SIZE rcvd: 54 > > > This looks to me like it is related to the same problem that > we're having at the moment with UltraDNS and how they hand out answers > marked as authoritative for zones where there is also host registration > for that name (see hark.org and usenix.org) > > I've done some zone transfers from c.root-servers.net, and from > what I can tell, the zones appear to be okay in and of themselves. I'm > wondering if this problem isn't somehow related to the version of BIND > that may be running on most of these systems -- perhaps a bug with the > new "delegation-only" and "root-delegation-only" code? > > I don't know. This looks pretty strange to me. Paul -- do you > have any ideas? > >-- >Brad Knowles, <brad.knowles(a)skynet.be> > >"They that can give up essential liberty to obtain a little temporary >safety deserve neither liberty nor safety." > -Benjamin Franklin, Historical Review of Pennsylvania. > >GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ >!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) >tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

1 0

LINX Letter to ICANN regarding Verisign
by Stephen J. Wilcox 07 Oct '03

07 Oct '03

FYI. Sent yesterday : Submission by the London Internet Exchange to the ICANN Security and Stability Advisory Committee Regarding Verisign's Deployment of Wildcard DNS Records The London Internet Exchange (LINX) is Europe's largest Internet exchange point. Owned mutually by nearly 140 member Internet Service Providers and Content Services Providers, LINX members carry the overwhelming majority of Internet traffic within the United Kingdom. Most of the Internet traffic exchanged between ISPs within the UK by public peering is passed across the LINX. LINX is concerned about Verisign's insertion of wildcard records into the .com and .net zones, and about the use of these wildcards to direct traffic that would otherwise have resulted in a "no domain" response to Verisign's own hosts. LINX views the DNS tree as extremely important to the smooth operation of Internet services: anything that damaged confidence in the integrity and unified nature of the DNS tree would be very unfortunate. LINX is concerned that Verisign's actions may undermine confidence in the DNS. In particular, LINX fears that individual networks may implement workarounds to avoid the effect that Verisign is seeking to create, and that this could result in reduced confidence in the DNS system continuing as a single coherent tree. Once the prospect of DNS resolvers choosing not to honour the DNS tree appears we have to consider the possibility of further fragmentation of the DNS through individual networks suborning the Domain Name System in order to pursue other commercial or policy interests. Another avenue of concern lies in the area of respecting end user privacy. While we take note of and welcome Verisign's assurances that they are not logging traffic to its mail servers, end users around the world are forced to rely on the promise offered by a commercial entity operating in a single national jurisdiction. The United States does not share the same data protection laws offered in some other countries, and most end users would have no practical or legal recourse if Versign were to fail to adhere to its policy, either for its own purposes or for those of the relevent legal authorities. There is therefore a powerful argument that end users should not have to take the promise not to retain private data on trust. In contrast to these concerns, there is Verisign's own interest in preserving its freedom of action and ability to pursue its commercial success. We are not persuaded that in this case Verisign's private interests outweigh the considerable public concerns that have been expressed by LINX and others on behalf of the wider Internet community. The longer term implications of such DNS fragmentation are directly relevent to the stability of Internet service, and thus to the work of ICANN's Security and Stability Advisory Committee. We believe that these implications would be quite regretable, and that it is appropriate to take steps to ensure that this does not occur. LINX endorses the statement of the Internet Architecture Board and recommends that Verisign is asked to remove the wildcard records it has inserted in the .com and .net zones.

1 0

Re: Some very strange network behaviors
by Gregory Hicks 07 Oct '03

07 Oct '03

> Date: Thu, 11 Sep 2003 13:35:37 -0700 > From: Crist Clark <crist.clark(a)globalstar.com> > > Mike Lewinski wrote: > > [...snip...] > OS's IP stack is misbehaving badly, Zone Alarm should not see the traffic > on the LAN that does not have his MAC address on it. > > How would a switch/router be deciding that these other IP addresses > should go to his PC's NIC (MAC address)? Unless the switch got confused when the MAC address changed as it did...? Then the switch would go into "broadcast" or "flood" mode where every packet is delivered to evey port because the switch doesn't know where to send it. Regards, Gregory Hicks > -- > Crist J. Clark crist.clark(a)globalstar.com > Globalstar Communications (408) 933-4387 --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks(a)cadence.com Never attribute to malice that which is adequately explained by ignorance or stupidity. Asking the wrong questions is the leading cause of wrong answers "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

4 3

AS5384 routing table is not propagating
by Henry Linneweh 07 Oct '03

07 Oct '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 AS5384 routing table is not propagating very good here and I see at least 50 instances of that I was checking it for a peer trying to get a better route result - -Henry R Linneweh -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com iQA/AwUBP4KhwsiimYc7OT3DEQLIEgCfTONrpI/K1AlnimGvDlnX79kDS44An2ZB K0Wyt2xT8YNeHNEzxXgKjc7T =tRS8 -----END PGP SIGNATURE-----

1 0

Re: Verisign's public opinion play
by Michael.Dillon＠radianz.com 07 Oct '03

07 Oct '03

>I know personally I would love to put out a paper, but I have no idea where >to begin. If you don't have the time to write a paper then sit down and write a case study about your own experiences that could be published in a trade magazine or your local newspaper. Submit it to your favorite publications, then if none of them print it, resubmit it as a letter to the editor. In general, a case study is easier to write up that a paper and it can be used later as raw material by people who are doing research for a more detailed paper. --Michael Dillon

1 0

Re: sitefinder technical discussions
by Michael.Dillon＠radianz.com 07 Oct '03

07 Oct '03

>Having been involved in the community internet for as long as I have, I >want to wretch. I'd think Mark would be one of those, as well. Whether he does or doesn't want to retch, Mark does need a job and he happens to have one currently at Verisign as do a number of other skilled technical people. Things would be different if people on this list would actively recruit these Verisign technical people and hire them away, but does anyone really care enough to put their money where there mouth is? It wouldn't be the first time that a company was gutted by hiring away its brightest and best. --Michael Dillon

1 0

Re: sitefinder technical discussions
by Michael.Dillon＠radianz.com 07 Oct '03

07 Oct '03

>In the interest in gaining more community review and comment, a discussion >list has been setup to discuss factually-based technical issues >and solutions surrounding the operational impact of wildcards in >top-level domains on Internet applications. If anyone wants to follow this via the web archives, it is at http://lists.elistx.com/archives/sitefinder-tech-discuss/ --Michael Dillon

1 0

Re: Verisign's public opinion play
by George William Herbert 07 Oct '03

07 Oct '03

One soundbite which just came to me: "What if the company which has the Yosemete restaraunt consession put up a 300 foot rig and drilled for oil behind the kitchen?" -george william herbert gherbert(a)retro.com

1 0