A little dry humour describing software solutions to thievery by Paul
Vixie and crew: http://www.isc.org/products/BIND/delegation-only.html

=======
                  ISC BIND "delegation-only" Feature

 Document last updated: September 24th, 2003

 delegation-only

 In response to high demand from our users, ISC has added to BIND9
 support for the declaration of "delegation-only" zones in
 caching/recursive name servers. Briefly, a zone which has been declared
 delegation-only will be effectively limited to containing NS RRs for
 subdomains, but no actual data beyond its own apex (for example, its
 SOA RR and apex NS RRset). This can be used to filter out "wildcard" or
 "synthesized" data from NAT boxes or from authoritative name servers
 whose undelegated (in-zone) data is of no interest.

 Example:

 zone "FOO" { type delegation-only; };
 zone "BAR" { type delegation-only; };

 root-delegation-only

 Additionally, because many of our users are uncomfortable receiving
 undelegated answers from root or top level domains at all, other than a
 few for whom that behaviour has been trusted and expected for quite
 some length of time, we have now introduced starting with 9.2.3rc3 the
 root-delegations-only feature which applies delegation-only logic to
 all top level domains, and to the root domain. An exception list should
 be specified, including those listed in the example listed below, and
 any other top level domains from whom undelegated responses are
 expected and trusted.

 Example:

 options {
      root-delegation-only exclude { "de"; "lv"; "museum"; "us"; };
 };
=======

Latest example of good old-fashioned internet 'routing around damage'? 

Any comments on this sort of approach, and how it might affect DNS
stability and conformance to expected net.behaviour for undelegated
subdomains of, say, .com and .net, assuming Veri$ign trumps ICANN?

Cheers, Ian