- NANOG - lists.nanog.org

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

07 Oct '03

>I think this list may be a very good choice of where to construct >such a response. Are you being paid by Verisign? A "constructed" response is the worst thing we could do. Everyone should write their own responses in their own words based on their own experiences or their own skills and knowledge. That's the only way to demonstrate that Verisign was wrong, wrong, wrong. A "constructed" response is pure politics and only demonstrates that a certain opinion is shared by a bunch of people with no basis in fact. We don't need to trumpet our opinions; we need to document and publish the facts of the matter. And this list is definitely not the place to discuss writing a letter of protest. If political activity is your bag, then try http://www.meetup.com --Michael Dillon

6 8

ftp.cisco.com broken ?
by Ezequiel Carson 07 Oct '03

07 Oct '03

hi, can you resolve ftp.cisco.com? [root@localhost /]# ping ftp.cisco.com ping: unknown host ftp.cisco.com [root@localhost /]# something is wrong here.... ezequiel.

9 9

RE: CCO/cisco.com issues.
by Sean McPherson 07 Oct '03

07 Oct '03

<SNIPPAGE> >We're continuing the work the issue, and would be grateful if operators >would check for 40-byte spoofed TCP headed towards 198.133.219.25/32 and >trace/block it as warranted. Your patience and understanding are greatly >appreciated. > >Thanks! > >------------------------------------------------------------- >Roland Dobbins <rdobbins(a)cisco.com> // 408.527.6376 voice Roland, Are these spoofed addresses from any range specifically in relation to the 'real' source address (ie, are they spoofing other IPs in the same subnet or CIDR range, a specific known range, or just random routable addresses)? I've run some netflow filters and have seen some traffic (very small amounts) that could match the very simple 40-byte payloads to that /32 traversing out of a few customers' gear, but I was hoping to not have to start digging into traffic to see if it originated in the 'right' places if you already had any ideas. That said, I don't want to ignore the fact it's not much traffic, since with enough zombied machines, a lot of 'trickles' forms a flood! Thanks, Sean McPherson nanog <@ is the at sign> seanmcpherson dotcom

1 0

Re: Verisign's public opinion play
by Brandon Butterworth 07 Oct '03

07 Oct '03

> we're only upset because Verisign makes money off of this. I'm sure that is a factor too. Verisign have a contract to operate a shared registry, as a monopoly is unreasonable, but hijack it to make a different service that nobody else gets to bid for running. If such a service were a feasible use of this public resource there'd be an open process to bid for running it and some of the rewards would go to public services in return for that lease brandon

1 0

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