Subject: RE: DNSSEXT Yokohama Minutes

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Tue, 03 Sep 2002 10:38:29 -0400

At 10:12 2002-08-14, Hallam-Baker, Phillip wrote:
> >  Bush: Current discussion is around corner cases. Both DS and
> >        OPT-IN need flag-date; DS signing testing will continue. By
> >        and of August there should be a document set for DS. Then
> >        estimate how long additional OPT-IN would take. So mid
> >        September an assessment will be made if to OPT-IN will be
> >        going into the document set.
>
>Randy,
>
>         DNSSEC is undeployable without the NXT record being fixed.
>

For the record:
Which problem or problems with NXT needs fixing IYHO ?

>         Filibustering will do absolutely nothing to change this fact.
>
>         I will start the appeals process if any attempt is made to pre-empt
>OPTIN by announcing a flag date on DS while OPTIN is blocked by political
>tactics.

This will not happen on my watch, but Opt-in camp needs to answer the
open questions in their open park.

         Olafur

--
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: David Blacka <[email-masked]>
Date: Tue, 03 Sep 2002 13:57:34 -0400

>>>>> "ogud" == Olafur Gudmundsson <Olafur> writes:

 ogud> This will not happen on my watch, but Opt-in camp needs to
 ogud> answer the open questions in their open park.

Could somebody please restate the open questions about opt-in?  Feel
free to add new open questions.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Roy Arends <[email-masked]>
Date: Tue, 3 Sep 2002 22:09:49 +0200 (CEST)

> free to add new open questions.

As I recall, we need to write:

- The impact on: Authoritative servers (but this is already clear in draft
                 IMHO)
                 [caching] resolvers (basically the change to the resolver
                 algorihm)
- The current issues:
                 Clear AD-bit on an opt-in response.
                 (I think this will be taken care of by the "AD-bit is
                 secure" authors ).

The other (main) issue is caching of NXT/SIG(NXT). When not individually
queried for, they MUST be cached as properties of QNAME/QCLASS/QTYPE or as
an integral part of the entire answer. They MUST NOT be stored as
individual records. However, these are DNSSEC issues which are inherited
by Opt-In. In other words, caches are not more then a "response replay"
box, which is only allowed to alter the TTLs of records and the
[E]DNS-header.

Some of the above were stated by Olafur last week during the DS workshop,
others were a result of research by Rob Austein and me (which was
presented at Yokohama).

Roy

---

From: Brian Wellington <[email-masked]>
Date: Tue, 3 Sep 2002 16:40:34 -0700 (PDT)

On Wed, 4 Sep 2002, Roy Arends wrote:

> > And then there is the issue on memory usage in caches, there was an
> > assertation that opt-in zones cause more memory consumption than other
> > DNSSEC zones.
> 
> This is true,
> 
> A positive response with Opt-in holds:    QTYPE+NXT+SIG(NXT).
> 
> A positive response without Opt-in holds: QTYPE+SIG(QTYPE).

The positive response with opt-in also needs to contain proof that there's
no secure wildcard, otherwise secure wildcards can be spoofed away.  This
will mean another SIG and SIG(NXT) in almost every case.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Sep 2002 14:23:21 +0000

> The example I gave in Yokohama had not a match with any QNAME:
> 
> cached was:
> 
> a NXT e
> c NXT f
> 
> and the query is for d. Which proof of non-existence does a cache return.

it's starting to seem to me that answers containing NXT should include an
SOA in the authority section.  (even though that means nonauthoritative
servers will have to cache them, which today is illegal.)  when new secure
(verified) data arrives with a later SOA.SERIAL, all the older cached data
for that zone becomes invalid.

this is something we've discussed previously for all data, not just security
metagoo.  it has a high price both in storage, transport, and computation,
but not as high as dnssec overall, so i think it's finally worth considering.

---

From: Jim Reid <[email-masked]>
Date: Wed, 04 Sep 2002 11:40:36 -0700

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:

    Paul> can someone explain why we don't just outlaw wildcard
    Paul> records in signed zones?

Why stop at outlawing them in signed zones? :-)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Sep 2002 17:11:18 -0400

> the case for dnssec is thin enough as it is and right now can't 
> withstand
> even the slightest restriction of functionality.

Sorry, this is FUD.   You have made a completely unsupported statement 
that bears no relationship of which I am aware to anything that is 
actually happening in the world.

