A list of (mostly) technical consequences of TLD wildcards
I've been collecting a list of things that are broken, or might break, now that the two most populated TLDs have A and MX record wildcards. You can find the list at http://www.packet-pushers.net/tld-wildcards/ I'll be happy to receive any additions or corrections that you might have. Duane W.
On Fri, 26 Sep 2003, Duane Wessels wrote:
I've been collecting a list of things that are broken, or might break, now that the two most populated TLDs have A and MX record wildcards.
Makes me wonder why Verisign didn't use a (less harmful?) CNAME wildcard ... Rik -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Makes me wonder why Verisign didn't use a (less harmful?) CNAME wildcard ...
The CNAME algorythm in RFC1034 looks for CNAMEs before it looks for wildcards, meaning that the target of a CNAME could end up matching a wildcard, but the CNAME owner itself won't be found using the wildcarding rules. see [4.3.2]. What this means is, there is no such thing as a wildcard CNAME. -- Paul Vixie
On Sat, 27 Sep 2003, Paul Vixie wrote:
What this means is, there is no such thing as a wildcard CNAME.
Funny... $ host -t cname \*.TD *.TD is an alias for www.nic.TD. Rik -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
participants (3)
-
Duane Wessels -
Paul Vixie -
Rik van Riel