- Test - lists.nanog.org

History of unannounced changes to the DNS core
by Sean Donelan 09 Oct '03

09 Oct '03

Try to match the quotes up with the actions. Postel gave no prior notification that the test would take place, a fact that drew criticism. "It's caused a good deal of uncertainty and perceived instability in the system," said Chris Clough, a spokesman for Network Solutions, which operates under a contract with the National Science Foundation. "It's a concern about who can authorize changes over the infrastructure and traffic patterns of the Internet." - Associated Press, February 4 1998 "We're very concerned," Becky Burr, administrator with the Commerce Department, said Tuesday. "This was undertaken without consultation with the United States government." People trying to visit the popular Internic directory which checks the availability of a new Web address are unexpectedly being swept automatically instead to the home page for Network Solutions Inc., which offers to register Internet addresses with the com, net or org suffixes for $119. - Associated Press, March 24 1999 NSI, naturally, has a different point of view. "The registry information is our proprietary information." says NSI spokesman Chris Clough. "We've been providing it free to the community, but under the contract, all of the intellectual property gathered through the InterNIC process is our proprietary information." - ABC News, March 7 1999

2 1

Contacts for CHINANET-BJ?
by Tom (UnitedLayer) 09 Oct '03

09 Oct '03

Anyone got a clueful contact over there? Getting 100Mbps or so of dos from over there and I'd rather not just blackhole the /16 --- Tom Sparks

1 1

i'm missing my copy of "why a wildcard MX won't help sitefinder"
by Paul Vixie 09 Oct '03

09 Oct '03

at the meeting yesterday, verisign said they were considering the benefits of a wildcard MX RR whose target was a nonexistent name, as a way to keep smtp traffic from having to come to sitefinder for rejection. i recall a very good posting on this topic and i think it was on nanog but i can't find it now. can someone privately send it to me if you've got it? -- Paul Vixie

1 0

[nanog@Overkill.EnterZone.Net: Extensions to RFC1998 - WAS: Re: DoS Attacks]
by Haesu 09 Oct '03

09 Oct '03

