Re: Verisign Responds
ISC has made root-delegation-only the default behaviour in the new bind, actually, though, we havn't, and wouldn't (ever). the feature is present but must be explicitly enabled by a knowledgeable operator to have effect. how about drafting up an RFC making it an absolute default requirement for all DNS? this is what the icann secsac recommendation... http://www.icann.org/correspondence/secsac-to-board-22sep03.htm ...says that ietf/iab should look into: We call on the IAB, the IETF, and the operational community to examine the specifications for the domain name system and consider whether additional specifications could improve the stability of the overall system. Most urgently, we ask for definitive recommendations regarding the use and operation of wildcard DNS names in TLDs and the root domain, so that actions and expectations can become universal. With respect to the broader architectural issues, we call on the technical community to clarify the role of error responses and on the separation of architectural layers, particularly and their interaction with security and stability. and it does seem rather urgent that if a wildcard in the root domain or in a top level domain is dangerous and bad, that the ietf say so out loud so that icann has a respected external reference to include in their contracts. -- Paul Vixie
bind 9.2.3rc3 successful
Thought I'd mention that I helped setup BIND 9.2.3rc3 on a yellowdog linux powercomputing machine tonight. It worked. And the mail queues began clearing out. Just for an oddball success report. Are others having similar luck? What needs to be done to make this a standard feature set? Is somebody working on an RFC? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: bind 9.2.3rc3 successful
Thought I'd mention that I helped setup BIND 9.2.3rc3 on a yellowdog linux powercomputing machine tonight. It worked. And the mail queues began clearing out. Just for an oddball success report. oh hell. thanks for the kind words, but we just released rc4. Are others having similar luck? What needs to be done to make this a standard feature set? Is somebody working on an RFC? i do not expect the ietf to say that root and tld zones should all be delegation-only. but good luck trying. -- Paul Vixie
Re: bind 9.2.3rc3 successful
I am using bind 9.2.2-p2 on our resolver name servers so far.. And I have no problems to report at this time, it's been running smooth so far; mail queues started clearing out nice and clean. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 174 Fax: (978)263-0033 | POC: HAESU-ARIN On Tue, Sep 23, 2003 at 02:35:48AM -0400, William Allen Simpson wrote: Thought I'd mention that I helped setup BIND 9.2.3rc3 on a yellowdog linux powercomputing machine tonight. It worked. And the mail queues began clearing out. Just for an oddball success report. Are others having similar luck? What needs to be done to make this a standard feature set? Is somebody working on an RFC? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: bind 9.2.3rc3 successful
On Tue, Sep 23, 2003 at 02:35:48AM -0400, William Allen Simpson wrote: Thought I'd mention that I helped setup BIND 9.2.3rc3 on a yellowdog linux powercomputing machine tonight. It worked. And the mail queues began clearing out. Just for an oddball success report. We've been using these patches on production servers since they first came out (both the 9.2.2 patches and the 9.2.3rcx versions); no problems reported so far (knock wood). -- Since when is skepticism un-American? Dissent's not treason but they talk like it's the same... (Sleater-Kinney - Combat Rock)
Re: Verisign Responds
On 23.09 06:07, Paul Vixie wrote: We call on the IAB, the IETF, and the operational community to examine the specifications for the domain name system and consider whether additional specifications could improve the stability of the overall system. Most urgently, we ask for definitive recommendations regarding the use and operation of wildcard DNS names in TLDs and the root domain, so that actions and expectations can become universal. With respect to the broader architectural issues, we call on the technical community to clarify the role of error responses and on the separation of architectural layers, particularly and their interaction with security and stability. and it does seem rather urgent that if a wildcard in the root domain or in a top level domain is dangerous and bad, that the ietf say so out loud so that icann has a respected external reference to include in their contracts. The IAB has done an excellent job with http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html. I quote: ... Proposed guideline: If you want to use wildcards in your zone and understand the risks, go ahead, but only do so with the informed consent of the entities that are delegated within your zone. Generally, we do not recommend the use of wildcards for record types that affect more than one application protocol. At the present time, the only record types that do not affect more than one application protocol are MX records. For zones that do delegations, we do not recommend even wildcard MX records. If they are used, the owners of zones delegated from that zone must be made aware of that policy and must be given assistance to ensure appropriate behavior for MX names within the delegated zone. In other words, the parent zone operator must not reroute mail destined for the child zone without the child zone's permission. We hesitate to recommend a flat prohibition against wildcards in registry-class zones, but strongly suggest that the burden of proof in such cases should be on the registry to demonstrate that their intended use of wildcards will not pose a threat to stable operation of the DNS or predictable behavior for applications and users. We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity. What else does the IETF need to do here? This should be enough of an expert opinion for ICANN and others like the US DoC in the sort term. Verisign have realised that and are talking about an -so far vapour- expert panel to counter that. I wonder about its composition . Daniel
Re: bind 9.2.3rc3 successful
On 23 Sep 2003, Paul Vixie wrote: Thought I'd mention that I helped setup BIND 9.2.3rc3 on a yellowdog linux powercomputing machine tonight. It worked. And the mail queues began clearing out. Just for an oddball success report. oh hell. thanks for the kind words, but we just released rc4. Now all I need is a patched version of the 9.3 snapshot tree, so I don't need to kill my dnssec stuff :P (And it's time for a non-snapshot bind version with full dnssec capabilities anyway :) Paul
Re: Verisign Responds
On Mon, 22 Sep 2003, Dave Stewart wrote: Courts are likely to support the position that Verisign has control of .net and .com and can do pretty much anything they want with it. ISC has made root-delegation-only the default behaviour in the new bind, how about drafting up an RFC making it an absolute default requirement for all DNS? -Dan That would be making a fundamental change to the DNS to make wildcards illegal anywhere. Is that what you want? --bill
Re: Cheap temperature sensors
At 06:29 AM 9/23/2003, you wrote: I hate to point this out but this sounds spammy as hell, and while I've been on this list a very short time, very very big alarm bells went off when I read it. I have no financial interest in the company and I was just letting the list know about a cheap solution that works really, really well for a tremendous price. That's an elusive thing to find and I managed to locate something that many of us need. If you aren't a spammer, compare your review with what spammers write, noting key phrases I bought one and WOW! rings IMMEDIATE spam bells, further you went from buying one (note above) to I purchased 10 individual temperature sensors and two temp/humidity sensors, for a total of 12. All comparable solutions were $2000-3000 for the same number of sensors. I was half expecting to loose $445 to a scam company in Slovakia. I was very pleasantly surprised and I wanted to share my positive experience. I was excited because of the ease of setup and the dirt cheap price. If you don't need them. Ignore the post. If you do, or if someone searching the archives does, they will find my post useful. It is a lot more on topic than a lot of the nanog noise. So I figure I'm going to call Tellurian tomorrow, and confirm you exist, hoping you'll forgive me for my lack of faith. Look at the archives. I've been a nanog poster for years and an ISP for even longer. Tellurian has been providing Internet access since 1995. I am _clearly_ not a spammer! Relatedly, don't capitalize words for emphasis, It's a stylistic choice. I don't believe in html posting. In plain text, I have caps and _underlines_. That's it. I note a previous post that stated that people will be able to search these lists when you're looking for employment and one must chose one's words carefully. I haven't done anything wrong and I never wrote anything I will regret in the future. I really don't get it. Anyway, I will give you a ring tomorrow, hoping that you do exist, and that you did send this, if not we can figure out exactly what's going on, and get it back to the list. I am real. Look at our web site and look at the archives. I bought a cheap and elegant solution to a problem we all have and I wanted to share that positive experience with the list to benefit others. I was hesitant to buy it because it looked too good to be true and they are located in Slovakia (no offense to others from SK), but it works and I'm very impressed. Again, I have absolutely NO connection to them other than as a satisfied customer. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Good will, like a good name, is got by many actions, and lost by one. - Francis Jeffrey
RE: [nanog]: Re: Cheap temperature sensors
All comparable solutions were $2000-3000 for the same number of sensors. I was half expecting to loose $445 to a scam company in Slovakia. I was very pleasantly surprised and I wanted to share my positive experience. I was no-scam actually being from .sk, i just can tell that what you might consider a crap price in .us gets you a reasonably good product here there are several companies here developing measurement and power systems, both telco- and industry- grade and they have great renome abroad if you need flexibility in [reasonably priced] custom-built products, i believe the best bet is one of these companies /no-scam sorry if this disturbed you -- deejay a.k.a. -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.
Re: Cheap temperature sensors
At 06:29 AM 9/23/2003, you wrote: I hate to point this out but this sounds spammy as hell, and while I've been on this list a very short time, very very big alarm bells went off when I read it. Well, if you had been on the list a little longer you would have realized that this is something that comes up on a regular basis and that someone has finally found an affordable solution helps a lot of people out. In fact, your reply was borderline creepy...maybe you need a different hobby then stalking spammers. andy -- PGP Key Available at http://www.tigerteam.net/andy/pgp
Re: bind patches++ (Re: Wildcards)
Hello Paul , All , Is there a url listing the TLD's that officially use wild cards in their deployment ? TIa , JimL On Sat, 20 Sep 2003, Paul Vixie wrote: this feature is only in the latest release candidate is 9.2.3rc3. our patches to 9.2.2 and 9.1 only support delegation-only zones. to get the root-delegation-only option you need 9.2.3rc3. see www.isc.org/products/BIND/delegation-only.html for details. re: Date: Sat, 20 Sep 2003 14:22:57 -0400 (EDT) From: Mr. James W. Laferriere [EMAIL PROTECTED] To: Paul Vixie [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: bind patches++ (Re: Wildcards) Hello Paul , Am I correct in the understanding that the below tells me that 9.2.2p2 does NOT contain the ablility to do root-delegation-only ? Tia , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkEngineer | P.O. Box 854 | Give me Linux | | [EMAIL PROTECTED] | Coudersport PA 16915 | only on AXP | +--+
Re: ICANN asks VeriSign to pull redirect service
John Dvorak wrote: and the response from Russell Lewis: http://www.icann.org/correspondence/lewis-to-twomey-21sep03.htm explenative deleted! The Internet works perfectly fine for years. They make a change which is confirmed to disrupt service. Instead of restoring the stable state while conducting a review, they feel that they must keep the service as is? This is the problem with a for-profit company. They are keeping it to make money. The truth is that no one would complain about reverting back to the stable condition which everyone has lived with for years. They are complaining now. In addition, the IAB has already published a report that pointed out the various problems. Much discussion has existed on the topic across all the major networking/spam/security mailing lists. It is obvious that they have broken a lot of things. To not revert is to push their own needs; ie. profit. This quote is also interesting: This was done after many months of testing and analysis and in compliance with all applicable technical standards The system is technically within standards. The purpose of the IAB is not only to watch standards, but to also understand common use of the network. Many standards have been changed to reflect common use. A good section of RFC's are about common use. As networks implement standards, there are always incompatibilities and extra's that are added in. As deployment reaches general use, it is one of the duties of the IAB to recognize that such utilization is in place and what the overall effect on the Internet is. In this case, IAB did state that the wildcard use did break commonly used mechanisms deployed on the Internet, even if it was technically within the standard. This is one reason that it was recommended that the users of the tld be allowed to decide on if a wildcard is appropriate. For .museum, it is appropriate. It's even in their ICANN agreements. For com and net, no such precedent was ever set and complaints from the users of said tld are being ignored. Common use was broken. -Jack
Re: Verisign Responds
... We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity. What else does the IETF need to do here? issue an rfc. iab is not a representative body, and their opinions are not refereed.
Re: bind 9.2.3rc3 successful
Paul Vixie wrote: i do not expect the ietf to say that root and tld zones should all be delegation-only. but good luck trying. It hasn't been that large an issue in the past, and as pointed out by some, the countermeasures are just as harmful. I hope that delegation-only is only a temporary measure in bind. I'm sure some people will keep it running and probably put it on tld's where it'll break valid records. -Jack
Re: Verisign Responds
On 23.09 14:34, Paul Vixie wrote: What else does the IETF need to do here? issue an rfc. iab is not a representative body, and their opinions are not refereed. brilliant_draft = rfc-format(relevant(good(iab-statement)) + night_sleep(own-ideas)); suggest(dnsop-wg, brilliant_draft); wait(unspec); ... Daniel
Re: Windows updates and dial up users
On Mon, Sep 22, 2003 at 10:02:57AM -0700, Owen DeLong wrote: Ok then different idea, assuming that we're all agreed its MS's responsibility to ensure users are patched promptly and without extra cost to the end user. The problem is that while we agree, Micr0$0ft does not. They feel they should have no responsibility whatsoever to the end user beyond cheerfully refunding their money if they decide to stop using Windows. Microsoft does not issue refunds if you stop using Windows, whether or not you were satisfied with the XPerience. My interactions with Microsoft have never been cheerful, which is a state mostly reserved for New Product Launch(tm) parties and advertisements. Nor can one readily obtain a refund from an OEM, even if you never use Windows and reject the EULA (http://windowsrefund.net/index2.php). -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
RE: Verisign Responds
-BEGIN PGP SIGNED MESSAGE- Paul Vixie wrote: We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity. What else does the IETF need to do here? issue an rfc. iab is not a representative body, and their opinions are not refereed. I wonder btw why Verisign didn't catch the typo's in their own domains if they think it is that important: 8- ; DiG 9.2.3rc2 .verisign.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 31401 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;.verisign.com. IN A ;; AUTHORITY SECTION: verisign.com. 3600IN SOA localhost.verisign.net. vshostmaster.verisign.com. 2003091501 10800 3600 604800 3600 ;; Query time: 165 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Sep 23 16:51:56 2003 ;; MSG SIZE rcvd: 106 - ---8 no mistyping there :) BTW, that SOA record doesn't exist... 8- ; DiG 9.2.3rc2 localhost.verisign.net. ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 52583 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;localhost.verisign.net.IN A ;; AUTHORITY SECTION: verisign.net. 3570IN SOA bay-w1-inf5.verisign.net. vshostmaster.verisign.com. 2003091501 10800 3600 604800 3600 ;; Query time: 32 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Sep 23 16:55:48 2003 ;; MSG SIZE rcvd: 113 - ---8 Hmmm, suddenly another SOA on the same zone, this SOA does exist though. Odd DNS software they are running over there :) And apparently they can return NXDOMAINS after all. Greets, Jeroen -BEGIN PGP SIGNATURE- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / [EMAIL PROTECTED] / http://unfix.org/~jeroen/ iQA/AwUBP3BgwSmqKFIzPnwjEQK18wCfc95MR1wwV6vxDYtjtRLiuUuOLQkAoLzL +ksSp4pgzPqouqxTgDIn1VTd =DNLO -END PGP SIGNATURE-
Re: Verisign Responds
On 23.09 14:34, Paul Vixie wrote: What else does the IETF need to do here? issue an rfc. iab is not a representative body, and their opinions are not refereed. brilliant_draft = rfc-format(relevant(good(iab-statement)) + night_sleep(own-ideas)); suggest(dnsop-wg, brilliant_draft); wait(unspec); ... Daniel you missed a step... approve(iesg, wildcard-clarify);
FW: ISS Security Brief: ProFTPD ASCII File Remote Compromise Vulnerability
-Original Message- From: ISS XForce Sent: Tuesday, September 23, 2003 10:54 AM To: [EMAIL PROTECTED] Subject: ISS Security Brief: ProFTPD ASCII File Remote Compromise Vulnerability *** PGP SIGNATURE VERIFICATION *** *** Status: Good Signature *** Signer: X-Force [EMAIL PROTECTED] (0x7DF5E1BD) *** Signed: 9/23/2003 10:52:05 AM *** Verified: 9/23/2003 11:51:58 AM *** BEGIN PGP VERIFIED MESSAGE *** Internet Security Systems Security Brief September 23, 2003 ProFTPD ASCII File Remote Compromise Vulnerability Synopsis: ISS X-Force has discovered a flaw in the ProFTPD Unix FTP server. ProFTPD is a highly configurable FTP (File Transfer Protocol) server for Unix that allows for per-directory access restrictions, easy configuration of virtual FTP servers, and support for multiple authentication mechanisms. A flaw exists in the ProFTPD component that handles incoming ASCII file transfers. Impact: An attacker capable of uploading files to the vulnerable system can trigger a buffer overflow and execute arbitrary code to gain complete control of the system. Attackers may use this vulnerability to destroy, steal, or manipulate data on vulnerable FTP sites. Affected Versions: ProFTPD 1.2.7 ProFTPD 1.2.8 ProFTPD 1.2.8rc1 ProFTPD 1.2.8rc2 ProFTPD 1.2.9rc1 ProFTPD 1.2.9rc2 Note: Versions previous to version 1.2.7 may also be vulnerable. For the complete ISS X-Force Security Advisory, please visit: http://xforce.iss.net/xforce/alerts/id/154 __ About Internet Security Systems (ISS) Founded in 1994, Internet Security Systems (ISS) (Nasdaq: ISSX) is a pioneer and world leader in software and services that protect critical online resources from an ever-changing spectrum of threats and misuse. Internet Security Systems is headquartered in Atlanta, GA, with additional operations throughout the Americas, Asia, Australia, Europe and the Middle East. Copyright (c) 2003 Internet Security Systems, Inc. All rights reserved worldwide. Permission is hereby granted for the electronic redistribution of this document. It is not to be edited or altered in any way without the express written consent of the Internet Security Systems X-Force. If you wish to reprint the whole or any part of this document in any other medium excluding electronic media, please email [EMAIL PROTECTED] for permission. Disclaimer: The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. In no event shall the author/distributor (Internet Security Systems X-Force) be held liable for any damages whatsoever arising out of or in connection with the use or spread of this information. X-Force PGP Key available on MIT's PGP key server and PGP.com's key server, as well as at http://www.iss.net/security_center/sensitive.php Please send suggestions, updates, and comments to: X-Force [EMAIL PROTECTED] of Internet Security Systems, Inc. *** END PGP VERIFIED MESSAGE *** -+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+ This message was posted through the FIRST mailing list server. Contact your team's FIRST representative to (un)subscribe, DO NOT REDISTRIBUTE BEYOND MEMBERS OF FIRST TEAMS UNLESS THE AUTHOR OF THIS MESSAGE GRANTS EXPRESS PERMISSION TO REDISTRIBUTE -+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+
Re: Providers removing blocks on port 135?
At 01:55 PM 21/09/2003, Justin Shore wrote: On Sun, 21 Sep 2003, Mike Tancsa wrote: Yes, this is all too familiar. Luckily it was not so acute for us. The porn company in question was using legit credit cards and we knew where they were located. We too got to the point where I had to contemplate blocking dialups with no ANI as I had already blocked all access from their phone numbers. However, once they started doing that I called up their office yelling and screaming law suits and I guess they figured there were other ISPs that didnt care as much and moved on to them. I don't know if you did this but if it were me I'd have contacted two other places. The first would have been the credit card companies with the stolen credit cards. The credit cards in our case were legit. They were different numbers, but they were not stolen. They are usuaully fairly responsive when it comes to them loosing money. Secondly after I contacted the local police, state BI, and perhaps the FBI (assuming no luck could be had with any of them) I am in Canada, but I know that it has been stated that the FBI will not investigate computer fraud if damage is under $100,000. I would have given the story to the local media. There's nothing like a little bad PR to give law enforcement a little kick in the butt. I doubt a porn company with international clientele would give a toss about what the local media say. If your newspapers where you're at are anything like our's, they love to print a good scandal involving the local government. Local government has nothing to do with it. It was just some dime a dozen porn company. ---Mike
Re: Providers removing blocks on port 135?
Mike Tancsa wrote: Local government has nothing to do with it. It was just some dime a dozen porn company. Back to the everyone's doing it, so let's not bother syndrome. -Jack
Re: bind 9.2.3rc3 successful
Dan Riley wrote: It breaks a few things we care about--for example, www.ithaca.ny.us is a naked CNAME in the the us root: There's no reason to force .us as delegate only. Force com and net to delegate only and you'll have the Internet as it was before this debate started. -Jack
Re: bind 9.2.3rc3 successful
Now all I need is a patched version of the 9.3 snapshot tree, so I don't need to kill my dnssec stuff :P (And it's time for a non-snapshot bind version with full dnssec capabilities anyway :) if you ask that question on [EMAIL PROTECTED], i promise to answer. but i do not think details of that nature are interesting on [EMAIL PROTECTED]
Re: Providers removing blocks on port 135?
Mike Tancsa wrote: I am not advocating that at all. (everyone's doing it, so let's not bother) However, I dont see what the municipal government has to do with a matter like this. I imagine its a civil issue where you have to get the lawyers involved :( Certainly if the company persisted, we would have done so. The fact that they can then go to another ISP who does not care and allows them to use their network is another issue. Of course, it depends on the local laws, but in many locations, pornography has a lot of restrictions and when those restrictions are broken, it becomes a criminal matter. For example, most of my user's have family accounts. This means that their email is not only theirs but their children and grandchildren's. Even if the owner of the account is an adult, the fact that their children are present when they read their email means that all pornographic spam they receive is essentially being delivered to a minor. This is especially true with misleading subject lines where children are exposed to unwanted material before anyone realizes it. In Oklahoma, at least, it is a criminal offense to expose children to pornographic material. -Jack
Re: bind patches++ (Re: Wildcards)
Hello Paul , All , Is there a url listing the TLD's that officially use wild cards in their deployment ? nope. right now you just have to know. we're trying to keep a list of places that either use wildcards and have been accepted by the community, or don't use wildcards but run bind8 or other old broken software that incorrectly sends answers rather than referrals when queried for data held as subzone glue... see www.isc.org/products/BIND/delegation-only.html for details. ...and that's where you'll find it. it's very possible that declaring a small number of zones delegation-only will be less work and less intrusive than trying to find/list the exceptions.
Re: Providers removing blocks on port 135?
At 01:18 PM 23/09/2003, Jack Bates wrote: Mike Tancsa wrote: I am not advocating that at all. (everyone's doing it, so let's not bother) However, I dont see what the municipal government has to do with a matter like this. I imagine its a civil issue where you have to get the lawyers involved :( Certainly if the company persisted, we would have done so. The fact that they can then go to another ISP who does not care and allows them to use their network is another issue. Of course, it depends on the local laws, but in many locations, pornography This user was sending *out* from our network, not to our users. It would have been up to the authorities in said localities to bring charges against them. I did what I could here. The only cost effective way to deal with things like this is for the ISP to act which we did. Oklahoma would be foolish to spend tens of thousands of dollars to go after this idiot. Really, your state money is better spent elsewhere. This is not very different than the ISPs out there not bothering to clean up their infected users (my favorite rant for the quarter). Looking at http://isc.sans.org/port_details.html?port=135repax=1tarax=2srcax=2percent=Ndays=70Redraw=Submit+Query it would appear by the number of source addresses, there has not been any significant reduction in blaster and its variants. ---Mike has a lot of restrictions and when those restrictions are broken, it becomes a criminal matter. For example, most of my user's have family accounts. This means that their email is not only theirs but their children and grandchildren's. Even if the owner of the account is an adult, the fact that their children are present when they read their email means that all pornographic spam they receive is essentially being delivered to a minor. This is especially true with misleading subject lines where children are exposed to unwanted material before anyone realizes it. In Oklahoma, at least, it is a criminal offense to expose children to pornographic material. -Jack
Re: Windows updates and dial up users
If you bought your Windows from an OEM, you're pretty much screwed because Micr0$0ft has transferred all responsibility to the OEM, and, the OEMs don't want to issue refunds because that costs them on their deal with Micr0$0ft. (A questionable business practice on M$ part, at best). However, every time I have purchased a copy of Windows from Micr0$0ft or from a store without a computer, discovered it didn't work, called Micr0$0ft and insisted that they deliver what they promise, they have cheerfully offered to refund my money, and, I have always gotten my refund within 2-3 weeks of sending them their piece of shit product. If you're OEM doesn't refund you, the simplest course of action is to print out the EULA you didn't agree to which says in clear text that you are entitled to a refund from your OEM (at least the last time I looked at one, which, was probably NT4 or W2K at the latest). Attach that to your small-claims filing, and, have the OEM served (certified mail usually works with corporations). It's always good to name the CEO as a party in the suit and send the service to him personally as well as the corporation generally. In any case, my point is that at best, they'll refund your money. They don't feel they have any responsibility for the consequences of their actions. Owen --On Tuesday, September 23, 2003 11:01 AM -0400 Henry Yen [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2003 at 10:02:57AM -0700, Owen DeLong wrote: Ok then different idea, assuming that we're all agreed its MS's responsibility to ensure users are patched promptly and without extra cost to the end user. The problem is that while we agree, Micr0$0ft does not. They feel they should have no responsibility whatsoever to the end user beyond cheerfully refunding their money if they decide to stop using Windows. Microsoft does not issue refunds if you stop using Windows, whether or not you were satisfied with the XPerience. My interactions with Microsoft have never been cheerful, which is a state mostly reserved for New Product Launch(tm) parties and advertisements. Nor can one readily obtain a refund from an OEM, even if you never use Windows and reject the EULA (http://windowsrefund.net/index2.php). -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
Re: bind 9.2.3rc3 successful
On Tue, 2003-09-23 at 01:35, William Allen Simpson wrote: Thought I'd mention that I helped setup BIND 9.2.3rc3 on a yellowdog linux powercomputing machine tonight. It worked. And the mail queues began clearing out. Just for an oddball success report. I upgrade our DNS server the week-end but only to bind 9.2.2-P2. (And I see there's a new release already. Sigh...) It's helped clear out a bunch of mail queues. I'm new to the list, but I do want to echo the thanks to Paul Vixie and the ISC for their prompt work. Thanks You very much! -- Stephen L Johnson [EMAIL PROTECTED] Unix Systems Administrator [EMAIL PROTECTED] Department of Information Systems State of Arkansas 501-682-4339
Re: Verisign Responds
I wonder btw why Verisign didn't catch the typo's in their own domains if they think it is that important: ... ;; QUESTION SECTION: ;.verisign.com. IN A wildcards don't work that way. there are ns rr's in .com for verisign.com, so you get a referral to those servers no matter whether a *.com wildcard exists or not.
Re: Verisign Responds
Paul Vixie wrote: wildcards don't work that way. there are ns rr's in .com for verisign.com, so you get a referral to those servers no matter whether a *.com wildcard exists or not. I think the point was that if catching typographical errors was so important to verisign, they would have created a *.verisign.com wildcard as well. -Jack
Re: Verisign Responds
On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2003, Dave Stewart wrote: Courts are likely to support the position that Verisign has control of .net and .com and can do pretty much anything they want with it. ISC has made root-delegation-only the default behaviour in the new bind, how about drafting up an RFC making it an absolute default requirement for all DNS? That would be making a fundamental change to the DNS to make wildcards illegal anywhere. Is that what you want? no it wouldnt. it would ust make wildcards illegal in top level domains, not subdomains. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Re: Verisign Responds
On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2003, Dave Stewart wrote: Courts are likely to support the position that Verisign has control of .net and .com and can do pretty much anything they want with it. ISC has made root-delegation-only the default behaviour in the new bind, how about drafting up an RFC making it an absolute default requirement for all DNS? That would be making a fundamental change to the DNS to make wildcards illegal anywhere. Is that what you want? no it wouldnt. it would ust make wildcards illegal in top level domains, not subdomains. -Dan really? and how would that work? (read be enforced...) --bill
Re: Verisign Responds
-BEGIN PGP SIGNED MESSAGE- Paul Vixie [EMAIL PROTECTED] wrote:- We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity. What else does the IETF need to do here? issue an rfc. iab is not a representative body, and their opinions are not refereed. Yes indeed, but one has to ask the question What about ICANN's recommendations? and what they might have to do to have them implemented. As an outsider to the politics of ICANN, registries, registrars and the like, it boggles my mind that Verisign, a company issued with a contract by ICANN to run a gTLD, should be able to make technical changes which cause significant breakage (and hence cost the Internet community to fix/workaround), and should then be quite so demonstrably unwilling to accept ICANN's polite request. It seems to me that there must be something seriously broken in the procedures or contracts that a situation such as this could occur. The consensus technical view seems to be that the wildcard introduction has been a destabilising influence and yet ICANN, who are charged with the responsibility of ensuring the stability of the Internet, seem powerless to do anything about it. It's all most bizarre! Best wishes, Matthew -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAgUBP3CPCwKwLwcHEv69AQGUKwP/dXTWek8Zh2fjGqjLjjhKJSY+y2FPYObI 0Q8o1IgCumuGxPlARDcy4JxZAzGa6NmU5bLyLSfLtJwZoSDeMCyvu4zVDUy5kfMN As0KrXVrkgEl8eRh1mZrQGdkf3SQIrhYhugAfX5LRBxZwMn3lcFMAhw1qUKJ+km5 IKtSQztc/sM= =kB7Y -END PGP SIGNATURE-
Re: Verisign Responds
[EMAIL PROTECTED] wrote: On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2003, Dave Stewart wrote: Courts are likely to support the position that Verisign has control of .net and .com and can do pretty much anything they want with it. ISC has made root-delegation-only the default behaviour in the new bind, how about drafting up an RFC making it an absolute default requirement for all DNS? That would be making a fundamental change to the DNS to make wildcards illegal anywhere. Is that what you want? no it wouldnt. it would ust make wildcards illegal in top level domains, not subdomains. -Dan really? and how would that work? (read be enforced...) The same way all RFCs and Standards are enforced, by the IETF Delta Squad Elite Stormtrooper Interdiction Unit Strike Force. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Verisign Responds
On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2003, Dave Stewart wrote: Courts are likely to support the position that Verisign has control of .net and .com and can do pretty much anything they want with it. ISC has made root-delegation-only the default behaviour in the new bind, how about drafting up an RFC making it an absolute default requirement for all DNS? That would be making a fundamental change to the DNS to make wildcards illegal anywhere. Is that what you want? no it wouldnt. it would ust make wildcards illegal in top level domains, not subdomains. really? and how would that work? (read be enforced...) Well yes thats part of the problem. It looks like verisign doesnt care what anyone (ICANN, IAB, operators) thinks. But if we can mandate via RFC it for dns software (servers, resolvers) etc. Then we go a ways to removing verisign from the equation. Verisign can do what they like, everyone will just ignore their hijacking. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Re: Verisign Responds
it would ust make wildcards illegal in top level domains, not subdomains. there are tlds with top level wildcards that are needed and in legitimate use. verisign has not done anything strictly against spec. this is a social and business issue. all this noise and bluster is depressing. it indicates that we are in a very quickly maturing industry because a lot of probably-soon-to-be-ex engineers have too much time on their hands. randy
Re: Verisign Responds
On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2003, Dave Stewart wrote: Courts are likely to support the position that Verisign has control of .net and .com and can do pretty much anything they want with it. ISC has made root-delegation-only the default behaviour in the new bind, how about drafting up an RFC making it an absolute default requirement for all DNS? That would be making a fundamental change to the DNS to make wildcards illegal anywhere. Is that what you want? no it wouldnt. it would ust make wildcards illegal in top level domains, not subdomains. really? and how would that work? (read be enforced...) Well yes thats part of the problem. It looks like verisign doesnt care what anyone (ICANN, IAB, operators) thinks. But if we can mandate via RFC it for dns software (servers, resolvers) etc. Then we go a ways to removing verisign from the equation. Verisign can do what they like, everyone will just ignore their hijacking. lets try this again... why should a valid DNS protocol element be made illegal in some parts of the tree and not others? if its bad one place, why is it ok other places? --bill
Foundry BigIron series
We're considering switching to Foundry BigIrons (probably the 4000, as opposed to Cisco 6500 series switches. We're currently using 7206VXRs). Anyone have opinions (on or off list) on this product? Looking through the archives, I don't notice any discussions of this since about 2001 [1]. (http://www.foundrynet.com/products/l3backbone/bigiron/BigIronx00Datasheet.html) I'm mostly interested in its BGP implementation, as the boxes would be handling our core routing via BGP. (I haven't noticed anyone complaining about BGP problems in the past year or so); also opinions on the CLI would be helpful (I'm told it's 95% identical to IOS's CLI). The CLI was another complaint in the thread cited below, so I'm curious if it has improved since 2001. I'd be interested in hearing about the comparable Riverstone boxes as well. [1] thread starting at http://www.merit.edu/mail.archives/nanog/2002-09/msg00050.html -- Since when is skepticism un-American? Dissent's not treason but they talk like it's the same... (Sleater-Kinney - Combat Rock)
Re: Verisign Responds
lets try this again... why should a valid DNS protocol element be made illegal in some parts of the tree and not others? if its bad one place, why is it ok other places? because some engineers think that all social and business problems can be solved by technical hacks. it's the godess's revenge for the lawyers who think all engineering problems can be solved at layer nine. randy, who will go back to work now
Re: Verisign Responds
Daniel Karrenberg wrote: What else does the IETF need to do here? Recognize the legacy status of certain zones and establish strict criteria for making configuration changes to them. This would be in addition to any guidance for all zones with delegations. KL
RE: Foundry BigIron series
Hey Will, I do not have experience using any Foundry boxes. I do however use Riverstone extensively; my whole network is composed of RS boxes ranging from RS3000's up to RS8600's. I have an RS8600 handling my core routing right now! Im taking full bgp tables from 3 upstreams and several gig and ds-3 links for my OSPF backbone. I used to have a 7206VXR trying to do the same. The cli is in my opinion easier than Cisco's IOS to learn. It has plenty of neat features that make it very user friendly. The only issue I have had is with the way it handles flows. I used to hit 100% cpu utilization when my traffic peaked due to the way the flows were handled. However, the problem was sort of fixed by enabling Riverstone's version of Cisco's CFE and move the flows to the ASIC's in the linecards. Just as an example during my peak usage I move between 300-350Megs of traffic and my cpu barely goes above 10% utilization. The draw back is that I can not use ACL's as effectively in my core, so I moved all my ACL's to my edge routers! Oh, and they are a fraction of the cost of the other big name brands. If you want any more info you are more than welcome to ask. Regards, -- Joel Perez [EMAIL PROTECTED] | IP Engineer http://www.ntera.net/ | Ntera 305.914.3412 -Original Message- From: Will Yardley [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 2:55 PM To: [EMAIL PROTECTED] Subject: Foundry BigIron series We're considering switching to Foundry BigIrons (probably the 4000, as opposed to Cisco 6500 series switches. We're currently using 7206VXRs). Anyone have opinions (on or off list) on this product? Looking through the archives, I don't notice any discussions of this since about 2001 [1]. (http://www.foundrynet.com/products/l3backbone/bigiron/BigIronx00Datas heet .html) I'm mostly interested in its BGP implementation, as the boxes would be handling our core routing via BGP. (I haven't noticed anyone complaining about BGP problems in the past year or so); also opinions on the CLI would be helpful (I'm told it's 95% identical to IOS's CLI). The CLI was another complaint in the thread cited below, so I'm curious if it has improved since 2001. I'd be interested in hearing about the comparable Riverstone boxes as well. [1] thread starting at http://www.merit.edu/mail.archives/nanog/2002-09/msg00050.html -- Since when is skepticism un-American? Dissent's not treason but they talk like it's the same... (Sleater-Kinney - Combat Rock)
Re: Verisign Responds
On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2003, Dave Stewart wrote: Courts are likely to support the position that Verisign has control of .net and .com and can do pretty much anything they want with it. ISC has made root-delegation-only the default behaviour in the new bind, how about drafting up an RFC making it an absolute default requirement for all DNS? That would be making a fundamental change to the DNS to make wildcards illegal anywhere. Is that what you want? no it wouldnt. it would ust make wildcards illegal in top level domains, not subdomains. really? and how would that work? (read be enforced...) Well yes thats part of the problem. It looks like verisign doesnt care what anyone (ICANN, IAB, operators) thinks. But if we can mandate via RFC it for dns software (servers, resolvers) etc. Then we go a ways to removing verisign from the equation. Verisign can do what they like, everyone will just ignore their hijacking. lets try this again... why should a valid DNS protocol element be made illegal in some parts of the tree and not others? if its bad one place, why is it ok other places? Well one point is from http://www.icann.org/tlds/ only domains classed as 'sponsored' previously had wildcards. Domains that are unsponsored including .net and .com are supposed to operate under policy established from the global community thro ICANN. Also this is a specific case, .net/.com have legacy implications and no one including Verisign is naive enough to believe that this would have been ok. This is why they have done it in the way they have without consultation. A number of people claim they are acting in breach of their charter with ICANN, sure (Randy) this is a social argument, but theres technical ones as well but they dont stand up so well in the courtroom.. Steve
Re: Verisign Responds
On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2003, Dave Stewart wrote: Courts are likely to support the position that Verisign has control of .net and .com and can do pretty much anything they want with it. ISC has made root-delegation-only the default behaviour in the new bind, how about drafting up an RFC making it an absolute default requirement for all DNS? That would be making a fundamental change to the DNS to make wildcards illegal anywhere. Is that what you want? no it wouldnt. it would ust make wildcards illegal in top level domains, not subdomains. really? and how would that work? (read be enforced...) Well yes thats part of the problem. It looks like verisign doesnt care what anyone (ICANN, IAB, operators) thinks. But if we can mandate via RFC it for dns software (servers, resolvers) etc. Then we go a ways to removing verisign from the equation. Verisign can do what they like, everyone will just ignore their hijacking. lets try this again... why should a valid DNS protocol element be made illegal in some parts of the tree and not others? if its bad one place, why is it ok other places? --bill Because of who is affected by the element. At the TLD level, many are affected, at the domain level, then its a much smaller subset. Ultimately, as Randy has already said, it is a business and social problem. From a business standpoint, why should an organization be forced to use its own resources to work around Verisign's plan to put more money in its own packet. From a social aspect, since Verisign has grown to be one of the most hated (a decidedly non-business adjective) and distrusted organizations existing. It pisses people off that they have found an unfair advantage to use resources in bad faith, to generate revenue from people's typos and ignorance. It smacks of being unethical, underhanded, illegal, and generally the opposite of generating revenue by providing a quality service to your loyal customers. The technical hacks are a testament to our culture and provide instance gratification while the slower moving social and business issues are worked it. They help to gratify the emotional need to generally do the right thing. andy -- PGP Key Available at http://www.tigerteam.net/andy/pgp
Re: Verisign Responds
Randy Bush wrote: it would ust make wildcards illegal in top level domains, not subdomains. there are tlds with top level wildcards that are needed and in legitimate use. verisign has not done anything strictly against spec. this is a social and business issue. And this in itself indicates a possible failure in our model. When someone can do something that causes so much outrage, and we the community have no recourse, something is wrong. Maybe we're in the realm of politics, but our implementations reflect our values. Do you feel the same today about the GPG/PGP v. X.509 as you did before Verisign decided to become an unauthorized interloper? Might we have a standards problem with SSL, because people cannot simply NOT trust Verisign certs? After all, how many certificates can you get out of SSL for a server or a client? all this noise and bluster is depressing. it indicates that we are in a very quickly maturing industry because a lot of probably-soon-to-be-ex engineers have too much time on their hands. I take a different view. If people who are upset with Verisign's change DON'T say anything, then there's no reason for Verisign to change. I suspect that the better forum may be one's Congress person... Eliot
monkeys.dom UPL being DDOSed to death
Hi! After Osirusoft was shut down most likely Infinite-Monkeys are doing down also ?? See: [Mimedefang] monkeys.dom UPL being DDOSed to death Jon R. Kibler [EMAIL PROTECTED] Tue Sep 23 14:15:01 2003 Greetings to all: I have some really sad news. I just got off the telephone with Ron Guilmette who runs the monkeys.com Unsecured Proxies List DNSBL. I hate to say it, but monkeys.com has been killed. It has been DDOSed to death. Ron says that every aspect of his network is undergoing a massive DDOS attack from thousands of IPs -- apparently many/all spoofed. He has tried to get law enforcement to investigate, but to no avail. He indicated that this is probably the end of his service. This makes two DNSBLs that have been DDOSed to death recently. Which one is next? NJABL? ORDB? The computer security industry really needs to figure out how to get law enforcement to take these attacks seriously. It would only take a few good prosecutions to put an end to these types of attacks. Any thoughts/suggestions? This is really a dark day for those of us fighting spam. I looks like the spammers have won a BIG battle. The only question now is who will be the causality in this war? Jon R. Kibler A.S.E.T., Inc. Charleston, SC USA This is pretty sad. bye, Raymond.
Re: Verisign Responds
On Tue, 23 Sep 2003, Randy Bush wrote: some engineers think that all social and business problems can be solved by technical hacks. Dunno about some engineers, but engineers in general can do a lot to avoid creation of many problems in the first place. This wildcard flop is a perfect example of a bad design decision coming back to bite. I'd say that engineers pay too little attention to the social and business implications of their decisions. --vadim
Re: Verisign Responds
At 11:47 AM -0700 9/23/03, [EMAIL PROTECTED] wrote: lets try this again... why should a valid DNS protocol element be made illegal in some parts of the tree and not others? if its bad one place, why is it ok other places? There's a simple answer and a not so simple. The simple answer is because in one part of the tree it was expected by all players up front, and in the other it wasn't. However in general I tend to agree. The things that Verisign broke (and which have cost my company several thousand dollars in lost time and unplanned programming tasks, never mind the increase in spam) are also broken by other TLDs that use wildcards. The issues weren't clear because the impact was small. Now that they are clear, those decisions should also be revisited. -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: Verisign Responds
Dan Hollis wrote: On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2003, Dave Stewart wrote: Courts are likely to support the position that Verisign has control of .net and .com and can do pretty much anything they want with it. ISC has made root-delegation-only the default behaviour in the new bind, how about drafting up an RFC making it an absolute default requirement for all DNS? That would be making a fundamental change to the DNS to make wildcards illegal anywhere. Is that what you want? no it wouldnt. it would ust make wildcards illegal in top level domains, not subdomains. Actually, it's worst than that. root-delegation-only does not just change the wildcard behavior. RRs which are in the tld itself instead of being delegated (like some of the ccTLDs) break if forced into root-delegation-only. This is one of the points in the IAB opinion concerning remedies causing other problems. The issue itself is political, but it does have technical ramifications. It's still to be seen if ISC's cure is worse than the disease; as instead of detecting and stoping wildcard sets, it looks for delegation. It is also configurable to a degree that inexperienced operators will break their DNS implementations out of ignorance (like ignoring the ISC recomendation and root-delegating .de). One should consider sponsored TLDs like .museum the exception. If you have filtering rules (like smtp) that are bypassed as a result of the wildcard, then those rules themselves should be changed. The sponsored TLDs and even a lot of the ccTLDs have a rather small subdomain base, allowing for unified agreement on changes made to the zone. The legacy TLD's should be rather static to ensure stability in DNS architecture overall. The subdomain base is massive, making communication and agreement on changes difficult. If I'm not mistaken, this is one of the duties of ICANN. -Jack
Re: Verisign Responds
Leo Bicknell wrote: Looks like the lawsuits are going to be the ones to settle this dispute...anyone think there's a chance of ICANN pulling .COM and .NET from Verisign due to breach of contract? I think it's highly unlikely. Dave Stewart wrote: Oh, I dunno... ICANN has no teeth, so that won't happen. Shouldn't one of them smarty-pants attorneys file for an immediate injunction against VeriSign? Looks like plenty of technical arguments have been posted here which even the most dim-witted judge would understand vs. the public position taken by VeriSign that they should keep their cash register jingling with Sitefinder proceeds while the topic is studied and/or fought over for another 24 months. It's obvious to me that the technical arguments fade out quickly if the service is kept up and running. VeriSign cashes in while everyone else incurs the expense of implementing workarounds and bug-fixes. Once the workarounds are in place for more than a couple weeks, there isn't much impetus to put everything back the way it was. Has an injunction been requested? -rich
Re: monkeys.dom UPL being DDOSed to death
On Tue, 23 Sep 2003, Raymond Dijkxhoorn wrote: After Osirusoft was shut down most likely Infinite-Monkeys are doing down also ?? Anyone SERIOUSLY interested in designing a new PTP RBL system 100% immune to DDOS, please drop me a line. By seriously, i mean those who actually want to solve the problem, not those who want to be whiny pedants. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Re: monkeys.dom UPL being DDOSed to death
Raymond Dijkxhoorn wrote: [Mimedefang] monkeys.dom UPL being DDOSed to death Jon R. Kibler [EMAIL PROTECTED] Tue Sep 23 14:15:01 2003 The computer security industry really needs to figure out how to get law enforcement to take these attacks seriously. It would only take a few good prosecutions to put an end to these types of attacks. Any thoughts/suggestions? This is really a dark day for those of us fighting spam. I looks like the spammers have won a BIG battle. The only question now is who will be the causality in this war? This goes beyond spam and the resources that many mail servers are using. These attacks are being directed at anti-spam organizations today. Where will they point tomorrow? Many forms of breaking through network security require that a system be DOS'd while the crime is being committed. These machines won't quiet down after the blacklists are shut down. They will keep attacking hosts. For the US market, this is a national security issue. These systems will be exploited to cause havoc among networks of all types and sizes; governmental and commercial. Windows Update may be protected for now, but it still has limitations. It can be killed to the point of non use. Then how will system get patched to protect themselves from new exploits? The problem will escalate. There are many financial institutions online. Does anyone doubt that their security can be penetrated? What about DoD networks? There are a lot of social aspects to internetworking. Changes need to be made. Power needs to be allocated appropriately. A reconing needs to occur. All the businesses that make and spend mass amount of money due to the Internet need to strongly consider that there won't be a product if the social ramifications are solved. Users don't want to be online and check email just to find hundreds of advertisements, pornography, and illegal material in their inbox. Users don't want to hear that they've been infected with the latest virus and can no longer be online until they fix the problem; usually resulting in money. Users don't want to hear that they can't reach site X because of some change in architecture. If the general masses get fed up with the Internet, there won't be an Internet. Millions of dollars are easily being lost because of malicious activity on the Internet. Millions more are being lost due to differences of opinion in the governing bodies of the Internet. Is everyone so short sighted and greedy as to not recognize that they are dying a slow financial death? -jack
Re: Foundry BigIron series
I've gotten some really useful responses off list. Sorry for the extra noise, but I'm going to summarize the responses to the list later today (for the archives)... I'm removing names, email addresses, company names and other identifying stuff in case anyone doesn't want to be quoted publicly, but if you don't want me to quote you at all, please do send me a heads up. -- Since when is skepticism un-American? Dissent's not treason but they talk like it's the same... (Sleater-Kinney - Combat Rock)
[Fwd: monkeys.dom UPL DNSBL being DDOSed to death]
Forwarded for your information. That leave 2 proxy DNSbls left - SORBS and DSBL... Looking at the stats for SORBS over at SDSC looks like SORBS is pretty ineffective thanks to the DDoS: (see: http://www.sdsc.edu/~jeff/spam/cbc.html) Original Message From: Jon R. Kibler [EMAIL PROTECTED] Newsgroups: news.admin.net-abuse.email Subject: monkeys.dom UPL DNSBL being DDOSed to death Date: Tue, 23 Sep 2003 14:26:47 -0400 Greetings to all: I have some really sad news. I just got off the telephone with Ron Guilmette who runs the monkeys.com Unsecured Proxies List DNSBL. I hate to say it, but monkeys.com has been killed. It has been DDOSed to death. Ron says that every aspect of his network is undergoing a massive DDOS attack from thousands of IPs -- apparently many/all spoofed. He has tried to get law enforcement to investigate, but to no avail. He indicated that this is probably the end of his service. This makes two DNSBLs that have been DDOSed to death recently. Which one is next? NJABL? ORDB? The computer security industry really needs to figure out how to get law enforcement to take these attacks seriously. It would only take a few good prosecutions to put an end to these types of attacks. Any thoughts/suggestions? This is really a dark day for those of us fighting spam. It looks like the spammers have won a BIG battle. The only question now is who will be the causality in this war? Jon R. Kibler A.S.E.T., Inc. Charleston, SC USA
Detecting a non-existent domain
Getting practical for a minute. What is the optimal way now to see if a given host truly exists? Assume that I can't control the DNS server--I need to have this code run in any (*ix) environment. Assume also that I don't want to run around specialcasing specific IP addresses or TLDs--this needs to work reliably no matter what the domain. User gives me a string, and I need to see if the given host is a real machine. An answer from Verisign would be most appropriate here, since they have done extensive research on the impact of their new service, so presumably they figured out the answer to this problem and have code samples available for distribution. However I get the feeling from their press releases that they've forgotten there is more to the internet than just the web. -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: Verisign Responds
Folks, EL And this in itself indicates a possible failure in our model. When EL someone can do something that causes so much outrage, and we the EL community have no recourse, something is wrong. Maybe we're in the EL realm of politics, but our implementations reflect our values. Verisign effectively disabled an error response. The response would not exist in the protocol if it were not to be used. Hence, Versign changed the protocol. That's a technical violation of the standard, not a social or business one. Folks are free to negotiate their own version of protocols. However, when a provider imposes a change by fiat, they have rendered the work technically proprietary. The IAB and the ICANN advisory panel reports characterise the technical issues carefully and thoroughly. They make clear that the technical and operational ramifications of this change are massive. /d -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Re: monkeys.dom UPL being DDOSed to death
http://www.openrbl.org is also offline due to a DDoS. ---Mike At 05:04 PM 23/09/2003, Joe St Sauver wrote: Hi, #This goes beyond spam and the resources that many mail servers are #using. These attacks are being directed at anti-spam organizations #today. Where will they point tomorrow? Many forms of breaking through #network security require that a system be DOS'd while the crime is being #committed. These machines won't quiet down after the blacklists are shut #down. They will keep attacking hosts. For the US market, this is a #national security issue. These systems will be exploited to cause havoc #among networks of all types and sizes; governmental and commercial. Note that not all DNSBLs are being effectively hit. DNSBLs which run with publicly available zone files are too distributed to be easily taken down, particularly if periodic deltas are distributed via cryptographically signed Usenet messages (or other push channels). You can immunize DNSBLs from attack, *provided* that you're willing to publicly distribute the contents of those DNSBLs. And when it comes to dealing with the sources of these attacks, we all know that there are *some* networks where security simply isn't any sort of priority. (For example, make it a practice to routinely see what ISPs consistently show up highly ranked on incident summary sites such as http://www.mynetwatchman.com/ ). Maybe the folks running those networks are overworked and understafffed, maybe they have legal constraints that limit what they can do, maybe their management just don't care as long as they keep getting paid. Who knows? Whatever the reason, no one is willing to depeer them or filter their routes, so they really are free to do absolutely *nothing* about vulnerable hosts or abusive customers. There are absolutely *no* consequences to their security inactivity, and because of that, none of us should be surprised that the problem is becoming a worsening one. Regards, Joe St Sauver ([EMAIL PROTECTED]) University of Oregon Computing Center
Re: Providers removing blocks on port 135?
On Tue, 23 Sep 2003, Mike Tancsa wrote: The credit cards in our case were legit. They were different numbers, but they were not stolen. That would make a difference. The credit card companies probably wouldn't care if you told them that the cards were being used by their customer for illegal activity. Stolen, maybe. Anything else they could probably care less about. They are usuaully fairly responsive when it comes to them loosing money. Secondly after I contacted the local police, state BI, and perhaps the FBI (assuming no luck could be had with any of them) I am in Canada, but I know that it has been stated that the FBI will not investigate computer fraud if damage is under $100,000. I didn't realize you were in Canada. That makes a difference. The dollar amount with the FBI varies widely. I've heard over $5,000, $25,000, $50,000, now $100,000. I don't think there's a hard set rule. I think it basically boils down to the old fashioned will-it-get-us-good-PR-with-little-or-not-work rule of thumb. :) I doubt a porn company with international clientele would give a toss about what the local media say. Local media would have been useful not against the spammers but against the local lw enforcement that refuses to do anything about it. Since however your local law enforncement can't do much about (international borders et al) then the local media wouldn't really care. Local government has nothing to do with it. It was just some dime a dozen porn company. Ditto for what I said above. The part about being in Canada changes things considerably from what I was assuming. I must have missed that earlier. Still it's worked in the past in other circumstances so the practice is fairly sound. It just won't work in your case. My only other advice would involve what's suggested in man 8 syslogd under SECURITY THREATS, option number 5. Best of luck. Justin
Re: monkeys.dom UPL being DDOSed to death
On Tue, 23 Sep 2003, Joe St Sauver wrote: There are absolutely *no* consequences to their security inactivity, and because of that, none of us should be surprised that the problem is becoming a worsening one. china seems hellbent on becoming a LAN. i see the same thing eventually happening to networks which refuse to deal with their ddos sources. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Re: monkeys.dom UPL being DDOSed to death
On Tue, 23 Sep 2003, Jack Bates wrote: This goes beyond spam and the resources that many mail servers are using. These attacks are being directed at anti-spam organizations today. Where will they point tomorrow? Many forms of breaking through network security require that a system be DOS'd while the crime is being committed. These machines won't quiet down after the blacklists are shut down. They will keep attacking hosts. For the US market, this is a national security issue. These systems will be exploited to cause havoc among networks of all types and sizes; governmental and commercial. It's somewhat funny. Quite some time ago, us IRC server operators warned about this same thing, and were mostly just told to not run IRC servers. The anti-spammers will likely just get told to not run DNSBL's. This only works up until the point that it's YOUR service thats getting hit and people tell you to stop running it. For several years now I've noticed a trend of technologies being used to attack IRC servers being later abused to send SPAM. First it was the open wingates, then the misconfigured Cisco's, then the HTTP Proxies. It looks like the large botnets are now being harvested by spammers to fight the Anti spammers. This is something we IRC server admins, and other high profile services like it which draw such attacks have been dealing with for some time. Ron, good luck with it. You're stuck between a rock and a hard place. If you down it the kiddies win again, and will feel they can bully the next guy. If you don't your network is crippled. It's a no win situation. Jason -- Jason Slagle - CCNP - CCDP /\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail .
Re: Detecting a non-existent domain
On Tue, 23 Sep 2003, Kee Hinckley wrote: Getting practical for a minute. What is the optimal way now to see if a given host truly exists? Assume that I can't control the DNS Look for a SOA record for the domain - this should be the proper way to check for the existance of a domain, instead of looking for A, NS or MX records.. box:~# dig assvsvsdcacdasc.com SOA ; DiG 9.1.3 assvsvsdcacdasc.com SOA ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47940 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;assvsvsdcacdasc.com. IN SOA ;; AUTHORITY SECTION: com.10800 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 2003092300 1800 900 604800 86400 box:~# dig yahoo.com SOA ; DiG 9.1.3 yahoo.com SOA ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50827 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0 ;; QUESTION SECTION: ;yahoo.com. IN SOA ;; ANSWER SECTION: yahoo.com. 1800IN SOA hidden-master.yahoo.com. hostmaster.yahoo-inc.com. 2003092304 900 300 604800 600 Note the difference in QUERY and ANSWER numbers for the two... - d. -- Dominic J. Eidson Baruk Khazad! Khazad ai-menu! - Gimli --- http://www.the-infinite.org/
Re: monkeys.dom UPL being DDOSed to death
On Tue, 23 Sep 2003 14:15:48 PDT, Dan Hollis said: china seems hellbent on becoming a LAN. i see the same thing eventually happening to networks which refuse to deal with their ddos sources. Well.. that's all fine and good, except we first need one large player to put their foot down and say That's enough of this manure, we're depeering you and blocking your prefixes till you clean up your act. Once *one* big player does that, your eventually happening will be pretty fast. pgp0.pgp Description: PGP signature
Re: monkeys.dom UPL being DDOSed to death
Joe St Sauver wrote: Note that not all DNSBLs are being effectively hit. DNSBLs which run with publicly available zone files are too distributed to be easily taken down, particularly if periodic deltas are distributed via cryptographically signed Usenet messages (or other push channels). You can immunize DNSBLs from attack, *provided* that you're willing to publicly distribute the contents of those DNSBLs. Actually, SBL has had a lot of issues. The issue isn't always with the dns zones. It is true that one can distribute the zones to make dDOS more difficult; although not impossible. However, in the case of SBL, they have had issues with the web servers being dDOS'd. The ability to lookup why a host is blacklisted, and in the case of relay/proxy lists to request removal, is also important. There are still a lot of blacklists out there; njabl, ordb, dsbl, reynolds, sbl, and spews (in a round about sort of way). Yet what happens when a business desides to destroy his competitor's website? What happens when someone decides they don't like magazine X or vendor X and attacks their web farms? Shall the Internet be called akamai? Don't get me wrong. It's a good service, but not invulnerable. windowsupdate.com can still be brought to it's knees if the attacker is persistant enough. Of course, when big money businesses are involved, things get done. Yet what about the smaller business or the charity? What about critical infrastructure? Does anyone claim that MAE East and West couldn't be made inoperational by dDOS? How does that shift the network and peering? What are the ramifications? Of the various RPC worms, spybot is the most malicious in intent. Yet what if parts of Swen/Gibe/Sobig.F were incorporated into blaster. Process terminations to make repair difficult and to open the computer to other viruses and vulnerabilites. Installed proxy servers and bots. Keyloggers. Now collect your information, gather your bots, and watch a single phrase create destruction. Things have not improved over the last year. They have gotten worse. The Internet is more malicious than ever. It is quickly becoming the Inner City Projects of communication. Greed and hatred created some of the worst neighborhoods in the world. The same concept will apply to network. If action isn't taken, it will get worse. More money will be lost over the coming years. Many people will be hurt. Communication will be impaired. Question: Why is it not illegal for an ISP to allow a known vulnerable host to stay connected and not even bother contacting the owner? There are civil remedies that can be sought but no criminal. Bear in mind, these vulnerable hosts are usually in the process of performing malicious activity when they are reported. Ron has reported many of the IP addresses that dDOS'd monkeys.com. Under the same token, Ron has also reported to many ISP's about spammers which have abused servers under his control, scanning and utilizing open proxies; which is theft of resources. Why is nothing done about these people? Why is the ISP not held liable for allowing the person to continue in such malicious activity? -Jack
Re: Detecting a non-existent domain
Kee Hinckley wrote: Getting practical for a minute. What is the optimal way now to see if a given host truly exists? Assume that I can't control the DNS server--I need to have this code run in any (*ix) environment. Assume also that I don't want to run around specialcasing specific IP addresses or TLDs--this needs to work reliably no matter what the domain. User gives me a string, and I need to see if the given host is a real machine. A set comparison between the domain your interested in and *.TLD will inform you if the domain is pointed to the same IP addresses as the wildcard. In many cases, this is sufficient and can be made to work dynamically and quickly with most software and scripts. -Jack
RE: Detecting a non-existent domain
On Tue, 23 Sep 2003, Kee Hinckley wrote: Getting practical for a minute. What is the optimal way now to see if a given host truly exists? Assume that I can't control the DNS Look for a SOA record for the domain - this should be the proper way to check for the existance of a domain, instead of looking for A, NS or MX records.. He asked for the optimal way to see if a given host truly exists and you told him how to confirm or deny the existance of a domain. He asked about hosts, you answered about domains. DS
Re: Detecting a non-existent domain
On Tue, Sep 23, 2003 at 04:24:32PM -0500, Dominic J. Eidson wrote: Look for a SOA record for the domain - this should be the proper way to check for the existance of a domain, No, because there doesn't _have_ to be a SOA RR for a 2nd level domain. For example, in the .de TLD, there are (many) domains which have their RRs (A, MX) in the de. zone file, NOT being delegated to another NS RRset. Example: fsck.de Regards, Daniel
Re: [Fwd: monkeys.dom UPL DNSBL being DDOSed to death]
Lewis, Chris [CAR:W669:EXCH] wrote: See cbl.abuseat.org. It's effectively a proxy DNSBL, and is more effective than any of the others. More effective than many of the more reasonable combo DNSBLs too. I should also mention that OPM and PSS (originally osirus's open socks proxy BL) are also quite good.
Re: monkeys.dom UPL being DDOSed to death
On Tuesday, Sep 23, 2003, at 17:32 Canada/Eastern, [EMAIL PROTECTED] wrote: On Tue, 23 Sep 2003 14:15:48 PDT, Dan Hollis said: china seems hellbent on becoming a LAN. i see the same thing eventually happening to networks which refuse to deal with their ddos sources. Well.. that's all fine and good, except we first need one large player to put their foot down and say That's enough of this manure, we're depeering you and blocking your prefixes till you clean up your act. Once *one* big player does that, your eventually happening will be pretty fast. In my recent experience, many, many network operators in North America and Europe who are really, really bad at tracking back source-spoofed DDoS traffic through their networks (there are also some notable, fine exceptions I've dealt with recently, who know who they are and should not feel slighted by this generality). If transit was uniformly denied to every operator who was not equipped to deal with DDoS tracking in a timely manner, I think 90% of the Internet would disappear immediately. This is not just an Asian problem. (Incidentally, I think if one big player suddenly decided to throw away the millions of dollars of revenue they earn through providing transit to east Asian countries, the likely effect would be another grateful big player leaping in to take over. I don't see a future in which the well-being of users in other peoples' networks trumps income.) Joe
Re: monkeys.dom UPL being DDOSed to death
Dan Hollis wrote: china seems hellbent on becoming a LAN. i see the same thing eventually happening to networks which refuse to deal with their ddos sources. This invites the question if the hijacked PC or the hijacker in the sunshine state is more guilty of the spam and ddos? I would expect disconnecting .fl.us have more positive effect to the Internet as whole than would .cn. Pete
Re: monkeys.dom UPL being DDOSed to death
On Tue, 23 Sep 2003, Joe Abley wrote: If transit was uniformly denied to every operator who was not equipped to deal with DDoS tracking in a timely manner, I think 90% of the Internet would disappear immediately. it gets worse. there are operators who *are* equipped, but refuse to deal not only with ddos tracking but with shutting off confirmed sources within their networks. the response is 'we will deal with it when we get a subpoena'. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Re: monkeys.dom UPL being DDOSed to death
On Tue, 23 Sep 2003, Jason Slagle wrote: It's somewhat funny. Quite some time ago, us IRC server operators warned about this same thing, and were mostly just told to not run IRC servers. A private IRC server with one user isn't much fun. The anti-spammers will likely just get told to not run DNSBL's. This only works up until the point that it's YOUR service thats getting hit and people tell you to stop running it. A private DNSBL with one user works just fine. If whoever is behind this succeeds in driving all the DNSBLs off the net what they'll really do is drive them all underground. In the short term, lots of networks will lose access to the public DNSBLs they've been using. The spammers will rejoice, but that will only fuel the creation of hundreds (maybe thousands) of new private DNSBLs. Necessity is the mother of invention. Those with clue, will run their own. Alot of those without will too. Some will likely even latch onto the last snapshot they got before the DNSBLs they were syncing went offline/private. These will, of course, get out of date and out of sync almost immediately. Once you host a customer who turns out to be a spammer, good luck getting those IPs removed from 1 private DNSBLs. E-mail abuse management may be the next field to really open up with job opportunities as networks will have to contact a large portion of the internet to try to get IPs cleared from everyone's private DNSBL...most of which will be poorly documented if at all. Just over 2 years ago, I posted a message titled Affects of the balkanization of mail blacklisting about how ex-MAPS users were using out-of-sync copies of the MAPS DUL after MAPS went commercial and those networks presumably lost access to the data. I guess that was just the tip of the iceberg. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: monkeys.dom UPL being DDOSed to death
On 9/23/2003 at 5:16 PM, Mike Tancsa [EMAIL PROTECTED] wrote: http://www.openrbl.org is also offline due to a DDoS. And the ignorance of front-end personnel in LE agencies, unless you are the NY Times and claim $500,000 in purely fictious damages, can be a bit frustrating. Spamcop and Spamhaus have been undergoing intense DDoS attacks for months, and I am only partially aware how they are being mitigated. If certain large operators can donate bandwidth and equipment for IRC servers in locations with OC-12 and better connectivity, AND live through the DDoS attacks that come with it, why not step forward and provide some forwarding-proxy service for some of the websites and distribution sites for DNSBLs, plus possibly proxying DNS traffic? OpenRBL.org has stated (http://www.openrbl.org/index-2.htm) that the bandwidth required for actual application traffic can be very low (0.5Mbps or less), not counting DDoS traffic. No arrangements of that kind have to be public knowledge. Other measures: - Got a spare /20 that can be used to make the forwarding proxy hop around a bit, every 5 minutes or so, with DNS TTLs in the 10-minute range? It's been done with 'moving-target' spamvertised sites like optinspecialists.info , which is currently using a LARGE number of compromised Windows hosts illegally to proxy DNS and HTTP traffic for them. They've been doing it for weeks. Do the registrars care? Hell no. (see morozreg.biz, bubra.biz, the domains used for DNS, domains you probably want to add local zone overrides for, in your nameservers, not your HOSTS file. Now we know how Al-Quaeda is hiding their websites, at last. It would be trivial to 'sinkhole' DoS traffic still going on to IPs of the recent past, greatly increasing the chances of catching the perpetrators as they keep switching their trojans to new IPs, hitting a few fully-sniffed honeypots while they are at it. - BGP anycast, ideally suited for such forwarding proxies. Anyone here feeling very adapt with BGP anycast (I don't) for the purpose of running such a service? This is a solution that has to be suggested and explained to some of the DNSBL operators. If someone reading this has gone forward with a private mailing list to discuss all these issues, I'd be happy to receive an invitation to donate my [lack of] smarts to the cause. bye,Kai
Re: monkeys.dom UPL being DDOSed to death
On Wed, 24 Sep 2003, Petri Helenius wrote: Dan Hollis wrote: china seems hellbent on becoming a LAN. i see the same thing eventually happening to networks which refuse to deal with their ddos sources. This invites the question if the hijacked PC or the hijacker in the sunshine state is more guilty of the spam and ddos? the operator hosting the hijacked PC is guilty if they are notified and refuse to take action. which seems to be all too common these days with universities and colocation companies. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
RE: Detecting a non-existent domain
Getting practical for a minute. What is the optimal way now to see if a given host truly exists? You first have to define what you mean by 'exists'. I have a machine here that I call 'stinky'. It's not on the Interent though. Does the 'host' 'stinky' exist? Assume that I can't control the DNS server--I need to have this code run in any (*ix) environment. Assume also that I don't want to run around specialcasing specific IP addresses or TLDs--this needs to work reliably no matter what the domain. User gives me a string, and I need to see if the given host is a real machine. How would you do this before? Does an A record for a hostname mean that a host with that name exists? If so, then all *.com 'hosts' now 'exist'. If not, what did you mean by exist before? An answer from Verisign would be most appropriate here, since they have done extensive research on the impact of their new service, so presumably they figured out the answer to this problem and have code samples available for distribution. However I get the feeling from their press releases that they've forgotten there is more to the internet than just the web. Forgive me for defending Verisign, but if you want to know if a given DNS name corresponds with an A record, you can still determine that. If you want to determine something else, you can still do that, depending upon what that something else is. As for 'fsck.de', a good argument can be made that this is not really a legal domain. It's a host. Checking for an SOA is a good way to tell if a domain is valid, depending upon what you mean by 'domain' and 'valid'. I'm reminded of the classic programmers question, how do you tell if a machine is online?. The answer is define what you mean by a machine being online and test for that. So you aren't asking a comprehensible question yet. DS
Follow up to: [Fwd: monkeys.dom UPL DNSBL being DDOSed to death]
Hi all, Sorry people I had forgotten about EasyNet.nl's proxy list (Wirehub) and for the record for a proxy spam blocker I don't rate the opm. Yours Matthew
Re: Detecting a non-existent domain
On Tue, Sep 23, 2003 at 03:15:06PM -0700, David Schwartz wrote: As for 'fsck.de', a good argument can be made that this is not really a legal domain. It's a perfectly valid domain registered with DE-NIC. DE-NIC offers two types of domains: delegated and so-called MX-only domains, where up to five (IIRC) RRs reside directly in the TLD zone file. Do a whois lookup on whois.denic.de for fsck.de to see how this looks like. It's a host. Checking for an SOA is a good way to tell if a domain is valid, depending upon what you mean by 'domain' and 'valid'. Your definition of domain is too narrow. A valid domain in common context is a registered second level DNS label. It has no implication on what is technically being done with this label. Some NICs like DE-NIC impose restrictions upon registration though (domain has to be delegated to a working and configured set of NSses or be a MX-only domain). Regards, Daniel
Re: Detecting a non-existent domain
On Tuesday, Sep 23, 2003, at 18:15 Canada/Eastern, David Schwartz wrote: As for 'fsck.de', a good argument can be made that this is not really a legal domain. It's a host. Checking for an SOA is a good way to tell if a domain is valid, depending upon what you mean by 'domain' and 'valid'. Are you sure you are not confusing the terms domain and zone?
Re[2]: monkeys.dom UPL being DDOSed to death
On Tue, 23 Sep 2003 18:12:11 -0400 (EDT) [EMAIL PROTECTED] wrote: These will, of course, get out of date and out of sync almost immediately. one wonders how many private blocking lists still have the old aegis netblocks in them. i make it a point to date entries in my lists and periodically purge older entries that don't seem to be active spam sources anymore, but most do not, i'm afraid. if the well run BLs are run underground or shutdown, this will ultimately lead to exactly what jon fears -- an IP space full of random, unusable superfund sites. cheers, richard -- Richard Welty [EMAIL PROTECTED] Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Re: Foundry BigIron series
Here are the responses I got so far, trimmed and edited. Thanks once again - I got way more than I bargained for in the way of responses. I did also receive a response directly from someone at Foundry, (with at least one of the expected emails from $SALES_DROID at $COMPETITOR). Sorry for the super long post (about 22k so far) - I've tried to trim as much as possible (if you respond to this post, PLEASE don't fullquote the entire message). Hopefully this won't start any flamewars! I didn't say any of this stuff, so please don't write me telling me that I'm wrong or asking who wrote a particular comment. From what I can tell, it sounds like the newer JetCore based stuff is much less problematic than the Ironcore stuff. Overall, sounds like the CLI is fairly easy to adapt to for someone who has experience with Cisco gear. Definitely some complaints about the BGP implementation; hard to tell whether those issues are resolved with newer hardware / software. *** Then take Juniper! Foundry is crap, seriously. [ And a followup, after request for a more specific answer ] Foundry is crap, its end of life stuff. They wont support Ipv6 in hardware and certainly dont do things wirespeed. Besides that, take a look on some internet exchanges. For example ams-ix, allmost ZERO foundrys left, they just dont fit the BGP stuff. Most people allready replaced them with either a cisco or a juniper. We have several Junipers running, and LOVE them. We also have three foundry's and they go oput end this year, and i am happy to replace them. They just die with the numer of users and traffic we push in those boxes. And its not THAT much (70.000 customers and 1.5 GB traffic). Cisco is ok also, we use a couple of 6509s and several 7206VXRs but if you want to do serious BGP and move real traffic, go for Junipers, rock solid and cheaper then cisco also. *** You're insane; use the cat 6500. [ And a followup, after requesting more information ] We USED Foundry, but the BGP implementation was horribly broken. *** We built a BGP network using them where I worked in 1999 to 2000 or so. Aside from various problems they had on their WAN links we had a bunch of BGP problems, relating to memory allocation and the like. I wound up filtering routes between all my sites (as I had the same upstream from each). At the time they didn't follow the BGP rfc closely, skipping things like closest IGP hop to use router id as a rotue selection criteria. Shortly after I left they demoted them to layer 2 switches and they put int junipers. I might have some concerns regarding their ability to handle DoS attacks a la Extreme. Who knows, they may have gotten the kinks out and they sure where cheap but my experience was far from perfect. Hope that helps, *** Just my experience. The interface ie command line is of course almost exactly the same so you'll have no trouble if you know cisco. Where I had problems is the particular bigiron I was working with would lock up hard under higher loads say 600 to 800 megabits on a gig. I'm not sure if it was load specific as the customer using the box was always under high load but it was known to lock up periodically. I had a 6509 and it only locked once as the result of what turned out to a be a counter growing to large. *** We use Foundry and Riverstone boxes to run our ISP and have wonderful success with them...the Riverstone CLI is a bit unwieldy, but the hardware rocks. But we mainly use foundry big iron and net iron boxes at the core, and for the most part they are great. Foundry's tech support is also first class, and you just can't beat the speed. *** Stay away from Riverstone. My upstream (GNAPS) just dumped them all...majorly unstable and they take forever to reboot when they crash. They switched to junipers (got a bunch of M20s used) and it's been rock solid since! *** We use Foundry here and are switching to a combination of Foundry and Juniper to meet our needs. The main recommendation I have is to avoid the Ironcore-based products (older stuff) and go with the newer, Jetcore-based products. The older stuff does not support Netflow nor Sflow, and a few other BGP features that are really must-have in my opinion. *** I would advise against it. I had some pretty extensive experience with this platform running a content network I left about 4 months ago. Some of the software implementations on their newer hardware may be better, but the BI4000 code we were running (their semi-latest) was totally bug ridden. Their BGP implmentation was not at all stable and their OSPF wasn't much better. They would drop routes for no reason and it would require kicking BGP or OSPF to fix the problem. In some cases removing it from the config and re-applying it. The boxes would randomly reload when applying an ACL change but with no consistancy. We also had a lot of bad luck with their hardware, we had a lot of the optics go bad on their Gig
Re: [Fwd: monkeys.dom UPL DNSBL being DDOSed to death]
[EMAIL PROTECTED] (Matthew Sullivan) writes: ... That leave 2 proxy DNSbls left - SORBS and DSBL... well, and, there's the MAPS OPL, which is also part of the RBL+. (just 'cuz i'm not operationally involved with maps doesn't mean i stopped subscribing.) -- Paul Vixie
Re: Verisign Responds
It's still to be seen if ISC's cure is worse than the disease; as instead of detecting and stoping wildcard sets, it looks for delegation. that's because wildcard (synthesized) responses do not look different on the wire, and looking for a specific A RR that can be changed every day or even loadbalanced through four /16's that may have real hosts in them seems like the wrong way forward. -- Paul Vixie
Re: monkeys.dom UPL being DDOSed to death
--On Tuesday, September 23, 2003 6:11 PM -0400 Kai Schlichting [EMAIL PROTECTED] wrote: - BGP anycast, ideally suited for such forwarding proxies. Anyone here feeling very adapt with BGP anycast (I don't) for the purpose of running such a service? This is a solution that has to be suggested and explained to some of the DNSBL operators. Anyone want to offer hardware, colo, bandwidth and a bgp session for a dnsbl anycast solution?
Re: monkeys.dom UPL being DDOSed to death
On Tue, 23 Sep 2003, John Payne wrote: --On Tuesday, September 23, 2003 6:11 PM -0400 Kai Schlichting [EMAIL PROTECTED] wrote: - BGP anycast, ideally suited for such forwarding proxies. Anyone here feeling very adapt with BGP anycast (I don't) for the purpose of running such a service? This is a solution that has to be suggested and explained to some of the DNSBL operators. Anyone want to offer hardware, colo, bandwidth and a bgp session for a dnsbl anycast solution? they still make static targets for ddos, the only difference is theres a few more of them. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Re: monkeys.dom UPL being DDOSed to death
--On Tuesday, September 23, 2003 4:56 PM -0700 Dan Hollis [EMAIL PROTECTED] wrote: On Tue, 23 Sep 2003, John Payne wrote: --On Tuesday, September 23, 2003 6:11 PM -0400 Kai Schlichting [EMAIL PROTECTED] wrote: - BGP anycast, ideally suited for such forwarding proxies. Anyone here feeling very adapt with BGP anycast (I don't) for the purpose of running such a service? This is a solution that has to be suggested and explained to some of the DNSBL operators. Anyone want to offer hardware, colo, bandwidth and a bgp session for a dnsbl anycast solution? they still make static targets for ddos, the only difference is theres a few more of them. Yep
RE: Detecting a non-existent domain
At 3:15 PM -0700 9/23/03, David Schwartz wrote: How would you do this before? Does an A record for a hostname mean that a host with that name exists? If so, then all *.com 'hosts' now 'exist'. If not, what did you mean by exist before? Okay, let's be very specific. I need to know if a given name has either A or MX records which are *not* the same as those provided by the a wildcard in the appropriate TLD. The answer so far seems to be to query *.TLD, nab all the records, and then compare them all the results you get back from querying the domain. If there is anything that doesn't match, you are in the clear. (Modulo internal networks and localhost and all those fun tricks of course--but that's a different problem.) The fact that this is a single IP comparison with Verisign today presumably does not preclude the wonders of MX records, CNAME's, multiple A records and all of that in the future. -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
RE: Detecting a non-existent domain
At 3:15 PM -0700 9/23/03, David Schwartz wrote: How would you do this before? Does an A record for a hostname mean that a host with that name exists? If so, then all *.com 'hosts' now 'exist'. If not, what did you mean by exist before? Okay, let's be very specific. I need to know if a given name has either A or MX records which are *not* the same as those provided by the a wildcard in the appropriate TLD. Okay, but what does that have to do with Verisign? That question would apply to .museum as well, for example. It also applies equally to lower-level domain. It's not Verisign's fault that DNS doesn't provide any 'wildcard' flag in its responses. If we're going to challenge Verisign, we should be very careful to precisely phrase our queries so that Verisign has no wiggle room. For example, I suggest, If I don't like SiteFinder, don't agree to its terms, and don't want to use it, or if I can't comply with its terms because my usage is commercial, how do I avoid it? DS
Lucent/Avaya Cajun experiences
This request is largely for anecdotal/historical purposes. The recent Foundry/Riverstone posts reminded me of a topic I'd kept meaning to broach. My organization will probably be replacing all of our L2/L3 Lucent/Avaya Cajun switches in the next few months with Catalyst 65XX series boxes. Our experience has largely been disastrous - 3 operational years have been filled with _constant_ HW and SW failures, buggy code (i.e. backplane suddenly stops all traffic forwarding), horrible tech support, lousy online resources (a la SW releases). Their M770 ATM gear hasn't been much better, and their PacketStar media gateways are still, surprisingly, limping along. Anyone care to share their own Lucent/Avaya experiences? Please feel free to reply off-list and I will provide an anonymous summary. Thanks. --- Andy Grosser, CCNP [EMAIL PROTECTED] ---
Re: monkeys.dom UPL being DDOSed to death
Ron, good luck with it. You're stuck between a rock and a hard place. If you down it the kiddies win again, and will feel they can bully the next guy. If you don't your network is crippled. It's a no win situation. If any of the dos'ed to death rbls really want's to get back at the spammers it's easy. Write software that allows any ISP or business to use their mail servers and their customers/employees (via a foward to address) to maintain their own highly dynamic blacklist. Blacklists are just one kind of filter. If we could load software that allowed us to forward spams caught by other filters into it and it maintained a DNS blacklist we could have our servers use, we wouldn't need big public rbl's, everyone doing any kind of mail volume could easily run their own IF THE SOFTWARE WAS AVAILABLE. A distributed solution for a distributed problem. Resistance is NOT futile. Geo.
New CA Law
Word is Gray Davis signed this law, http://info.sen.ca.gov/pub/bill/sen/sb_0151-0200/sb_186_bill_20030911_enrolled.html today. It seems to be a pretty strong anti-spam bill. Given all the talk of black lists and DDOS's and the like does anyone think this will make a difference? Is anyone planning on using the law to recover damages? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: New CA Law
Hi Leo, #Word is Gray Davis signed this law, #http://info.sen.ca.gov/pub/bill/sen/sb_0151-0200/ #sb_186_bill_20030911_enrolled.html today. It seems to be a pretty #strong anti-spam bill. Given all the talk of black lists and DDOS's #and the like does anyone think this will make a difference? Is #anyone planning on using the law to recover damages? Likewise, Oregon passed (and our Governor signed) SB910 http://www.leg.state.or.us/03reg/measures/sb0900.dir/sb0910.en.html which includes a right of private action with $500 per spam penalties [in the case of spam which Misrepresents or hinders a person from determining the point of origin or transmission path of the electronic mail message] among other nice provisions. Electronic mail service providers also acquire new rights of action, and some interesting immunities. All that's needed now is litigation support software that can ingest spam submissions, aggregate and summarize appropriately, do automated whois lookups and deobfuscation, and produce digestified ready-to-litigate spam packages for interested attorneys. Regards, Joe
Re: monkeys.dom UPL being DDOSed to death
On Tue, 23 Sep 2003, Geo. wrote: If any of the dos'ed to death rbls really want's to get back at the spammers it's easy. Write software that allows any ISP or business to use their mail servers and their customers/employees (via a foward to address) to maintain their own highly dynamic blacklist. Already been done. http://spamikaze.nl.linux.org/ -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
