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.

RE: ICANN can't do anything...