Decius wrote:
] Original Page:
] ] We call on ICANN to examine the procedures for changes in
] ] service, including provisions to protect users from
] ] abrupt changes in service.
] ]
] ] 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.
]
] This really didn't get much coverage yesterday given that it
] came out shortly after Verisign's arrogant response. Its
] interesting. If ICANN could do something, this document would
] specifically say "Verisign is in violation of XYZ." It
] doesn't. What it says is that rules need to be reconsidered
] and clarified. IE, what they have done is not against the
] current rules. ICANN has the right under their contracts to
] create new policies, and Verisign must abide by those policies
] once they are approved within a reasonable period of time.
] This document is part of a long documentation trail that will
] ultimately result in Sitefinder getting shutdown. This
] process could take years. There are a number of methods
] that Verisign can use to delay things, including disputing the
] ICANN process, and filing a breach of contract suit along with
] a request for preliminary injunction preventing any new ICANN
] regulation from taking effect, and then delaying and delaying
] and delaying on going to trial, and then appealing and
] appealing... Once the court process is over with Verisign gets
] 4 months to implement any change ICANN requires. Furthermore,
] we're not anywhere near that stage yet. We are miles away.
] There is all kinds of IAB, IETF, and ICANN beaurocratic
] bullshit that has to occur first.
]
] I hope I'm wrong, but I doubt it. They should have had a
] clause in the contract that prevents Verisign from making
] disruptive changes without seeking approval. They don't. This
] is a loophole big enough to drive a truck through, and
] Verisign just did. By the time this actually gets resolved
] will we have been living with it for so long that no one will
] notice.

I don't think you are wrong. It will take years.

] If this issue is not resolved by Phreaknic I will use my
] speaking time there to call for a move to a DNS system that
] exists outside of ICANN's control. Its not really their fault,
] but this situation cannot be allowed to go on for years.

I have a few questions that I have not yet had the time to research.. What is the current size of the z... [ Read More (0.2k in body) ]

Decius wrote:
] ] We call on ICANN to examine the procedures for changes in
] ] service, including provisions to protect users from
] ] abrupt changes in service.
] ]
] ] 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.

] If this issue is not resolved by Phreaknic I will use my
] speaking time there to call for a move to a DNS system that
] exists outside of ICANN's control. Its not really their fault,
] but this situation cannot be allowed to go on for years.

There's always opennic (www.opennic.unrated.net or www.opennic.glue if you already have it set up). This doesn't help with the *.com problem, though. The CMU Computer Club's nameservers are set up that way -- 128.2.4.142 and 128.2.4.151 -- feel free to play with it but be advised that those addresses may change in a few months.

One thing that I advocate doing with recursive nameservers regardless of your position on ICANN, etc, is rather than having a root.cache that just lists root nameservers, sync the root zone and have the hints point to all of the nameservers for all of the TLDs. This reduces latency since you never go to root servers -- good queries go straight to the NS for that TLD and your server can immediately generate an NXDOMAIN for queries that don't correspond to any TLD.