Subject: Re: wcard-clarify's change

From: Paul Vixie <[email-masked]>
Date: Mon, 29 Sep 2003 03:00:35 +0000

> You can do it better (the web server can know the domain name
> desired) with
> 
> >    *.gn.    ns	no-domain-ns0.psg.com.
> >    *.gn.    ns	no-domain-ns1.psg.com.
> >    *.lr.    ns	no-domain-ns0.psg.com.
> >    *.lr.    ns	no-domain-ns1.psg.com.
> >    *.ng.    ns	no-domain-ns0.psg.com.
> >    *.ng.    ns	no-domain-ns1.psg.com.

not with bind you won't.  perhaps there is software somewhere that
misreads and misimplements 1034 in that way, but this once, bind isn't
it.  it's dimly possible that dname is supposed to work like this, but
not NS.

> which is why delegation-only of BIND does not work.

that being a separate issue, i'll address it anyway.  the official
position of verisign with regard to their wildcard labels under .com
and .net is "users are free to block sitefinder if they want, we're
only doing it as a service to the internet community."  before they
(or indeed the .tk people or any of the others) could hack their
name servers to respond with an extra set of NS RRs for this, they
would have to make a public statement, "we just want to monetize
eyeballs and we'll crush anyone who gets in our way" which i think
is a statement they won't make.

therefore root-delegation-only is not BIND's answer to a prolonged
conflict but rather a way to let people "opt out" of something that
at least one gtld administrator has said "opting out of" is okay.

had this been an actual "final solution to wildcards" it would likely
have been implemented very differently.  this is a layer 9 problem,
and root-delegation-only is essentially a layer 9 solution to it.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 29 Sep 2003 03:05:34 +0000

> > Of course, in this case, since nothing says "set an authoritative
> > name error" (as it does if the '*' doesn't exist), one must presume
> > that the correct answer is NODATA (no answer, no error code).
> 
> That is the best possible interpretation of 4.3.2.

i agree.  moreover:

> However, it is also written in rfc1034 that:
> 
>    CNAME RRs cause special action in DNS software.  When a name server
>    fails to find a desired RR in the resource set associated with the
>    domain name, it checks to see if the resource set consists of a CNAME
>    record with a matching class.
> 
> And it can be said that a domain name matching a wildcard CNAME
> is associated with the CNAME but no other RRs.

what 1034 calls a "resource set" is a "set of rrsets" by modern terminology,
that is, "all rrsets at a node" or even "all rrs at a node".  by "associated
with a domain name" in the paragraph quoted above, wildcards are uninvolved.

there is no incoherency (on this point) in 1034.  wildcard cnames aren't in.
the fact that any version of bind ever pretended or still pretends to support
this unspecified behaviour is an embarrassment to me personally and to isc.