Forwarding to NANOG on behalf of Mr. Fraizer. Please don't shoot the messenger for any arguable/discussions. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | haesu(a)towardex.com Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN ----- Forwarded message from John Fraizer <nanog(a)Overkill.EnterZone.Net> ----- X-Original-To: haesu(a)mx01.bos.ma.towardex.com Delivered-To: haesu(a)mx01.bos.ma.towardex.com Date: Wed, 8 Oct 2003 21:58:26 -0400 (EDT) From: John Fraizer <nanog(a)Overkill.EnterZone.Net> To: Haesu <haesu(a)towardex.com> Cc: nanog(a)merit.edu, a_spicer(a)bellsouth.net Subject: Extensions to RFC1998 - WAS: Re: DoS Attacks In-Reply-To: <20031009004646.GB88086(a)scylla.towardex.com> X-Spam-Status: No, hits=-2.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Wed, 8 Oct 2003, Haesu wrote: > Hmmmm? What did I miss? When did RFC1998 get updated to include Null > community? Feel free to let me know if they updated RFC on that > lately.. b/c I havent checked it in a while. > > As far as I know, my upstreams are fully RFC1998 compliant and I use them well. > > -hc > Note: please echo this to the list. I don't have post access. Ahem... Sue...Ahem... The RFC itself hasn't been updated to include a Null community but if you think about it, providing a NULL community is fully within the concept of allowing customers to influence routing policy with the use of community strings. For example: ! router bgp 65534 neighbor a.a.a.a remote-as 65530 neighbor a.a.a.a description Customer AS65530 neighbor a.a.a.a prefix-list AS-65530 in neighbor a.a.a.a route-map CUSTOMERS in ! ip prefix-list AS-65530 seq 5 permit x.x.x.x/y le 32 ! ip community-list standard POISON permit 65534:666 ! route-map CUSTOMERS permit 10 match community POISON set local-preference 500 set ip next-hop [ip address of your sink-hole] ! Of course, the rest of the route-map CUSTOMERS is going to need to do some sanity checks on the announcements you accept from the customers OTHER than blackhole requests. In our case, we pass them through a prefix-list match that includes: ip prefix-list CUSTOMERS seq 10 deny 0.0.0.0/0 ge 25 As you can see, we're doing a prefix-list check against the announcements that the customer sends us in the neighbor statement. Each customer gets their own prefix-list that covers the networks that we have LOA to accept from that customer. (Keeps boneheads from blackholing OTHER people!) The first stanza in the CUSTOMERS route-map checks for the POISON community. Any prefix that the customer sends us that includes this community will be routed to our sink-hole. The rest of the stanzas in the CUSTOMERS route-map look for other communities from the customer. One stanza looks to see if the customer is requesting us to pass their announcements of our address space on as de-aggregated announcements. If we don't see that community, they're aggregated. Other stanzas in the route-map are pretty cut and dry RFC1998. Our customers can do the following: Community Action --------------------------------------------- 13944:0 Don't announce to any peer 13944:1 Don't announce to PEERS 13944:2 Don't announce to TRANSIT 13944:3 Don't announce to CUSTOMERS 13944:20 Announce specific from EnterZone aggregate for customers who are running on our IPs. 13944:90 Set preference to 90 13944:100 Set preference to 100 13944:110 Set preference to 110 13944:120 Set preference to 120 13944:666 Poison a Route 13944:NNN0 don't announce to Peer NNN 13944:NNN1 prepend once towards Peer NNN 13944:NNN2 prepend twice towards Peer NNN 13944:NNN3 prepend thrice towards Peer NNN Any time I do any consulting on another network, I recommend that they at MINIMUM implement the Poisoned Route ability. It is not terribly difficult to do as you can see above. -- John Fraizer EnterZone, Inc (13944+$|13944+_14813+$|13944+_17266+$) PGP Key = 6C5903C4 Fingerprint = 2AA6 6614 1B5E EDD2 38AD C417 3E61 F975 6C59 03C4 ----- End forwarded message -----

1 0

More news coverage
by Howard C. Berkowitz 09 Oct '03

09 Oct '03

Associated Press at http://www.boston.com/business/technology/articles/2003/10/08/experts_descr… I am talking with the reporter, Ted Bridis. Associated Press reporters are under about as tough a deadline as TV, so it's a good fast first pass.

6 6

RE: Verisign on Process
by Howard C. Berkowitz 09 Oct '03

09 Oct '03

At 5:23 PM -0700 10/8/03, David Schwartz wrote: > > Is it possibly time to suggest that perhaps ICANN should >> call for formal separation of regiSTRAR functions from >> regiSTRY functions, and stipulate that stewards of record >> for regiSTRY functions not participate in regiSTRAR roles? > > Already done -- read the contact between ICANN and VeriSign. > >> Certainly it's been shown to be very difficult to resist >> the temptation to extend editorial control over what entries >> get placed into the DNS records as a regiSTRY if you also >> happen to be able to increase the profits from your regiSTRAR >> role. > > Sure, but you could also do it to increase the profits from >your registry >role, which seems to have been the intent of SiteFinder. > >> If the functions are stipulated to be kept separate, > > They are. > >> then we have a much better opportunity to engage a system of >> checks and balances, to self-limit potential future abuses >> like this. > > How would that stop a registry from, for example, adding a >wildcard record >that goes to pages sold to the highest bidder? Registry functions are >supposed to be wholly ministerial. VeriSign doesn't get that and ICANN is >going to have to force them to -- probably more than once. > > DS

1 0

Finding clue at comcast.net
by Howard C. Berkowitz 09 Oct '03

09 Oct '03

I'm rapidly beginning to believe this is equivalent to finding the pot of gold at the end of the rainbow. When my broadband alternative is Verizon and it's looking better, this is scary. Sometime today, their SMTP server started bouncing messages with more than 3 addressees. When I called customer support, I was told "we only handle troubleshooting, not mail service." The operator "guessed" they might be doing software updates on the mail service, had no information, and said there was no person to which it could be escalated. She insisted that I call my local cable office to find out when the "server repair" would be completed, because "they schedule all repairs." Is this a bad dream?

