Subject: Re: DNSSEXT Yokohama Minutes

From: Roy Arends <[email-masked]>
Date: Mon, 16 Sep 2002 17:25:13 +0200 (CEST)

On Mon, 16 Sep 2002, Edward Lewis wrote:

> At 4:16PM +0200 9/16/02, Roy Arends wrote:
> >Please inform me what a resolver should do with the ambiguity of both an
> >unsigned referral and a signed wildcard in a response.
>
> That's the problem.  It's getting harder and harder to tell what
> should be done.
>
> It's clear that a reply should have, barring EDNS1's multiple query
> proposal, 0 or 1 answering RRsets.  (0 means no data/name found.)
> The rest of the answer should be there to support the answer chosen.
>
> The problem is how do you protect answers that should have been
> synthesized from a signed wildcard answer (which does not have to be
> a delegation)

cannot be a delegation (wildcard delegations are not legal).

> from being spoofed away by OPT-IN modified NXT records
> and falsified answers?

I'm stumbling over your words now.

I do understand the problem. The problem is _not_ what should be in a
response, the problem is what a resolver should do with the ambiguity:
Follow unsigned delegation, or assume its a spoof, and go with the signed
wildcard.

Yes, with opt-in as is, you could simply spoof away signed wildcards with
unsecure delegations, and simply spoof away unsecure delegations with
secure wildcards.

How'bout we state in the Opt-In draft that, when using DNSSEC, having both
opt-in and wildcards are illegal.

Roy

--
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: Edward Lewis <[email-masked]>
Date: Mon, 16 Sep 2002 11:44:09 -0400

>cannot be a delegation (wildcard delegations are not legal).

I have never said that there was a wild card NS.  A wild card with 
any (legal) RRset is sufficient to cause heartburn burn because of 
the way wild cards are processed.

>Follow unsigned delegation, or assume its a spoof, and go with the signed

Not quite.  The signed wild card wouldn't be synthesized to the 
answer, but there is a need to prove it doesn't exist in this case. 
In other words, you have to prove that the answer has to have come 
from the unsecured portion of the zone before the consumer can rely 
on it.  This is getting pretty darned confusing.

>unsecure delegations, and simply spoof away unsecure delegations with

That's my issue.

>opt-in and wildcards are illegal.

No.  That's the absolute wrong approach.  I don't know where to start 
to back that up - there are too many reasons.  Reducing the problem 
to meet a solution is suboptimal.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: bert hubert <[email-masked]>
Date: Mon, 16 Sep 2002 17:42:48 +0200

> cannot be a delegation (wildcard delegations are not legal).

Neither are wildcard CNAMEs but you get roasted if you don't offer them.

regards,

bert hubert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

---

From: Roy Arends <[email-masked]>
Date: Mon, 16 Sep 2002 18:18:27 +0200 (CEST)

> Neither are wildcard CNAMEs but you get roasted if you don't offer them.

Apples and oranges,

Roy

---

From: Peter Koch <[email-masked]>
Date: Mon, 16 Sep 2002 18:45:05 +0200

> Neither are wildcard CNAMEs but you get roasted if you don't offer them.

while deviating from the thread a bit, may I ask you for a reference which
supports either of these statements? Maybe there's plenty of work to be done
to make '*'-NS-RRs actually work correctly as delegations (you'd have to
generate the SOA RRs etc. and multi level '*' expansions will turn out to
be hard), and maybe they don't make sense at all, but I wonder why they should
be "not legal", i.e. not conforming to the DNS spec.

And since '*'-PTR-RRs and '*'-A-RRs have been in use, what's so special about
'*'-CNAME-RRs?

-Peter

---

From: bert hubert <[email-masked]>
Date: Mon, 16 Sep 2002 22:02:17 +0200

> And since '*'-PTR-RRs and '*'-A-RRs have been in use, what's so special about

A CNAME is not a normal RR and requires special attention. See the
'Algorithm' in RFC1034 and how it does not mention checking for wildcard
CNAMEs. 

It may be interesting to document the actual algorithm used by PowerDNS and
BIND. PowerDNS internally does a * ANY lookup when it hits the 'check for a
wildcard' stage and retargets if the ANY record turned up a CNAME. This step
is not present in RFC1034.

Regards,

bert hubert

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Sep 2002 16:04:17 +0700

Date:        Mon, 16 Sep 2002 17:42:48 +0200
    From:        bert hubert <[email-masked]>
    Message-ID:  <[email-masked]>

  |   | > cannot be a delegation (wildcard delegations are not legal).
  | Neither are wildcard CNAMEs but you get roasted if you don't offer them.

>From exactly where do people dream up these restrictions?

There's absolutely nothing wrong with a wildcard CNAME, nor is there
any reason for there to be.   Having one would mean that you couldn't
have any other wildcard RR in the zone, because the owner of a CNAME
can't have any other data, but a wildcard CNAME is a perfectly sensible
thing to have (its the cheap way to direct all (not otherwise defined)
sub-domains of a domain to the same target, for all uses).

Nor is there anything illegal about a wildcard NS.    Actually making it
work is tricky (which might be an understatement) - that is, in making
sure the servers named actually implement the zone in question, but there's
nothing illegal as such about delegations to servers that have never head of
the zone, that (lame delegations) - happens all the time - and one could
construct a server that would generate a zone on the fly when queried about
it - provided the rules by which that was done were consistent between
all servers for a zone, that would make wildcard NS records perfectly
feasible (if most likely not very useful).

The only RR type that cannot possibly be matched by a wildcard, is SOA.
(Or at least the only one in 1034/5 vintage DNS, what happens to the
dnssec RR's, and the even odder ones like OPT aren't important here).

That's because wildcards never apply to names that are known to exist,
whereas the only place SOA is permitted is at the head of a zone, which
by definition is known to exist.

Any of the rest of the "normal" RRs can be attached to a wildcard however.

kre

---

From: Rob Austein <[email-masked]>
Date: Tue, 17 Sep 2002 09:46:18 -0700

As far as I know there is nothing in the specs to rule out either NS
or CNAME RRs with wildcard owner names (ie, I think Peter's right).

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 17 Sep 2002 15:25:16 -0700 (PDT)

> or CNAME RRs with wildcard owner names (ie, I think Peter's right).

There are two sides to this.

On the one hand, nothing forbids publishing an NS or CNAME record with
an owner name of "*", and if you explicitly query for type NS or type
CNAME, the wildcard expansion will be returned.  In this sense,
wildcard NS and CNAME records "work" just like any other record type.

On the other hand, a server that implements the name server algorithm
in RFC1034 section 4.3.2 will not issue a referral response due to a
wildcard NS, nor will it follow a wildcard CNAME, because the logic
that makes NS and CNAME records special is in the part of the
algorithm dealing with existing names (steps 3a - 3b) but not in the
part dealing with nonexistent names (step 3c).  Therefore, a wildcard
CNAME record will not create a working alias, nor will a wildcard NS
record create a working delegation.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Wed, 18 Sep 2002 11:16:53 +1000

> or CNAME RRs with wildcard owner names (ie, I think Peter's right).

	CNAME are not illegal but if you follow the steps in RFC 1034
	you won't see the wildcard CNAME unless you ask for a CNAME.

	* 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.  Since * cannot be at the
	apex of the zone, you cannot have wilcard NS records in the
	parent.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]