Re: VeriSign SMTP reject server updated
Is it possible for the client resolver code to distinguish between a wildcard answer and an explicit answer?
no.
If this was available, it would mail clients and other things interested in the specific domain name could get the answers they want. While other stuff would get the wildcard answers.
right.
What happens when Verisigns monopoly registry agreement for .COM and .NET expires on November 10 2007? http://www.icann.org/tlds/agreements/verisign/com-index.htm According to the contract signed between ICANN and Verisign, Zone File Data is defined as 13. "Zone File Data" means all data contained in DNS zone files for the Registry TLD, or for any subdomain for which Registry Services are provided and that contains Registered Names, as provided to TLD nameservers on the Internet. A "wildcard" name does not meet the definition of Registered Name in the Verisign/ICANN contract. 6. "Registered Name" refers to a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels, about which Registry Operator or an affiliate engaged in providing Registry Services maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. A name in a Registry Database may be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but inactive name). Because "wildcard" names are not Registered Names, Verisign appears to be in breach of their contract with ICANN by including them in the Zone File Data. ICANN can seek specific performance of the agreement by Verisign, or seek to terminate Verisign's contract as the .COM/.NET registry operator and transfer the operation to a successor registry. IANAL, ICANN and Verisign should seek the advice of their own legal advisors.
On 9/20/03 4:45 PM, "Sean Donelan" <sean@donelan.com> wrote:
ICANN can seek specific performance of the agreement by Verisign, or seek to terminate Verisign's contract as the .COM/.NET registry operator and transfer the operation to a successor registry.
Quiet honestly I'd like to see all of the GTLD servers given to neutral companies, ones that ARE not registrars. Verisign is already engaging in a lot of unfair business practices because they hold the GTLD servers for net/com. The wildcard SNAFU is just one of their tactics to patch the financial hole since people have been switching registrars in droves. -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 Sleep: A completely inadequate substitute for caffeine.
ICANN can seek specific performance of the agreement by Verisign, or seek to terminate Verisign's contract as the .COM/.NET registry operator and transfer the operation to a successor registry.
Quiet honestly I'd like to see all of the GTLD servers given to neutral companies, ones that ARE not registrars. [...]
frankly i am mystified as to why icann awards registry contracts to for-profit entities. registrars can be for-profit, but registries should be non-profit or public-trust or whatever that specific nation's laws allow for in terms of requirements for open accounting, uniform dealing, and nonconflict with the public's interest. -- Paul Vixie
My view would concur with this, these are really old battles starting back in the netsol days and now the verisign has taken the same short sighted path. It is time that neutral party is in charge -Henry R Linneweh Paul Vixie <vixie@vix.com> wrote:
ICANN can seek specific performance of the agreement by Verisign, or seek to terminate Verisign's contract as the .COM/.NET registry operator and transfer the operation to a successor registry.
Quiet honestly I'd like to see all of the GTLD servers given to neutral companies, ones that ARE not registrars. [...]
frankly i am mystified as to why icann awards registry contracts to for-profit entities. registrars can be for-profit, but registries should be non-profit or public-trust or whatever that specific nation's laws allow for in terms of requirements for open accounting, uniform dealing, and nonconflict with the public's interest. -- Paul Vixie
On Sat, Sep 20, 2003 at 11:23:04PM -0700, Henry Linneweh wrote:
My view would concur with this, these are really old battles starting back in the netsol days and now the verisign has taken the same short sighted path.
It is time that neutral party is in charge -Henry R Linneweh
I was thinking this earlier this week. This is a public-trust that should be operated by people whose sole job is to keep it up and working, not by a dual-role entity as it is today. Perhaps we can get someone to make a not-for-profit for this sole role. - Jared
Paul Vixie <vixie@vix.com> wrote:
ICANN can seek specific performance of the agreement by Verisign, or seek to terminate Verisign's contract as the .COM/.NET registry operator and transfer the operation to a successor registry.
Quiet honestly I'd like to see all of the GTLD servers given to neutral companies, ones that ARE not registrars. [...]
frankly i am mystified as to why icann awards registry contracts to for-profit entities. registrars can be for-profit, but registries should be non-profit or public-trust or whatever that specific nation's laws allow for in terms of requirements for open accounting, uniform dealing, and nonconflict with the public's interest. -- Paul Vixie -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
----- Original Message ----- From: "Robert Blayzor" <rblayzor@inoc.net> To: "Sean Donelan" <sean@donelan.com>; <nanog@merit.edu> Sent: Saturday, September 20, 2003 5:01 PM Subject: Re: When is Verisign's registry contract up for renewal
Quiet honestly I'd like to see all of the GTLD servers given to neutral companies, ones that ARE not registrars. Verisign is already engaging in a lot of unfair business practices because they hold the GTLD servers for net/com. The wildcard SNAFU is just one of their tactics to patch the financial hole since people have been switching registrars in droves.
I've had long discussions with my admin team at the SOSDG on what would be the best way to prevent stuff like this from happening in the future. We came to the following conclusion: * Root servers or any critical DNS servers should not be in the control of companies. It should be handed over to Non-profit/not-for-profit orgs who will not be tempted to do the things Verisign has done. We feel completely comfortable with the root servers being in control of a group like the ISC or even govt. agencies like NASA. There is too much at stake here for people to be playing games with TLDs, especially ones as important as .com and .net. -------------------------- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511
On 9/20/03 6:09 PM, "Brian Bruns" <bruns@2mbit.com> wrote:
* Root servers or any critical DNS servers should not be in the control of companies. It should be handed over to Non-profit/not-for-profit orgs who will not be tempted to do the things Verisign has done. We feel completely comfortable with the root servers being in control of a group like the ISC or even govt. agencies like NASA.
Of course. Putting trust into big money corporations; look where that got us. (Hi Worldcom, Enron, Tyco, etc.) They have no respect for public interest, just the bottom line.. Hell and some don't even care about that. I don't believe in any one organization running the GTLD servers either. I believe giving it to two or three would be good. That way if one seems to do something seemingly stupid, we can effectively negate the perps and move on. There are lots of good organizations that can handle (and would be proud to handle) the GTLD servers. I don't know if I'd throw NASA in that group. (or any government agency for that matter) -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 Supercomputer: Turns CPU-bound problem into I/O-bound problem. - Ken Batcher
participants (7)
-
Brian Bruns -
Henry Linneweh -
Jared Mauch -
Paul Vixie -
Paul Vixie -
Robert Blayzor -
Sean Donelan