1 0

DoS Attacks
by Brian Bruns 09 Oct '03

09 Oct '03

Oh boy, what a fun night this was. After a 4 or so hours downtime, my servers are back up and running. Heres the gorey details. At about 7pm EST, we began having unusual issues with our network, the router, and several machines on the network. For the first part of the attack, we were held down for a good 30-60 minutes. Took us a while to figure out which one of our machines was being targeted. Turns out to be our NAT firewall box. We tried several things to drop the attack, but it still kept coming in strong (mind you, we don't have very much bandwidth, but we can usually ride out DoS attacks pretty well - this was an exception) Then suddenly, out of the blue it dropped. Outside connectivity was restored and things were back to normal. 20 minutes later, the relentless attack began again. This time, we were ready and waiting with tcpdump and several other handcrafted tools we use for this type of thing. The attack was coming from a single source machine, unspoofed (ballsy if you ask me), 128.186.11.215. Packets were UDP, random from 2100-2299 source and 2400-2699 dest. So, now for the fun part. Being offsite, I wasn't the one to place the calls, but my admin on site started with FSU's abuse desk. No help whatsoever. Claimed that because the abuse desk was gone, they had no authority to deal with the problem. Frustrated, annoyed, and pissed off, he tried again, and got hung up on twice. Nice people eh? Our next call was a bit later (at this point, we were very unhappy and ready to start raising hell with anyone we could find) - this time, to their upstream Qwest. After dealing with the operator, they finally sent him to one of the NOCs. Unfortunately, they sent him to the wrong NOC and not the Qwest MD NOC. Luckily, we got someone with a clue - a nice guy by the name of Richard Stein who tried to help us, but found that the other NOC was unresponsive and couldn't do anything himself to solve the problem. After hanging up with Qwest, we got a call back from FSU. After a good 20 minutes or so of talking with the net admin from FSU, things were finally set in motion. After another good 10 minutes or so, connectivity was restored and everything was back to normal. According to my guy, they yanked the whole subnet at FSU. Problem solved. So here I am, asking if anyone here has any advice on dealing with these issues in the future? Its painfully apparent noone takes these situations seriously enough. What should we do when we are put in a position like this? Just sit back and hope it goes away itself? Also, any ideas on how to deal with these attacks on lower bandwidth connections? Right now, 2mbit.com / sosdg.org is sitting on a 1.5/256 business DSL line. I really can't afford to be buying T1s or T3s just to hold up to attacks like this. As always, thanks. -------------------------- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511

10 11

Re: Verisign on Process
by Howard C. Berkowitz 08 Oct '03

08 Oct '03

At 2:51 PM -0400 10/8/03, Dean Anderson wrote: >On Wed, 8 Oct 2003, Howard C. Berkowitz wrote: > >> >VeriSign's vice president for its registry service. Citing concerns >> >of proprietary information and competitive advantage, he added that >> >he didn't think he could guarantee any advance notice of similar >> >changes in the future. >> >> >> Gomes' position truly bothers me if a registry, given that it meets >> the formal definition of a technical monopoly, is planning around >> competitive advantage. > >This is incorrect. Verisign is not a monopoly. There are many registrars >of .net and .com domain names which compete with Verisign. > > --Dean It is not a monopoly in its regiSTRAR function. It is a monopoly as regiSTRY of .net and .com. It couldn't have inserted the wildcards if it wasn't. Having control of the TLD servers makes you a monopoly for that TLD.

2 1

Old Lorain Rectifier Manual availability?
by Marius Strom 08 Oct '03

08 Oct '03

Does anyone know where to find old Lorain Rectifier manuals (Specifically model #A50F50)? Google (groups and www) turns up nothing. (A PDF would be nice, but I don't have my fingers crossed) -- /-------------------------------------------------> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-------------| Alan Frame |---------------------->

2 1