(also -- bind8 workaround published) Re: delegation-only: Who?

[Jonathan de Boyne Pollard]

AK>   *.BZ.           IN A      216.220.34.101

Whilst resource record sets with this domain name exist, 
wildcard processing is _not_ being performed by the 
"bz." content DNS servers.

(This exemplifies the points that wildcard answer generation is an 
entirely internal matter for a set of peer content DNS servers;
and that there's no completely reliable way for the rest of 
Internet to determine positively that it is occurring.)

AK>   *.CN.           IN A      159.226.7.162

The "cn." content DNS servers are also not performing 
wildcard processing, despite the existence of this resource
record set.

AK>   *.TW.           IN A      203.73.24.11

The "tw." content DNS servers are another set that
are not actually performing wildcard processing.

AK>   *.TK.           IN MX     20 NUKUMATAU.TALOHA.COM.
AK>   *.TK.           IN A      217.69.159.151
AK>   *.TK.           IN A      216.38.142.218
AK>   *.TK.           IN A      217.69.159.150

The wildcard processing on the "tk." content DNS servers
appears to be broken.  Look at their responses to "ANY" 
queries.  

AK>   *.PW.           IN CNAME  wfb.dnsvr.com.

At 2003-09-26 13:08, this resource record set was not being 
published by any of the "pw." content DNS servers.

AK>   *.TD.           IN CNAME  www.nic.TD.

Ironically, the fact that this works demonstrates that the
"td." content DNS servers are not following the algorithm
in section 4.3.2. of RFC 1034.  (That algorithm produces
incorrect results, if followed.)

This also flouts the good practice of not using client-side
aliases in addition to server-side aliases.  (Wildcard answer 
generation is one specialised form of server-side aliasing,
of course.)