(also -- bind8 workaround published) Re: delegation-only: Who?
Jonathan de Boyne Pollard
J.deBoynePollard at Tesco.NET
Fri Sep 26 11:44:04 UTC 2003
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.)
More information about the bind-users
mailing list