The case for DNSSEC is thick as a brick.   What is missing is a 
practical path to deployment for early adopters.   This is, as far as 
I've been able to tell from watching this process for some time now, 
because the cost of providing support to early adopters is the same as 
the cost of providing support once everybody's adopted it, and this 
represents what is seen to be an unsurmountable barrier to adoption.   
This has absolutely nothing to do with functionality, or restrictions 
thereof.

If we can lower the barrier for early adopters by getting rid of 
wildcards in secured zones, we should do it.   If you think that this 
statement is incorrect, you should make a logical argument, based on 
verifiable facts, that refutes it.   You should not engage in FUD.

---

From: Edward Lewis <[email-masked]>
Date: Sat, 14 Sep 2002 10:44:44 -0400

>for that zone becomes invalid.

NXT's are already supposed to only be signed by the zone key.  Isn't 
that sufficient to identify the authority - or is there something 
else needed out of the SOA RR RDATA?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

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

On Mon, 16 Sep 2002, Scott Rose wrote:

> ----- Original Message -----
> From: "Edward Lewis" <[email-masked]>
>
>
> > At 10:01AM +0200 9/4/02, Roy Arends wrote:
> > >Note that wildcards are in a zone, delegation points are outside a zone,
> > >therefor you can't use wildcard delegations, and thus no proof for
> > >existing wildcard delegation is needed.
> >
> > Question is: does an signed wildcard trump an unsigned delegation name?
> > --
>
> I think it should - wildcards can be signed, and considered authoritative in
> a zone.  Since delegations aren't, it could be spoof (but hopefully detected
> later).
>
> A resolver can verify a signed wildcard, but not a delegation.

You treat "authoritative" and "signed" as equal, while one relates to
server and the other to source.

Delegations can only be spoofed if they are not signed. That is a
conscious descision a signer makes.

Please inform me what a resolver should do with the ambiguity of both an
unsigned referral and a signed wildcard in a response.

Spoofing can go both ways, one can spoof a unsigned referral with a signed
wildcard, or a signed wildcard with an unsigned referral. Simply proofing
the existence of a signed wildcard makes this ambiguity not go away. It is
about the descision a resolver has to make: follow an unsigned referral or
stick with the signed wildcard.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Sep 2002 10:46:18 -0400

>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) from being spoofed away by OPT-IN modified NXT records 
and falsified answers?

---

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

On Mon, 16 Sep 2002, Edward Lewis wrote:

> At 5:25PM +0200 9/16/02, Roy Arends wrote:
> >cannot be a delegation (wildcard delegations are not legal).
>
> I have never said that there was a wild card NS.

Apologies, I've misread your post.

> A wild card with any (legal) RRset is sufficient to cause heartburn burn
> because of the way wild cards are processed.

I agree.

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

yeah.

> >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.
>
> That's my issue.

Okay, lets focus on that.

> >How'bout we state in the Opt-In draft that, when using DNSSEC, having both
> >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.

I agree, but I would just call it a pragmatic solution, since it works.

(I wasn't seriously proposing it, I just forgot the smiley)

Roy

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Sep 2002 11:59:58 -0400

>(I wasn't seriously proposing it, I just forgot the smiley)

Okay - ;)

---

From: "Loomis, Rip" <[email-masked]>
Date: Mon, 16 Sep 2002 18:54:20 -0400

> > This will, I'm told by folks who run large zones (other 
> > than .COM), will result in DNSSEC not being deployed in
> > those zones.
> 
> Could you phrase their concerns ? Or do you know if there are 
> alternatives to their wildcard needs ?
> 
> I'm looking for the case where wildcards are vital, and for 
> which there is no alternative present. I can't think of any.

Roy--
I agree that I can't think of any case where there is no
alternative available.  However, from what little I know there
are some folks who run very large numbers of "small" zones,
and a few folks who run small numbers of "medium large" zones,
who currently do use wildcards.  The existence of an alternative
to wildcards does not mean that the alternative will be used,
unless those folks can in some way be convinced that wildcards
are broken and must in fact be fixed.  

Since I don't see such convincing happening (it hasn't to date),
if we tell them that they can't sign a zone with wildcards then
they're quite likely to reply, "Okay we won't sign it."  Then
again, many of those folks are unlikely to sign those zones in
the next five years regardless (IMHO), so I'm not sure we should
let them tie things in knots.

Perhaps David has a more complete and concrete answer.

--
Rip Loomis                         Senior Systems Security Engineer
SAIC Secure Business Solutions Group         www.saic.com/securebiz
Center for Information Security Technology   www.cist-east.saic.com

