Subject: Re: DNSSEXT Yokohama Minutes

From: Brian Wellington <[email-masked]>
Date: Wed, 18 Sep 2002 16:43:51 -0700 (PDT)

On Thu, 19 Sep 2002 [email-masked] wrote:

> 
> >     Date:        Wed, 18 Sep 2002 11:16:53 +1000
> >     From:        [email-masked]
> >     Message-ID:  <[email-masked]>
> > 
> >   | 	* is internal to a zone, i.e. not the apex.
> >   | 	NS records for delegation are supposed to be copies of the
> >   | 	NS records in the child zone.
> > 
> > They should be the same, yes.
> > 
> >   |     Since * cannot be at the apex of the zone,
> > 
> > What has that to do with anything?
> 
> 	It has to do with the fact that you can't have a zone
> 	"*.example.com", hence you can't have a NS records in the
> 	parent with owner names of "*.example.com".

I don't understand why not.  I know that wildcard delegations won't work, 
but if I want to create a zone called "*.example.com", so that I can look 
up names like "foo.*.example.com", why can't I?  BIND 9 explicitly checks 
for and rejects this zone, but this has no basis in the standards.  You 
added this code :)

> 	Even if you were to create a server that supported a zone with
> 	a name of "*.example.com" that server would also *have* to serve
> 	example.com to ensure that the names that are in "example.com"
> 	get answered from the "example.com" zone and not "*.example.com".

Why?  Again, assuming * is used as a literal name, not a wildcard, the 
*.example.com zone would be the closest.  The NS record at *.example.com 
only creates a delegation at *.example.com, not every name matched by the 
wildcard (see the name server algorithm in RFC 1034).

I have absolutely no clue what the rest of the message means, so I'll stop 
here.

Brian

--
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: Robert Elz <[email-masked]>
Date: Thu, 19 Sep 2002 16:29:19 +0700

Date:        Thu, 19 Sep 2002 08:58:25 +1000
    From:        [email-masked]
    Message-ID:  <[email-masked]>

I'll ignore the question of whether it is ever possible to have
'*' as a label in the DNS, where it isn't a wildcard, as that isn't
relevant to the question of wildcards, clearly.

  |     A.my.domain and B.my.domain serve "foo.example.com"
  | 	not "www.foo.example.com".

That could trivially be changed, if it was necessary...

  | 	They generate NS records for "www.foo.example.com" as * matches
  | 	multiple labels.

It does usually, but it is possible that it does not for NS records,
because of the "delegations stop wildcards" restriction.   That is, '*' means
everything possible (other than what exists).  So, if there is a wildcard
NS record, then (using the example from my last mail), there is
necessarily a delegation for foo.example.com.   Then, we get that clause
from 1034 that says that wildcards don't survive delegations.   Hence,
the existence of the foo.example.com delegation, even without it being
explicit, would mean that www.foo.example.com was not matched by the wildcard.

Or at least that's the interpretation I was adopting in my last message.

  |     They all generate NS record for
  | 	"sfdlhkljdfsljdsa.ldkshlkds.lljkklkkk.foo.example.com".

Yes.  So ?

  | 	Answers returned from the child servers will be rejected by todays
  | 	servers as lame as the generated NS records will not match those
  | 	returned from the child zone without re-defining * to be a single
  | 	label for NS.

Huh?   Since when does anyone (registries doing delegations excepted, or
some of them...) actually go comparing the server names in NS records.
Servers (resolvers) that did that would find half the universe as lame,
as people keep sticking different names for their servers in their
delegations than what's in the zone itself (for reasons I can't even
begin to fathom, but they do).

  |	Even then you will get lame delegations unless you
  | 	have specialised child servers that accept "*.example.com" as
  | 	a zone name, expand perform a single label expansion and serve
  | 	the parent zone to ensure that the "*.example.com" "zone" doesn't
  | 	match name in example.com.

Possibly (without thinking about the details for now).   But how to
avoid lame servers wasn't the question.   Whether it is legal in the
first place to have wildcard NS was.

  | 	Using a wildcard to "delegate" can provide no benefits over
  | 	standard delegation and will lead to lame delegations.

I don't disagree with that, in general (though I could probably dream up
some exotic scenario where it would help, without causing lame delegations).

But what's useful isn't what is being discussed.   Wildcard SRV records
are unquestionably legal, but they're almost certainly not useful.
(that is *.example.com. IN SRV ...    I don't mean *._http._tcp.example.com)

That something isn't useful for anything doesn't make it illegal.

kre