Although the Russians don't like it, I though it was "unoficially" names Space Station Alpha (although wasn't Alpha used in the Space 1999 brit-import sci-fi series).
It is not acceptible design for a device with a part that will wear out during the useful life of the device not having that part serviceable. This is as bad as the old V-8 Mustang-IIs that required the engine be dropped to replace the back two spark plugs. Even the game boy advance has a user replaceable battery (albeit behind a screw).
While Apple might not be guilty of any crime in their handling of this, they are definately guilty of:
o Very poor design
o Very poor handing of the problem.
Apple relies on very high customer satisfaction to justify their premium products. This type of incident does not bode well.
In one sense, hacking a virtual is as good as hacking the real thing. On the other hand, hacking a virtual is quite dangerous on the part of the hacker.
UML virtuals have the ability to log a bunch of stuff "outside" the virtual. This can include keystroke logging on devices (including the pty's that ssh allocates). Plus you have a 100% sniffable network from the outside and the "owner" of the UML can "give" the virtual to the hacker at almost no cost and watch and learn.
If you are concerned about a hacker launching a DDOS using your virtual, this can happen, but you can also stop or mitigate it without tipping your hand against the hacker. You can firewall the virtual from the host side and silently block all (or most) of the attacking packets. You can even rate-limit the damage that they can do with 'tc'.
The amazing thing about getting a UML hacked is that most hackers don't even realize they are being watched. While/proc/cpuinfo and a bunch of device setups are unique to UML, most hackers have no clue and trudge on blindly. If you want to be more "stealthy" and setup a honeypot, the honeypot/proc and/dev filesystems change all the names to match a "normal" physical server. If your purpose is a "honeypot", you will probably need to only run a single UML with enough memory to seem realistic. Even then, if the hacker knows the internals of Linux, he can tell, altough it might require writing/loading a kernel module to see that the address space is not quite right.
UML has a number of differences when compared to chroot environments.
Resource usage is higher because less is shared.
Each virtual needs a real network, and usually a real public IP
Network configuration can become nightmareish as the number of virtuals
grows unless you write some signifigant config scripts that run dynamically.
You really need a good understanding of networking and especially routing
and how ARP works. The docs on the UML site are correct, but they only scratch
the surface.
You still have to secure the virtual on the host system. This usually involves
running UML as non-root inside of a chroot jail that is as sparsly populated
as possible.
You will want the SKAS patch.
With the SKAS patch, you will need a/proc in your chroot jail. Look
at mount --bind to just mount/proc/cpuinfo and/proc/mm
On the other hand, UML is good enough to fool even the hackers (I have had
UMLs hacked and the hacker didn't realize they were in a virtual).
We run public webservers, and mailservers on UML. We are at the point where
we just assume that you use one UML per application. The manageability of running
single-application servers is just too good to pass up.
Hopefully, the do not call list will not be a "downloadable" list, but instead use some sort of DNS lookup. I would hate to have the list used as a source list for emails that aren't spam.
And if you think that all unsolicited emails are spam, I am sure the definition included is unsolicited commercial email. This means that political parties, disenchanged PETA activists, local PTAs, pseudo for-profit charatible? (think auto donations) organizations, etc. would love a large free list of good email addresses.
The alternative to ban all unsolicited email probably would not pass constitutional muster and I am not 100% sure that cure would be "better" than the problem.
I have setup a mirror here which includes the NERC report.
The PDF is about 4.4 Meg and the NERC site has been well/.ed
Novell Officially Replies to SCO "Non-compete"
on
SCO News Roundup
·
· Score: 3, Interesting
In a press release here
Novell basically says "fuck off".
Novell Statement on SCO claims regarding a non-compete clause in Novell-SCO
contracts
PROVO, Utah Nov. 18, 2003 Novell has seen the November 18 InfoWorld
article in which SCO CEO Darl McBride refers to a supposed non-compete agreement
between Novell and SCO. Mr. McBride's characterization of the agreements between
Novell and SCO is inaccurate. There is no non-compete provision in those contracts,
and the pending acquisition of SUSE LINUX does not violate any agreement between
Novell and SCO.
Novell has received no formal communication from SCO on this particular issue.
Novell understands its rights under the contracts very well, and will respond
in due course should SCO choose to formally pursue this issue.
I was curios so I asked a Cox support person on chat what was blocked. They have a page published on this. You can get there by searching for "blocked" on their FAQ.
I see a couple of ports in your list that are not in theirs, so the FAQ may be a little out of date.
In general, I would love to see a "control panel" that let you set this up yourself (instead of making it global), but there choices are not unreasonable on the surface. They also appears to be full disclosure here, so I would compliment Cox in this area.
Here is a cut-and-paste of their FAQ.
What ports do you block?
Answer:
Reasons For Filtering Ports
Protecting our customers - Certain ports are filtered in order to protect our customers. We can protect them from certain common worms and protect them from running dangerous services on their computers that could allow intruders access. Protecting our upstream bandwidth - Upstream bandwidth to a cable plant is limited. If customers over utilize their upstream bandwidth by running high-traffic servers or becoming infected with a worm or virus, it can degrade the service of other customers on their node. Protecting the rest of the Internet - Some filters prevent our customers from attacking other computers on the Internet. In addition to being in our best interests for protecting our bandwidth, it is our duty as good Netizens to prevent abuse of our network.
Port Transport Protocol Direction Reason for Filtering 25 TCP SMTP Both* SMTP Relays 80 TCP HTTP Inbound Web servers, worms 135 UDP NetBios Both Net Send Spam/Pop-ups, Worms 136-139 UDP, TCP NetBios Both Worms, Network Neighhood 445 TCP MS-DS/NetBios Both Worms, Network Neighhood 1433 TCP MS-SQL Inbound Worms, Trojans 1434 UDP MS-SQL Inbound Worms, SQLslammer 1900 UDP MS-DS/NetBios Both Worms, Network Neighhood 27374 TCP Subseven Both SubSeven Trojan
*SMTP is only permitted outbound to Cox-provided SMTP servers
Detailed Explanations Of Filtered Ports
25/TCP - SMTP. SMTP stands for Simple Mail Transport Protocol. This is the protocol that mail servers use to exchange email. We block this in order to protect upstream bandwidth and prevent customers from running open relays could potentially be used by others to send spam via our network.
80/TCP - HTTP. HTTP stands for Hypertext Transport Protocol. This is the protocol web browsers use to communicate with web servers. In addition to protecting bandwidth by preventing customers from running high-traffic web servers, we can stop many destructive worms that spread via security holes in web server software.
135,137/UDP, 135,139/TCP, 445 MS-DC - NetBIOS. NetBIOS (also known as Server Message Block, LanManager, and Common Internet File System) is a networked file sharing protocol. The Microsoft Windows "Network Neighborhood" runs over NetBIOS. We filter this port to protect customers from inadvertently exposing files on their computers, and also to block worms which spread via open file shares. The latest addition to this series, a consolidated service port (TCP445), has also opened new (yet similar) security risks in Win2K and WinXP.
1433/TCP, 1434/UDP - MS-SQL. Microsoft SQL Server (and software designed with SQL Server components) is a database application with a long history of security exploits, and is noted for the propagation of the SQLslammer worm. These ports are filtered to prevent exploitation and propagation of MS-SQL exploits.
1900/UDP - UPnP discovery/SSDP, is a service that runs by default on WinXP, and creates an immediately exploitable security vulnerability for any network-connected system. Filtering this port proactively prevents XP systems from being remotely compromised by malicious worms or intruders.
27374/TCP - SubSeven. SubSeven is a common trojan. When installed on a victim's computer, it allows an attacker to remote control it over the Internet. SubSeven can be configured to run on any port - not just 27374 - but blocking this port at least provides our customers some protection and prevents our customers from attacking others on the default port.
Many ISPs don't want home user to run servers or services that are
not traditionally considered a part of the home internet experience.
Some of the restrictions in the AUPs can get pretty ugly. Here are a couple of
examples:
Some don't let you run tunnels to telecommute and run office applications
remotely.
Most don't let you run public servers like web, email, ftp,
etc.
There are a couple of justifications for this. Some are probably more realistic
than others.
They want to sell you a more expensive business account
They want to prune out the high-volume users that burn a lot of bandwidth
They want to avoid the DCMA requests for takedowns and other
legal (both real and imagined) stuff.
They are really trying to reduce spam
They assume they know more about what you need than you do
My cable-modem ISP (Cox) blocks outbound 25. This is a minor only a minor issue
to me because Cox's outbound mail servers are generally:
Reasonably reliable
Don't mind my sending mail using my domain names
I receive mail with co-lo servers that are part of my business.
The comment of not trusting outbound relaying because they might
look at it is a bit misplaced. Looking at internet traffic is pretty
easy for anyone with the desire and means to do so.
If you send outbound SMTP on your cable modem, your ISP can look at the packets
if they have the desire to do so (and I doubt that this breaks any
laws). It does not really matter if they relay the traffic or not. They have
physical access to the network, so they can sniff either way. On the other hand,
they are pretty unlikely to do so unless they are asked by some governmental
agency. Basically, sniffing such large amounts of data is uninteresting to them,
so why would they bother. If you are worried about eavesdropping on email, encrypt.
In your case, I suspect that the blocks have two reasons:
Inbound blocks to 25 are just an enforcement to a no servers rule.
I suspect that there are also blocks on 80 and perhpas a bunch of others. In
all fairness, I would hate to run a mail server in-house on a cable modem. Mail
is just too important to me, and I don't trust my in-house systems to be up
24x7. That is what co-lo is for.
Outbound blocks to 25 are an attempt to slow down spam. Specifically, they
prevent hacked home systems from becoming SMTP relays. In general, this is probably
a good thing and most users with hacked boxes never know the damage they are
doing.
Your only real solutions that you have are:
Convince your ISP to open the ports up. They probably won't do this.
Use your ISP's mail server and pull messages from it with POP/IMAP or similar
Switch ISPs, perhaps to a business-type account with static IPs and no filtering
Use an outside mail server that does not have these restrictions.
None of these are 100% free or pretty, but the bottom line is that you are
using your cable-modem line in a manner that doesn't fit your provider's pre-conceived
image of the type of user they have/want.
On the other hand, the solutions above are not necessarily that expensive either.
You can get email hosting with adequate access for <$10/mo, co-lo virtual
servers for <$15/mo, and full dedicated co-lo servers for <$100/mo.
Hopefully, Hollywood will recognize the "mob" (ie. organized crime) when they see it.
--- Posting from Yesterday follows ---
Paul Murphy at E Commerce Times
http://www.ecommercetimes.com/perl/story/31932.htm l
has an absolutely insane article about this whole mess. Mind you, 98% of the article is completely nuts as it basically blames IBM, or anyone else, for not paying off SCO already. He does not understand that paying off the mob is bad social policy and that Linux is about social policy, but I digress.
Here is one interesting part:
- - - # SCO is attacking the entire Linux community.
It is not. Responses from SuSE Latest News about SuSE and Red Hat to the contrary, the SCO demand for license fees from Linux users was classic legal fiction. Both key SCO executives -- Darl McBride and Chris Sontag -- have said repeatedly that they are trying to work through issues to achieve justice without putting "a hole in the head of the penguin."
Most people find these license claims outrageous, but think about the drivers behind the demand and you might yet see SCO as a victim of its own lawyers and the way the courts operate.
Fundamentally, the court eventually will require SCO to show a quantitative, market-based derivation for the value of damages claimed. Demanding license fees is one way of establishing that basis -- and one likely to appeal to lawyers acting on contingency because a few successful sales would suffice to establish an enormous fair-market value. - - -
Terrifyingly, this almost makes sense. If SCO can set a "high" license value on their property, they can then multiply this by the number of Linux systems to get their damages. It only takes a couple of bozos (or co-conspirators) to create "license sales" that can then be multiplied out. This is not too disimilar from the RIAA / WebCasting royalty calculations. Take what Yahoo will pay during the bubble, and then try to get everyone else to empty their pockets. It is very likely that they are not trying to actually get licenses, but that they are trying to establish a "market value" that is to their favor.
If this is actually their plan, then it is not only SCO that needs taken down, but their lawyers as well.
http://www.ecommercetimes.com/perl/story/31932.htm l
has an absolutely insane article about this whole mess. Mind you, 98% of the article is completely nuts as it basically blames IBM, or anyone else, for not paying off SCO already. He does not understand that paying off the mob is bad social policy and that Linux is about social policy, but I digress.
Here is one interesting part:
- - - # SCO is attacking the entire Linux community.
It is not. Responses from SuSE Latest News about SuSE and Red Hat to the contrary, the SCO demand for license fees from Linux users was classic legal fiction. Both key SCO executives -- Darl McBride and Chris Sontag -- have said repeatedly that they are trying to work through issues to achieve justice without putting "a hole in the head of the penguin."
Most people find these license claims outrageous, but think about the drivers behind the demand and you might yet see SCO as a victim of its own lawyers and the way the courts operate.
Fundamentally, the court eventually will require SCO to show a quantitative, market-based derivation for the value of damages claimed. Demanding license fees is one way of establishing that basis -- and one likely to appeal to lawyers acting on contingency because a few successful sales would suffice to establish an enormous fair-market value. - - -
Terrifyingly, this almost makes sense. If SCO can set a "high" license value on their property, they can then multiply this by the number of Linux systems to get their damages. It only takes a couple of bozos (or co-conspirators) to create "license sales" that can then be multiplied out. This is not too disimilar from the RIAA / WebCasting royalty calculations. Take what Yahoo will pay during the bubble, and then try to get everyone else to empty their pockets. It is very likely that they are not trying to actually get licenses, but that they are trying to establish a "market value" that is to their favor.
If this is actually their plan, then it is not only SCO that needs taken down, but their lawyers as well.
I had a couple of telephone calls that ***really*** had fallouts yesterday morning. Land line and everything.
There is a "non zero" chance that they were telling the truth. On the other hand it is far more likely that they just did not want to take the tech support call.
I will try not to advertise too much here, but you should try to run your servers at a hosting facility that offers low-cost virtual servers. My company does this starting at $150/year including 3Gig of disk and 10Gig of transfer running "User Mode Linux" w/ RedHat 7.3. We are not alone and there are a number of vendors that can give you small "dedicated" servers for much less than $50/month.
There are two "classes" of virtual servers. Companies that offer shared hosting, and companies that offer true "virtual" server. With shared hosting, you don't really have the flexibility of a whole machine. With virtual servers, you get ssh root access into a Linux or BSD system and can load your own packages etc.
The User Mode Linux based servers work very well and are really complete servers with their own dedicated file system, network, and RAM. Other than being small (32Meg of RAM, 32Meg of SWAP, and 3G of disk) that are 100% complete systems running 2.4.22 with gcc, emacs, vi, perl, php, apache, bind,... Plus you can load anything else you want.
Our servers are 100% open sitting on dedicated 100Mbit lines with truely public and unfiltered IP addresses. We pre-configure iptables based firewalls, but you can open up whatever you wish.
The downside of true "virtual" servers versus shared hosting accounts is that you have to configure the software yourself. If you don't know how to setup apache and bind, then a complete server is probably not a good idea.
The bottom line is that this lets you use any old DSL/Cable modem line and still have your 100% accessible server on the net.
A lawyer representing the Free Software Foundation (FSF) disputed SCO's claims that the FSF is the only organization with the necessary legal standing to launch a GPL-based lawsuit. Since IBM holds the copyright to much of the Linux kernel software that is distributed under the GPL license, it has every right to enforce the GPL, he argued.
"The proper enforcer of a copyright is the copyright holder," said Eben Moglen, general counsel for the FSF. "IBM says, 'You're using a copyrighted work of ours in a fashion which is prohibited by the Copyright Act, and you're doing so without our permission. You owe us damages and you must stop.'"
1. If you are doing this for internet based servers, you might well be better off colocating your servers in a commercial data center. The cost of doing this is a lot less than it used to be and is likely less than doing it yourself. This might not be the solution for all of your systems, but may be appropriate for many.
2. You will need a lot more power than you think. Most "single/dual" cpu servers are 3-4 amps each. If you load up a rack with 1U servers, this can easily require 4 20amp circuits. UPS ratings are also in VA which is less than watts, so a 3KVA UPS is required for a 20amp circuit.
2a. Professionally install your power. Conduit and "lots" of plugs are approrpiate. 20A plugs are usually not necessary (the ones with the sideways prongs).
3. If you overload your UPS, there are two side effects. If you are only close, you just lose backup run-time. If you actually go over, then the servers all shutdown, rudely. It does not really matter what kind of servers you have in this case as the UPS itself will usually take everything to zero.
3a. Do you have a generator. If not, then the UPS will become very expensive to get any type of real run-time.
4. It sounds like you have a bit of an airflow issue. If you are using enclosed racks and have no need for rack "security", take the doors and sides off completely. If you need to lock the racks, then get perforated fronts and mount several 8-inch fans thru the back doors to blow air. You also need to get the air moving around the room. Some high-quality fans up high might move things around enough.
4a. If you are in a "seismic" area (like I am in California), be sure to bolt everything down. Even if your datacenter goes down during a 6.5, you will be less likely to kill someone.
4b. Pay attention to fire control. Sprinklers are "bad", but sometimes required. Haylon is more desireable, but often water is required anyway.
5. Buy equipment used if you can. Things like racks etc. are plentiful from failed co-los.
6. Remember remote management. You might not need managed switches, but remote power controllers are really nice. We use stuff from BayTech because it does both AC and serial. Other solutions are available from APC, etc. A lot of this stuff is also available used (ebay) so shop around.
7. If you buy used, consider possible licensing gotcha's. Some vendors have steep software/firmware relicense fees.
Most *nix distributions have a copy of rsync loaded.
In this case you are using rsync directly over tcp/ip connections, sometimes called "daemon mode".
This mode features:
o high-strenght crytpo on passwords, but no encryption of data.
o passwords that are 100% independent of the system passwords.
o 100% streaming, even with large numbers of small files.
o restart of failed transfers where they left off.
o delta transfers for files where only parts change.
o optional gzip style compression.
o plus a lot more neat stuff.
Info on rsync is at:
http://rsync.samba.org
If you have a Linux system with xinetd or equivilent, there is a good change that you already have an/etc/xinetd.d/rsync control record for the daemon. You then need an/etc/rsyncd.conf file plus a "secrets" file to hold the passwords.
rsync directly on top of tcp/ip is how most "mirror sites" sync to their masters. It is about the only "practical" way to send gigabytes over the internet.
A couple of caveats. If stuff is twitchy, try to use the latest version of rsync (2.5.6) on both ends. Also, if you use the --compress option with already compressed (or encrypted data), there is a gziplib boundary bug. There are patches for this, but if you are sending uncompressable data, just leave off the --compress option.
I used to run hybrid servers packing as many function on a single box as practical. The problem here is that it can be tough to manage a mix of many services on a single server.
We have migrated to single application servers running on User-Mode Linux. The only down side here is that you can burn thru a lot of IP addresses, and in that most of our servers are public, it is not the best usage of address space.
In terms of maintenance, virtuals are ideal. You can individually firewall them opening only a few ports, and often only to select destinations. Updates are easily automatable with ssh pushing rpm's to guest systems.
If a system does get compromized, the damage is usually limited. The amazing part is that I have seen hackers in UML virtuals who did not even realize they were not hacked into a "real" system. This is without having "honeypot" mode turned on.
One nice thing about virtuals and single-service boxes is that you can run different software configurations for different applications without worrying about interactions. If SquirrelMail needs a different Apache/PHP version than your primary web server then just run the two in different virtuals. If you need to patch mod_proxy, then you can do it without worrying about killing your shared hosting customers because you only tested it for 15 minutes.
And the best thing about virtuals is that you can lift them up and plop them down on another system with everything 100% intact. Great when systems crash at inconvienient times.
Finally, prototyping a new server now takes a couple of minutes. Just clone an existing virtual, give it an IP address and boot. 15 seconds later, you have a live system. When you are done with it, delete the COW file (Copy-Over-Write block device file) and all signs of your temporary system are gone. It has been so long since I have done a full install, I am not sure I remember how anymore.
I don't want this to sound like an ad, but Virtuals, whether they are UML, Xen (which looks really neat, now would someone please port it's run-time as a LKM), VMWare, full VM, or whatever are just too usefull to ignore.
I have a Cox cable modem at home (along with an SBC DSL line as a backup) and run a hosting business with servers in Philadelphia, Costa Mesa, CA, and Los Angeles.
We are constantly looking for the right mix of rules to deal with spam. We don't want to interfere with our customers businesses, but we don't want to be the source of spam as well.
We have implemented a number of items to try to "play well" and give our customers the service they need.
Shared hosting customers get send after read SMTP privilidges. This is pretty standard with POP3/IMAP servers. We further limit the outbound rate to about 2 seconds a destination address just to keep people from getting cute. For those that are behind funny firewalls (like Cox), we run an outbound SMTP server on 8025. All in all, this seems to work pretty well.
I am not 100% sure how the SPF stuff would impact us. For the domains we manage, we could easily automate the DNS updates. The issue is for users that want to run our server but that we don't actually run the DNS servers for. I would love to see a "delegate" record in the spec to send the query somewhere else (maybe a CNAME would actually work, but it is late and my brain does not do that type of DNS right now).
For our "server" customers, our approach is a bit different. If you are buying a dedicated server in a co-lo, you have an expectation of being able to talk to the "net" without interference. We also believe that we dont have a lot of justification in "spying" on what our customers are doing. On the other hard, we don't want to be surprised when a customer sends out 50G of spam. About the only "solution" we could come up with is transfer logging the packets that are going to port 25 outbound (fortunately, IPTABLES does this very well). This way we will hopefully see an abuser before they get us in trouble with the BH lists.
All in all, the SPF stuff looks like it needs a bit more discussion before diving in. Also, if the outcome is just a new set of tricks that the spammers play then I am not sure if it is worth it.
The BIND patch is very simple and elegant. It relies on the particular technical method that Verisign used to implement their wildcard responses. But we can make some assumptions here.
If Verisign truely believe they have the "right" to do whatever they want to do with the root zone files, they can easily circumvent the patch.
One design that they might try is to take the inbound domain name, hash it, take a modulo of the hash and create a "fake" SOA and NS for that domain name on a unique IP address. With a pool of only several thousand real IP addresses they could create what looks like 100% real zones for everything. They could even send the traffic to one of many different IP addresses. This could be an arms race that never ends.
The only "real" solution is that the root zone files must be "trusted".
If Verisign refuses to change their behaviour then one of several things must happen.
o ICANN / IANA must force them to
o DOC must force them to
o Private lawsuits must force them to
o State AGs must force them to
o Everying must blackhole "ALL" Verisign owned IP addresses and effectively take them off of the net.
RedHat has fixes (source and binaries) on their FTP site and docs in the erratta pages.
https://rhn.redhat.com/errata/RHSA-2003-279.html
For RedHat 7.1: openssh-3.1p1-9 For RedHat 7.2: openssh-3.1p1-10 For RedHat 7.3: openssh-3.1p1-10 For RedHat 8.0: openssh-3.4p1-5 For REdHat 9 : openssh-3.5p1-9
Good luck at getting to their FTP servers. Hopefully, the mirrors will get them soon.
If this only impacted browsers, this would not be so bad. The problem is that it impacts a bunch of other stuff. And at the bottom of it all, the reply from the root servers is a "LIE".
Verisign thinks that it "owns" the.com and.net domains. That it is their property and that they can do whatever they want with it. I have news for them. As a US Citizen, I own the.com and.net domains thru my elected government. I know this is naive, but corporations need some ethics and monopolies need regulation.
Complain loud and often. Via email, fax, phone, letter, or script. This cannot stand.
I think we should all call tech support on their 800 number and complain.
U.S. and Canada: 888-642-9675
Worldwide: 1-703-742-0914
Lets see if we can get their hold queue time to several hours. Perhaps even ask to speak to a supervisor. Be sure to get names of everyone you talk to. Ask for names and phone number of the corporate officers. Compare them to SCO (ok, a bit off topic but I couldn't resist).
To: icann@icann.org, iana@iana.org, nstld@verisign-grs.com,
rcc@verisign.com, hostmaster@nsiregistry.net, ir@verisign.com,
dcpolicy@verisign.com Subject: Complaint about Versign abuse of DNS root zones
A Letter of Complaint about actions undertaken by Verisign Incorporated on or about 9/13/03.
Sent to the Internet Corporation of Assigned Names and Numbers and the Internet Assigned Number Authority.
Doug Dumitru xxxxx xxxxxx xxxx Road xxxxxx xxxxxx, CA 9xxxx 949 xxx-xxxx
Dear sirs,
As you are probably aware, Verisign is redirecting unregistered 2nd-level domains in the.com and.net TLDs to a Verisign owned search engine. They are using a technique known as DNS wildcarding to accomplish this.
I firmly believe that this is clearly an abuse of the DNS system, that it violates the technical requirements for domain lookups, that the results returned are fraudulent, and that this technical action only benefits Verisign at the expense of the rest of the internet population.
I respectfully request that IANA and ICANN immediately take action against Verisign demanding that Verisign cease this fraudulent and damaging behaviour. Should Verisign refuse, I would recommend that IANA and/or ICANN (and/or the US government) take immediate action to revoke Verisign's contract to administer the.com and.net TLDs.
I would also recommend that IANA and/or ICANN immediately pass "best practice" rules that prevent other TLDs and country-code domains from following in Verisign's deceptive footsteps. It is important that a "domain not found" error not be subverted into an advertising opportunity.
Slashdot Mirror
Although the Russians don't like it, I though it was "unoficially" names Space Station Alpha (although wasn't Alpha used in the Space 1999 brit-import sci-fi series).
It is not acceptible design for a device with a part that will wear out during the useful life of the device not having that part serviceable. This is as bad as the old V-8 Mustang-IIs that required the engine be dropped to replace the back two spark plugs. Even the game boy advance has a user replaceable battery (albeit behind a screw).
While Apple might not be guilty of any crime in their handling of this, they are definately guilty of:
o Very poor design
o Very poor handing of the problem.
Apple relies on very high customer satisfaction to justify their premium products. This type of incident does not bode well.
In one sense, hacking a virtual is as good as hacking the real thing. On the other hand, hacking a virtual is quite dangerous on the part of the hacker.
/proc/cpuinfo and a bunch of device setups are unique to UML, most hackers have no clue and trudge on blindly. If you want to be more "stealthy" and setup a honeypot, the honeypot /proc and /dev filesystems change all the names to match a "normal" physical server. If your purpose is a "honeypot", you will probably need to only run a single UML with enough memory to seem realistic. Even then, if the hacker knows the internals of Linux, he can tell, altough it might require writing/loading a kernel module to see that the address space is not quite right.
UML virtuals have the ability to log a bunch of stuff "outside" the virtual. This can include keystroke logging on devices (including the pty's that ssh allocates). Plus you have a 100% sniffable network from the outside and the "owner" of the UML can "give" the virtual to the hacker at almost no cost and watch and learn.
If you are concerned about a hacker launching a DDOS using your virtual, this can happen, but you can also stop or mitigate it without tipping your hand against the hacker. You can firewall the virtual from the host side and silently block all (or most) of the attacking packets. You can even rate-limit the damage that they can do with 'tc'.
The amazing thing about getting a UML hacked is that most hackers don't even realize they are being watched. While
UML has a number of differences when compared to chroot environments.
On the other hand, UML is good enough to fool even the hackers (I have had UMLs hacked and the hacker didn't realize they were in a virtual).
We run public webservers, and mailservers on UML. We are at the point where we just assume that you use one UML per application. The manageability of running single-application servers is just too good to pass up.
Hopefully, the do not call list will not be a "downloadable" list, but instead use some sort of DNS lookup. I would hate to have the list used as a source list for emails that aren't spam.
And if you think that all unsolicited emails are spam, I am sure the definition included is unsolicited commercial email. This means that political parties, disenchanged PETA activists, local PTAs, pseudo for-profit charatible? (think auto donations) organizations, etc. would love a large free list of good email addresses.
The alternative to ban all unsolicited email probably would not pass constitutional muster and I am not 100% sure that cure would be "better" than the problem.
The PDF is about 4.4 Meg and the NERC site has been well /.ed
Novell Statement on SCO claims regarding a non-compete clause in Novell-SCO contracts
PROVO, Utah Nov. 18, 2003 Novell has seen the November 18 InfoWorld article in which SCO CEO Darl McBride refers to a supposed non-compete agreement between Novell and SCO. Mr. McBride's characterization of the agreements between Novell and SCO is inaccurate. There is no non-compete provision in those contracts, and the pending acquisition of SUSE LINUX does not violate any agreement between Novell and SCO.
Novell has received no formal communication from SCO on this particular issue. Novell understands its rights under the contracts very well, and will respond in due course should SCO choose to formally pursue this issue.
I was curios so I asked a Cox support person on chat what was blocked. They have a page published on this. You can get there by searching for "blocked" on their FAQ.
I see a couple of ports in your list that are not in theirs, so the FAQ may be a little out of date.
In general, I would love to see a "control panel" that let you set this up yourself (instead of making it global), but there choices are not unreasonable on the surface. They also appears to be full disclosure here, so I would compliment Cox in this area.
Here is a cut-and-paste of their FAQ.
What ports do you block?
Answer:
Reasons For Filtering Ports
Protecting our customers - Certain ports are filtered in order to protect our customers. We can protect them from certain common worms and protect them from running dangerous services on their computers that could allow intruders access.
Protecting our upstream bandwidth - Upstream bandwidth to a cable plant is limited. If customers over utilize their upstream bandwidth by running high-traffic servers or becoming infected with a worm or virus, it can degrade the service of other customers on their node.
Protecting the rest of the Internet - Some filters prevent our customers from attacking other computers on the Internet. In addition to being in our best interests for protecting our bandwidth, it is our duty as good Netizens to prevent abuse of our network.
Port Transport Protocol Direction Reason for Filtering
25 TCP SMTP Both* SMTP Relays
80 TCP HTTP Inbound Web servers, worms
135 UDP NetBios Both Net Send Spam/Pop-ups, Worms
136-139 UDP, TCP NetBios Both Worms, Network Neighhood
445 TCP MS-DS/NetBios Both Worms, Network Neighhood
1433 TCP MS-SQL Inbound Worms, Trojans
1434 UDP MS-SQL Inbound Worms, SQLslammer
1900 UDP MS-DS/NetBios Both Worms, Network Neighhood
27374 TCP Subseven Both SubSeven Trojan
*SMTP is only permitted outbound to Cox-provided SMTP servers
Detailed Explanations Of Filtered Ports
25/TCP - SMTP. SMTP stands for Simple Mail Transport Protocol. This is the protocol that mail servers use to exchange email. We block this in order to protect upstream bandwidth and prevent customers from running open relays could potentially be used by others to send spam via our network.
80/TCP - HTTP. HTTP stands for Hypertext Transport Protocol. This is the protocol web browsers use to communicate with web servers. In addition to protecting bandwidth by preventing customers from running high-traffic web servers, we can stop many destructive worms that spread via security holes in web server software.
135,137/UDP, 135,139/TCP, 445 MS-DC - NetBIOS. NetBIOS (also known as Server Message Block, LanManager, and Common Internet File System) is a networked file sharing protocol. The Microsoft Windows "Network Neighborhood" runs over NetBIOS. We filter this port to protect customers from inadvertently exposing files on their computers, and also to block worms which spread via open file shares. The latest addition to this series, a consolidated service port (TCP445), has also opened new (yet similar) security risks in Win2K and WinXP.
1433/TCP, 1434/UDP - MS-SQL. Microsoft SQL Server (and software designed with SQL Server components) is a database application with a long history of security exploits, and is noted for the propagation of the SQLslammer worm. These ports are filtered to prevent exploitation and propagation of MS-SQL exploits.
1900/UDP - UPnP discovery/SSDP, is a service that runs by default on WinXP, and creates an immediately exploitable security vulnerability for any network-connected system. Filtering this port proactively prevents XP systems from being remotely compromised by malicious worms or intruders.
27374/TCP - SubSeven. SubSeven is a common trojan. When installed on a victim's computer, it allows an attacker to remote control it over the Internet. SubSeven can be configured to run on any port - not just 27374 - but blocking this port at least provides our customers some protection and prevents our customers from attacking others on the default port.
There are a couple of justifications for this. Some are probably more realistic than others.
My cable-modem ISP (Cox) blocks outbound 25. This is a minor only a minor issue to me because Cox's outbound mail servers are generally:
I receive mail with co-lo servers that are part of my business.
The comment of not trusting outbound relaying because they might look at it is a bit misplaced. Looking at internet traffic is pretty easy for anyone with the desire and means to do so. If you send outbound SMTP on your cable modem, your ISP can look at the packets if they have the desire to do so (and I doubt that this breaks any laws). It does not really matter if they relay the traffic or not. They have physical access to the network, so they can sniff either way. On the other hand, they are pretty unlikely to do so unless they are asked by some governmental agency. Basically, sniffing such large amounts of data is uninteresting to them, so why would they bother. If you are worried about eavesdropping on email, encrypt.
In your case, I suspect that the blocks have two reasons:
Inbound blocks to 25 are just an enforcement to a no servers rule. I suspect that there are also blocks on 80 and perhpas a bunch of others. In all fairness, I would hate to run a mail server in-house on a cable modem. Mail is just too important to me, and I don't trust my in-house systems to be up 24x7. That is what co-lo is for.
Outbound blocks to 25 are an attempt to slow down spam. Specifically, they prevent hacked home systems from becoming SMTP relays. In general, this is probably a good thing and most users with hacked boxes never know the damage they are doing.
Your only real solutions that you have are:
None of these are 100% free or pretty, but the bottom line is that you are using your cable-modem line in a manner that doesn't fit your provider's pre-conceived image of the type of user they have/want.
On the other hand, the solutions above are not necessarily that expensive either. You can get email hosting with adequate access for <$10/mo, co-lo virtual servers for <$15/mo, and full dedicated co-lo servers for <$100/mo.
This seems to be exactly the tact. I commented on this yesterday:
2 172
m l
http://slashdot.org/comments.pl?sid=85084&cid=742
Hopefully, Hollywood will recognize the "mob" (ie. organized crime) when they see it.
--- Posting from Yesterday follows ---
Paul Murphy at E Commerce Times
http://www.ecommercetimes.com/perl/story/31932.ht
has an absolutely insane article about this whole mess. Mind you, 98% of the article is completely nuts as it basically blames IBM, or anyone else, for not paying off SCO already. He does not understand that paying off the mob is bad social policy and that Linux is about social policy, but I digress.
Here is one interesting part:
- - -
# SCO is attacking the entire Linux community.
It is not. Responses from SuSE Latest News about SuSE and Red Hat to the contrary, the SCO demand for license fees from Linux users was classic legal fiction. Both key SCO executives -- Darl McBride and Chris Sontag -- have said repeatedly that they are trying to work through issues to achieve justice without putting "a hole in the head of the penguin."
Most people find these license claims outrageous, but think about the drivers behind the demand and you might yet see SCO as a victim of its own lawyers and the way the courts operate.
Fundamentally, the court eventually will require SCO to show a quantitative, market-based derivation for the value of damages claimed. Demanding license fees is one way of establishing that basis -- and one likely to appeal to lawyers acting on contingency because a few successful sales would suffice to establish an enormous fair-market value.
- - -
Terrifyingly, this almost makes sense. If SCO can set a "high" license value on their property, they can then multiply this by the number of Linux systems to get their damages. It only takes a couple of bozos (or co-conspirators) to create "license sales" that can then be multiplied out. This is not too disimilar from the RIAA / WebCasting royalty calculations. Take what Yahoo will pay during the bubble, and then try to get everyone else to empty their pockets. It is very likely that they are not trying to actually get licenses, but that they are trying to establish a "market value" that is to their favor.
If this is actually their plan, then it is not only SCO that needs taken down, but their lawyers as well.
Paul Murphy at E Commerce Times
m l
http://www.ecommercetimes.com/perl/story/31932.ht
has an absolutely insane article about this whole mess. Mind you, 98% of the article is completely nuts as it basically blames IBM, or anyone else, for not paying off SCO already. He does not understand that paying off the mob is bad social policy and that Linux is about social policy, but I digress.
Here is one interesting part:
- - -
# SCO is attacking the entire Linux community.
It is not. Responses from SuSE Latest News about SuSE and Red Hat to the contrary, the SCO demand for license fees from Linux users was classic legal fiction. Both key SCO executives -- Darl McBride and Chris Sontag -- have said repeatedly that they are trying to work through issues to achieve justice without putting "a hole in the head of the penguin."
Most people find these license claims outrageous, but think about the drivers behind the demand and you might yet see SCO as a victim of its own lawyers and the way the courts operate.
Fundamentally, the court eventually will require SCO to show a quantitative, market-based derivation for the value of damages claimed. Demanding license fees is one way of establishing that basis -- and one likely to appeal to lawyers acting on contingency because a few successful sales would suffice to establish an enormous fair-market value.
- - -
Terrifyingly, this almost makes sense. If SCO can set a "high" license value on their property, they can then multiply this by the number of Linux systems to get their damages. It only takes a couple of bozos (or co-conspirators) to create "license sales" that can then be multiplied out. This is not too disimilar from the RIAA / WebCasting royalty calculations. Take what Yahoo will pay during the bubble, and then try to get everyone else to empty their pockets. It is very likely that they are not trying to actually get licenses, but that they are trying to establish a "market value" that is to their favor.
If this is actually their plan, then it is not only SCO that needs taken down, but their lawyers as well.
I had a couple of telephone calls that ***really*** had fallouts yesterday morning. Land line and everything.
There is a "non zero" chance that they were telling the truth. On the other hand it is far more likely that they just did not want to take the tech support call.
I will try not to advertise too much here, but you should try to run your servers at a hosting facility that offers low-cost virtual servers. My company does this starting at $150/year including 3Gig of disk and 10Gig of transfer running "User Mode Linux" w/ RedHat 7.3. We are not alone and there are a number of vendors that can give you small "dedicated" servers for much less than $50/month.
... Plus you can load anything else you want.
There are two "classes" of virtual servers. Companies that offer shared hosting, and companies that offer true "virtual" server. With shared hosting, you don't really have the flexibility of a whole machine. With virtual servers, you get ssh root access into a Linux or BSD system and can load your own packages etc.
The User Mode Linux based servers work very well and are really complete servers with their own dedicated file system, network, and RAM. Other than being small (32Meg of RAM, 32Meg of SWAP, and 3G of disk) that are 100% complete systems running 2.4.22 with gcc, emacs, vi, perl, php, apache, bind,
Our servers are 100% open sitting on dedicated 100Mbit lines with truely public and unfiltered IP addresses. We pre-configure iptables based firewalls, but you can open up whatever you wish.
The downside of true "virtual" servers versus shared hosting accounts is that you have to configure the software yourself. If you don't know how to setup apache and bind, then a complete server is probably not a good idea.
The bottom line is that this lets you use any old DSL/Cable modem line and still have your 100% accessible server on the net.
http://www.infoworld.com/article/03/10/27/HNscoenf orce_1.html
Some good quotes:
A lawyer representing the Free Software Foundation (FSF) disputed SCO's claims that the FSF is the only organization with the necessary legal standing to launch a GPL-based lawsuit. Since IBM holds the copyright to much of the Linux kernel software that is distributed under the GPL license, it has every right to enforce the GPL, he argued.
"The proper enforcer of a copyright is the copyright holder," said Eben Moglen, general counsel for the FSF. "IBM says, 'You're using a copyrighted work of ours in a fashion which is prohibited by the Copyright Act, and you're doing so without our permission. You owe us damages and you must stop.'"
A bunch of random comments.
1. If you are doing this for internet based servers, you might well be better off colocating your servers in a commercial data center. The cost of doing this is a lot less than it used to be and is likely less than doing it yourself. This might not be the solution for all of your systems, but may be appropriate for many.
2. You will need a lot more power than you think. Most "single/dual" cpu servers are 3-4 amps each. If you load up a rack with 1U servers, this can easily require 4 20amp circuits. UPS ratings are also in VA which is less than watts, so a 3KVA UPS is required for a 20amp circuit.
2a. Professionally install your power. Conduit and "lots" of plugs are approrpiate. 20A plugs are usually not necessary (the ones with the sideways prongs).
3. If you overload your UPS, there are two side effects. If you are only close, you just lose backup run-time. If you actually go over, then the servers all shutdown, rudely. It does not really matter what kind of servers you have in this case as the UPS itself will usually take everything to zero.
3a. Do you have a generator. If not, then the UPS will become very expensive to get any type of real run-time.
4. It sounds like you have a bit of an airflow issue. If you are using enclosed racks and have no need for rack "security", take the doors and sides off completely. If you need to lock the racks, then get perforated fronts and mount several 8-inch fans thru the back doors to blow air. You also need to get the air moving around the room. Some high-quality fans up high might move things around enough.
4a. If you are in a "seismic" area (like I am in California), be sure to bolt everything down. Even if your datacenter goes down during a 6.5, you will be less likely to kill someone.
4b. Pay attention to fire control. Sprinklers are "bad", but sometimes required. Haylon is more desireable, but often water is required anyway.
5. Buy equipment used if you can. Things like racks etc. are plentiful from failed co-los.
6. Remember remote management. You might not need managed switches, but remote power controllers are really nice. We use stuff from BayTech because it does both AC and serial. Other solutions are available from APC, etc. A lot of this stuff is also available used (ebay) so shop around.
7. If you buy used, consider possible licensing gotcha's. Some vendors have steep software/firmware relicense fees.
Most *nix distributions have a copy of rsync loaded.
/etc/xinetd.d/rsync control record for the daemon. You then need an /etc/rsyncd.conf file plus a "secrets" file to hold the passwords.
In this case you are using rsync directly over tcp/ip connections, sometimes called "daemon mode".
This mode features:
o high-strenght crytpo on passwords, but no encryption of data.
o passwords that are 100% independent of the system passwords.
o 100% streaming, even with large numbers of small files.
o restart of failed transfers where they left off.
o delta transfers for files where only parts change.
o optional gzip style compression.
o plus a lot more neat stuff.
Info on rsync is at:
http://rsync.samba.org
If you have a Linux system with xinetd or equivilent, there is a good change that you already have an
rsync directly on top of tcp/ip is how most "mirror sites" sync to their masters. It is about the only "practical" way to send gigabytes over the internet.
A couple of caveats. If stuff is twitchy, try to use the latest version of rsync (2.5.6) on both ends. Also, if you use the --compress option with already compressed (or encrypted data), there is a gziplib boundary bug. There are patches for this, but if you are sending uncompressable data, just leave off the --compress option.
I used to run hybrid servers packing as many function on a single box as practical. The problem here is that it can be tough to manage a mix of many services on a single server.
We have migrated to single application servers running on User-Mode Linux. The only down side here is that you can burn thru a lot of IP addresses, and in that most of our servers are public, it is not the best usage of address space.
In terms of maintenance, virtuals are ideal. You can individually firewall them opening only a few ports, and often only to select destinations. Updates are easily automatable with ssh pushing rpm's to guest systems.
If a system does get compromized, the damage is usually limited. The amazing part is that I have seen hackers in UML virtuals who did not even realize they were not hacked into a "real" system. This is without having "honeypot" mode turned on.
One nice thing about virtuals and single-service boxes is that you can run different software configurations for different applications without worrying about interactions. If SquirrelMail needs a different Apache/PHP version than your primary web server then just run the two in different virtuals. If you need to patch mod_proxy, then you can do it without worrying about killing your shared hosting customers because you only tested it for 15 minutes.
And the best thing about virtuals is that you can lift them up and plop them down on another system with everything 100% intact. Great when systems crash at inconvienient times.
Finally, prototyping a new server now takes a couple of minutes. Just clone an existing virtual, give it an IP address and boot. 15 seconds later, you have a live system. When you are done with it, delete the COW file (Copy-Over-Write block device file) and all signs of your temporary system are gone. It has been so long since I have done a full install, I am not sure I remember how anymore.
I don't want this to sound like an ad, but Virtuals, whether they are UML, Xen (which looks really neat, now would someone please port it's run-time as a LKM), VMWare, full VM, or whatever are just too usefull to ignore.
I have a Cox cable modem at home (along with an SBC DSL line as a backup) and run a hosting business with servers in Philadelphia, Costa Mesa, CA, and Los Angeles.
We are constantly looking for the right mix of rules to deal with spam. We don't want to interfere with our customers businesses, but we don't want to be the source of spam as well.
We have implemented a number of items to try to "play well" and give our customers the service they need.
Shared hosting customers get send after read SMTP privilidges. This is pretty standard with POP3/IMAP servers. We further limit the outbound rate to about 2 seconds a destination address just to keep people from getting cute. For those that are behind funny firewalls (like Cox), we run an outbound SMTP server on 8025. All in all, this seems to work pretty well.
I am not 100% sure how the SPF stuff would impact us. For the domains we manage, we could easily automate the DNS updates. The issue is for users that want to run our server but that we don't actually run the DNS servers for. I would love to see a "delegate" record in the spec to send the query somewhere else (maybe a CNAME would actually work, but it is late and my brain does not do that type of DNS right now).
For our "server" customers, our approach is a bit different. If you are buying a dedicated server in a co-lo, you have an expectation of being able to talk to the "net" without interference. We also believe that we dont have a lot of justification in "spying" on what our customers are doing. On the other hard, we don't want to be surprised when a customer sends out 50G of spam. About the only "solution" we could come up with is transfer logging the packets that are going to port 25 outbound (fortunately, IPTABLES does this very well). This way we will hopefully see an abuser before they get us in trouble with the BH lists.
All in all, the SPF stuff looks like it needs a bit more discussion before diving in. Also, if the outcome is just a new set of tricks that the spammers play then I am not sure if it is worth it.
mirror
Not an invitation for a DOS, but I would like to see what some real traffic looks like.
This is not a challenge for bots, just an underutilized server on a big pipe.
This is more than a little troubling.
The BIND patch is very simple and elegant. It relies on the particular technical method that Verisign used to implement their wildcard responses. But we can make some assumptions here.
If Verisign truely believe they have the "right" to do whatever they want to do with the root zone files, they can easily circumvent the patch.
One design that they might try is to take the inbound domain name, hash it, take a modulo of the hash and create a "fake" SOA and NS for that domain name on a unique IP address. With a pool of only several thousand real IP addresses they could create what looks like 100% real zones for everything. They could even send the traffic to one of many different IP addresses. This could be an arms race that never ends.
The only "real" solution is that the root zone files must be "trusted".
If Verisign refuses to change their behaviour then one of several things must happen.
o ICANN / IANA must force them to
o DOC must force them to
o Private lawsuits must force them to
o State AGs must force them to
o Everying must blackhole "ALL" Verisign owned IP addresses and effectively take them off of the net.
Just for fun, I called IANA at their listed number and asked them if there was any activity on this issue.
/.ing IANA's phone number. They are not to blame and may be our best hope of keeping Veri$ign in check.
The response from the receptionist was that it was "under discussion now" and that they were aware of the displeasure of the community.
We can only hope.
ps: I would recommend against
I also got an email response to my email from Verisign:
Dear Doug,
Thank you for contacting VeriSign Customer Service.
We have forwarded your concerns to senior management for review.
Management will be contacting you later today to discuss this issue.
If you require further assistance please contact us by replying to this
email.
Best Regards,
David Reid
Customer Service
VeriSign, Inc.
www.verisign.com
info@verisign-grs.com
RedHat has fixes (source and binaries) on their FTP site and docs in the erratta pages.
l
https://rhn.redhat.com/errata/RHSA-2003-279.htm
For RedHat 7.1: openssh-3.1p1-9
For RedHat 7.2: openssh-3.1p1-10
For RedHat 7.3: openssh-3.1p1-10
For RedHat 8.0: openssh-3.4p1-5
For REdHat 9 : openssh-3.5p1-9
Good luck at getting to their FTP servers. Hopefully, the mirrors will get them soon.
If this only impacted browsers, this would not be so bad. The problem is that it impacts a bunch of other stuff. And at the bottom of it all, the reply from the root servers is a "LIE".
.com and .net domains. That it is their property and that they can do whatever they want with it. I have news for them. As a US Citizen, I own the .com and .net domains thru my elected government. I know this is naive, but corporations need some ethics and monopolies need regulation.
Verisign thinks that it "owns" the
Complain loud and often. Via email, fax, phone, letter, or script. This cannot stand.
Only 4 of the root servers have the wildcard in place. Thus there is a bit of randomness in whether you hit it or not.
...
If you have a Linux box, you can see this with:
host verisigniscrooked.com a.gtld-servers.net
host verisigniscrooked.com i.gtld-servers.net
I think we should all call tech support on their 800 number and complain.
U.S. and Canada: 888-642-9675
Worldwide: 1-703-742-0914
Lets see if we can get their hold queue time to several hours. Perhaps even ask to speak to a supervisor. Be sure to get names of everyone you talk to. Ask for names and phone number of the corporate officers. Compare them to SCO (ok, a bit off topic but I couldn't resist).
To: icann@icann.org, iana@iana.org, nstld@verisign-grs.com,
.com and .net TLDs to a Verisign owned search
.com and .net TLDs.
rcc@verisign.com, hostmaster@nsiregistry.net, ir@verisign.com,
dcpolicy@verisign.com
Subject: Complaint about Versign abuse of DNS root zones
A Letter of Complaint about actions undertaken by Verisign Incorporated
on or about 9/13/03.
Sent to the Internet Corporation of Assigned Names and Numbers and the
Internet Assigned Number Authority.
Doug Dumitru
xxxxx xxxxxx xxxx Road
xxxxxx xxxxxx, CA 9xxxx
949 xxx-xxxx
Dear sirs,
As you are probably aware, Verisign is redirecting unregistered
2nd-level domains in the
engine. They are using a technique known as DNS wildcarding to
accomplish this.
I firmly believe that this is clearly an abuse of the DNS system, that
it violates the technical requirements for domain lookups, that the
results returned are fraudulent, and that this technical action only
benefits Verisign at the expense of the rest of the internet population.
I respectfully request that IANA and ICANN immediately take action
against Verisign demanding that Verisign cease this fraudulent and
damaging behaviour. Should Verisign refuse, I would recommend that IANA
and/or ICANN (and/or the US government) take immediate action to revoke
Verisign's contract to administer the
I would also recommend that IANA and/or ICANN immediately pass "best
practice" rules that prevent other TLDs and country-code domains from
following in Verisign's deceptive footsteps. It is important that a
"domain not found" error not be subverted into an advertising opportunity.
Sincerely,
Doug Dumitru