---

From: Paul Vixie <[email-masked]>
Date: Mon, 16 Sep 2002 23:19:52 +0000

> are broken and must in fact be fixed.  

for the case i think you're referring to, an apex DNAME is a better
solution in any case.  i volunteer to edit an i-d on the subject of
"alternatives to wildcarding" if you (and everyone else here) will
send me detailed cases to study.

> let them tie things in knots.

the quality (including simplicity if any) of the specification, and
its timeliness, and the availability of good tools, are all going to
have a much greater impact on the deployment curve than wildcarding.

---

From: Roy Arends <[email-masked]>
Date: Tue, 17 Sep 2002 01:23:38 +0200 (CEST)

> let them tie things in knots.

I'm not saying wildcards should be killed. I'm convinced that wildcard
support makes the system more complex, but not impossible. I'm simply
assessing arguments for and against it.

Thanks,

Regards,

Roy

---

From: Roy Arends <[email-masked]>
Date: Tue, 17 Sep 2002 11:58:19 +0200 (CEST)

On Tue, 17 Sep 2002, Robert Elz wrote:

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

....

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

I find this highly unlikely.

An NS record is not authoritative in a parent zone, i.e. they point
outside the zone (they are authoritative elsewhere). Wildcards are
_within_ a zone, (they are within the authoritative part). I quote:

   The owner name of the wildcard RRs is of the form "*.<anydomain>",
   where <anydomain> is any domain name. <anydomain> should not contain
   other * labels, and should be in the authoritative data of the zone.

   Wildcard RRs do not apply:

      - When the query is in another zone.  That is, delegation cancels
        the wildcard defaults.

Sure, this is all theoretical, and you could hack up a server which allows
you to do this. That does not make it legal.

Roy

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Sep 2002 19:27:54 +0700

Date:        Tue, 17 Sep 2002 11:58:19 +0200 (CEST)
    From:        Roy Arends <[email-masked]>
    Message-ID:  <[email-masked]>

  | I find this highly unlikely.

Yes, of all the possible RR types, wanting to wildcard NS is perhaps
the least likely.

  | An NS record is not authoritative in a parent zone, i.e. they point
  | outside the zone (they are authoritative elsewhere). Wildcards are
  | _within_ a zone, (they are within the authoritative part). I quote:

Yes, but ...

  |    The owner name of the wildcard RRs is of the form "*.<anydomain>",
  |    where <anydomain> is any domain name. <anydomain> should not contain
  |    other * labels, and should be in the authoritative data of the zone.

Note it is <anydomain> that has to be in the authoritative data for
the zone, not the foo.anydomain that is being looked up.   That restriction
has no relevance at all.

  |    Wildcard RRs do not apply:
  | 
  |       - When the query is in another zone.  That is, delegation cancels
  |         the wildcard defaults.

This one is more borderline, but I certainly can't convince myself that
it actually means that wildcard NS is illegal.   I'm not actually sure what
that one is for, especially if wildcard NS were illegal, as then the
delegation would create a "known" name, and it is clear that wildcards
never match known names, or their sub-domains, so if wildcard NS was
illegal, that rule wouldn't be needed at all.

The only situation that I can imagine where that restriction would apply,
would be if we had

	$ORIGIN example.com.
	* IN NS server.whatever.
	  IN NS other.thing.

and a lookup came for a.b.example.com.   Then the paragraph above would
indicate that the '*' there matches b.example.com, and that making a
delegation, cancels the wildcard defaults, so the correct response is a
referral to server.whatever and other.thing, rather than to return

	a.b.example.com. IN NS server.whatever. (etc).

as one would normally do if it were a wildcard MX, or A, or something.

I'm not about to fault any servers that don't implement wildcard NS records,
but I really don't think they're illegal according to the specs (just useless
for most practical purposes).

kre

ps: I really did go and re-check 1034 before I replied the first time...

pps: I have no direct opinion on the question of whether or not wildcards
should be declared incompatible with signed zones.   I do know that I
see no merit at all in the line of argument that goes "we cannot do X, as
person or group Y won't like it".   If you suspect that to be true, tell
Y about the proposal, and ask for reasoned responses to the namedroppers
list.   That way we get first hand responses, from the people it (perhaps)
actually matters to, rather than someone's perhaps misinformed opinion 
of what some 3rd party's needs are.   [Roy: this ps is not aimed at you!]

---

