Re: A list of (mostly) technical consequences of TLD wildcards

2003-09-27 Thread Paul Vixie
> > 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. just because bind does it doesn't make it a standard. -- Paul Vixie

Re: A list of (mostly) technical consequences of TLD wildcards

2003-09-27 Thread Rik van Riel
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

Re: A list of (mostly) technical consequences of TLD wildcards

2003-09-27 Thread Paul Vixie
> 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.

Re: A list of (mostly) technical consequences of TLD wildcards

2003-09-27 Thread Rik van Riel
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 h

A list of (mostly) technical consequences of TLD wildcards

2003-09-26 Thread Duane Wessels
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.