Subject: Re: DNSSEXT Yokohama Minutes

From: Peter Koch <[email-masked]>
Date: Thu, 19 Sep 2002 19:05:25 +0200

kre wrote:

>   | 	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.

the more important part might be the actual owner of that NS RR identifying
the zone's apex. For the server names in RDATA, you're right - that would
be fun - not. But then, I'd not call delegations failing these validity
checks `lame'.

-Peter

--
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: [email-masked]
Date: Fri, 20 Sep 2002 10:20:40 +1000

>     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
> .

	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 ?
> 
> 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: [email-masked]