From: Robert Elz <[email-masked]>
Date: Wed, 18 Sep 2002 18:23:21 +0700

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?

Eg, say I have on server A

	$ORIGIN	foo.example.com.
	@	IN	SOA	...
		IN	NS	A.my.domain.
		IN	NS	B.my.domain.
	www	IN	A	1.2.3.4

Then on server Q, I have

	$ORIGIN example.com.
		[normal stuff]
	*	IN	NS	A.my.domain.
		IN	NS	B.my.domain.

and no mention of "foo" anywhere in that zone at all.

Then, someone does a lookup of www.foo.example.com

The wildcard NS records exactly match the NS records at the apex of the
zone delegated.   No problem at all.

Of course, someone might also do a lookup of

	www.random.example.com.

and you might think, that because A (and B) have never heard of 
random.example.com this must necessarily be illegal.   But first,
how can Q possibly tell the difference between these two cases?

And second, A might be a "smart" server, that creates the zone upon
demand - that is the "$ORIGIN foo.example.com." zone above might have
been created by A when the (first) query for www.foo.example.com. appeared.

I'm not saying that any of this is useful for anything much, but

  | you cannot have wilcard NS records in the parent.

isn't supportable as an argument.

kre

---

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

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

> zone delegated.   No problem at all.

	No they don't.

	They generate NS records for "www.foo.example.com" as * matches
	multiple labels.  A.my.domain and B.my.domain serve "foo.example.com"
	not "www.foo.example.com".  They all generate NS record for
	"sfdlhkljdfsljdsa.ldkshlkds.lljkklkkk.foo.example.com".

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

	The only place I've seen an attempt to use * to "delegate" is in
	the IN-ADDR.ARPA tree.  We created $GENERATE and offered it to
	dnsind to handle this case.  It got rejected so we kept it as
	a implementation extention.

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

	Mark

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

---

From: [email-masked]
Date: Fri, 20 Sep 2002 11:20:16 +1000

> 
> kre wrote:
> 
> >   | 	Answers returned from the child servers will be rejected by tod
> ays
> >   | 	servers as lame as the generated NS records will not match thos
> e
> >   | 	returned from the child zone without re-defining * to be a sing
> le
> >   | 	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

	I meant the parent server says that a zone "www.foo.example.com"
	exists then the child says I serving "foo.example.com" not
	"www.foo.example.com".
	
	This is no different to those sites that are lazy and use
	a "com" zone for all there delegations under com.  It's a lame
	delegation and a cache poisioning attack so we have to look
	for it.

	Mark

---

From: Robert Elz <[email-masked]>
Date: Fri, 20 Sep 2002 18:39:20 +0700

Date:        Fri, 20 Sep 2002 10:20:40 +1000
    From:        [email-masked]
    Message-ID:  <[email-masked]>

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

But that would be meaningless, as (at least without wildcard NS records).
If foo.example.com exists, then it is a 

   - When the query name or a name between the wildcard domain and
     the query name is know to exist.
[sic]

We wold know that foo.example.com exists, if we have explicitly delegated
it, obviously, and hence the wildcard could not apply to anything below
foo.example.com (just as it could not if foo.example.com merely had an A
record, it is still a known name, and hence, the wildcard *.example.com
cannot make www.foo.example.com exist).

Hence, what is

actually for?   Here I'm guessing, not stating the intent of the time,
or of the authors.   But it might be interpreted as assuming

	* IN NS xxx

delegates every (unknown) sub-domain.   Then every query to anything
a.b.$ORIGIN would necessarily be to something in another zone, as the
wildcard would delegate b.$ORIGIN (should anyone bother to ask).
Then, the restriction would mean that this delegation cancels the wildcard.
and in particular, www.foo.example.com. would not match the wildcard
in my previous message, but foo.example.com. would be delegated, implicitly,
and hence a referral would be correct behaviour.

I'm not attached to this interpretation in any way, I'm not claiming that
it is the correct one (any better knowledge on why this particular
restriction is there gratefully accepted - even better if backed by some
contemporary evidence, rather than "looking back, it must have meant...)

[email-masked] said in another message:
| 	I meant the parent server says that a zone "www.foo.example.com"
| 	exists then the child says I serving "foo.example.com" not
| 	"www.foo.example.com". 

Yes, I know, but if the correct interpretation of the wildcard were that
www.foo.example.com was delegated, then I would have made the server for
the child serve that zone.   It was the way it was, only because I was
assuming the interpretation above.

kre