Re: DNSSEXT Yokohama Minutes

[Mark.Andrews@isc.org]

>     Date:        Thu, 19 Sep 2002 08:58:25 +1000
>     From:        Mark.Andrews@isc.org
>     Message-ID:  <200209182258.g8IMwPB5061141@drugs.dv.isc.org>
> 
> 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
> .

	Well I've always read "that wildcards don't survive delegations"
	to mean that wildcards can't apply to delgations as you have
	delegated "foo.example.com" hence the wildcard can't match
	"foo.example.com".

	Mark

> 
> 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
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

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