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: David Blacka <[email-masked]>
Date: Tue, 03 Sep 2002 16:39:08 -0400

>>>>> "Roy" == Roy Arends <[email-masked]> writes:

 >> free to add new open questions.

 Roy> As I recall, we need to write:

 Roy> - The impact on: Authoritative servers (but this is already
 Roy> clear in draft IMHO)

 Roy> [caching] resolvers (basically the change to the resolver
 Roy> algorihm)

More specifically, what needs to be in the opt-in draft that isn't
already there about this?  Or is what is in the draft just not clear
enough? (I am asking the list, not just Roy)

 Roy> - The current issues:
 Roy> Clear AD-bit on an opt-in response.
 Roy> (I think this will be taken care of by the "AD-bit is
 Roy> secure" authors ).

Ok.  Does this mean the AD bit behavior does not need to be opt-in
draft at all?  Or just a reference to a new AD-bit draft?

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

I do not understand the harm in also caching the NXTs as individual
records.  This is probably because I do not fully understand the
corner case you and Rob Austein investigated.

What I do understand is this: opt-in creates a case where for a
postive response, a cache must be able to return the covering opt-in
NXT that goes with the response, and that NXT record does NOT share
its name with qname.  Hence, the cache should store the NXT records as
properties of the original qname.  I also know that this case also
shows up in negative caching, with or without opt-in.  Well, there
will most likely be more than one NXT record to cache in this manner,
as there will most likely be at least one wild-card proof NXT.

But why shouldn't the cache be able to respond for an explict query
for one of those NXT records?

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 3 Sep 2002 17:27:26 -0400 (EDT)

>                  (I think this will be taken care of by the "AD-bit is

This is for Opt-in to specify, not AD due to dependancy reasons, this
definition is only needed if both AD and Opt-in are part of the standard.

For the record: this relates to use of NXT between the two names
on the NXT (record name and the target name).
In DNSSEC where AD bit is used (either RFC2535 or AD-secure definition),
the AD bit can be set on responce if it is authenticated denial with NXT,
for the QNAME if the
	NXTNAME  == QNAME or (NXTNAME < QNAME and QNAME < NXTargetNAME )

Opt-in NXT must define that this that NXT can only be used when
NXTNAME == QNAME to set the AD bit.

> others were a result of research by Rob Austein and me (which was

Then there is the minor issue of bytes on the wire, are responses
from Opt-in zones smaller/same/larger than from regular DNSSEC zones.

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.

	Olafur

---

From: Roy Arends <[email-masked]>
Date: Tue, 3 Sep 2002 23:57:43 +0200 (CEST)

> enough? (I am asking the list, not just Roy)

And I was just repeating comments. The draft is pretty clear on that, but
hey, who am I to judge :-)

> draft at all?  Or just a reference to a new AD-bit draft?

Then lets just fully specify it, better double effort that no effort at
all.

> corner case you and Rob Austein investigated.

Wait, thats not what I wrote. When explicitly queried for, yes, the cache
can replay the response if, and only if it was cached as result of a
previous explicit query for that NXT.

> for one of those NXT records?

Sure, explicit queries for qtype NXT are okay, as long as cache follows
the query, and NOT _reconstruct_ responses from cache. If it has been
cached as an individual QNAME/QCLASS/QTYPE, than the cache can simply
respond that. But again, simply replay the response, not reconstruct.

Roy

---

From: Roy Arends <[email-masked]>
Date: Wed, 4 Sep 2002 00:20:24 +0200 (CEST)

> > As I recall, we need to write:
.....
> definition is only needed if both AD and Opt-in are part of the standard.

Okay.

> NXTNAME == QNAME to set the AD bit.

I don't understand what you just wrote.

This issue is as follows:

"AD-is-secure" states that the AD bit may be set when _all_ resource
records in a [negative] response are cryptographically verified to be
valid.

An Opt-in negative response reaching the resolver only has signed records.
This implies AD=1.

But, this negative response might have been a positive Opt-In response
when it has left the authoritative server.

When AD=1 is sent to an application/stub/whatever which places trust in
this bit, the application/stub/whatever is effectively misled. So, AD=0 on
an Opt-In response effectively takes care of this situation.

> assertation that opt-in zones cause more memory consumption than other

This is true,

A positive response with Opt-in holds:    QTYPE+NXT+SIG(NXT).

A positive response without Opt-in holds: QTYPE+SIG(QTYPE).

Roy

---

From: David Blacka <[email-masked]>
Date: Tue, 03 Sep 2002 18:32:25 -0400

>> corner case you and Rob Austein investigated.

 Roy> Wait, thats not what I wrote. When explicitly queried for, yes, the cache
 Roy> can replay the response if, and only if it was cached as result of a
 Roy> previous explicit query for that NXT.

What I was really asking is why the "only if it was cached as result
of a previous explicit query for that NXT" condition?

If I get NXT records (opt-in or otherwise) in the authority section of
a response, I need to cache these NXTs as properties of the qname, but
why can't I ALSO cache them as ordinary records?

 Roy> Sure, explicit queries for qtype NXT are okay, as long as cache
 Roy> follows the query, and NOT _reconstruct_ responses from
 Roy> cache. If it has been cached as an individual
 Roy> QNAME/QCLASS/QTYPE, than the cache can simply respond that. But
 Roy> again, simply replay the response, not reconstruct.

Specifically, what pitfalls exist in reconstructing a positive
response to an explit NXT query?

The reason I am pursuing this is that I'm trying to imagine how I
would build a cache, and I am thinking that I would like to store the
NXT records just like any other record in my cache, while having other
cache values have pointers to it (rather than storing the NXT set in
toto with the original qname).

---

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

> 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: Derek Atkins <[email-masked]>
Date: 03 Sep 2002 23:20:05 -0400

> why can't I ALSO cache them as ordinary records?

Let me see if I can remember this example that Roy worked through
with me in Yokohama (at a very expensive bar, eh Roy? ;)

Assume you've got this record at time T0:

 a in ...
   in nxt k ...

At time T1 you make a query for f and get the "a in nxt k" response.
Now, at time T2 the zone is changed and you now have records:

 a ...
   in nxt d
 d ...
   in nxt k
 
At time T3 you make a query for e.  You now have two overlapping NXT
records, a->k and d->k.

Now you make a query for d.  What do you do?  You've now got an
authoritative negative query for "d" in your cache, but you've also
got an authoritative positive response for 'd' in the zone (not
cached).

Note that this is not just a problem with Opt-in, but opt-in makes the
problem worse because records can not only change in terms of
existance but also in terms of whether they are signed.

Hopefully Roy can better explain this particular issue.

> response to an explit NXT query?

That's not the issue.  The issue is if you make a request for
NameA/ClassA/TypeA and cache the NXT response, then make a request for
NameB/ClassB/TypeB, you should not respond with the NXT obtained from
the A/A/A request.  In other words, you should not promote the NXT
response from request 1 across to request2 unless the Name/Class/Type
are the same.

> toto with the original qname).

NXT records are just special..  The reason is that they can cause a
failure in other records, which can lock out a large portion of a zone
for long periods of time.

As I said, hopefully Roy can better explain this.

> Sr. Engineer    Verisign Applied Research

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Roy Arends <[email-masked]>
Date: Wed, 4 Sep 2002 09:06:08 +0200 (CEST)

> will mean another SIG and SIG(NXT) in almost every case.

No, you don't need proof for wildcards.

If I was to spoof a resolver, proof of [non-]existence of secure wildcards
does not prevent or help me do that.

If you asked for something in an unsecured interval, all bets are off.

Remember that this is for delegations only. Are you suggesting proof
of [absent] signed wildcard delegations ?

Roy

---

From: Roy Arends <[email-masked]>
Date: Wed, 4 Sep 2002 09:17:51 +0200 (CEST)

> with me in Yokohama (at a very expensive bar, eh Roy? ;)

Yes, it still hurts :-)

> Hopefully Roy can better explain this particular issue.

This is indeed the problem. This problem exist with any accidental
"interval overlap".

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.

> response from request 1 across to request2 unless the Name/Class/Type

Bingo.

> As I said, hopefully Roy can better explain this.

You did it very well.

NXT records are more a statement on other records/types then that they are
individual records. (or: NXT records just suck).

Roy

---

From: Roy Arends <[email-masked]>
Date: Wed, 4 Sep 2002 10:01:30 +0200 (CEST)

> of [absent] signed wildcard delegations ?

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.

roy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 4 Sep 2002 08:25:22 -0400

>	NXTNAME  == QNAME or (NXTNAME < QNAME and QNAME < NXTargetNAME )

By "NXTNAME," do you mean the NXT RR set owner name?  (ONAME?)

Also, there is the case that the "target" name = apex name ( = signer name).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: David Blacka <[email-masked]>
Date: Wed, 04 Sep 2002 09:53:57 -0400

>>>>> "Derek" == Derek Atkins <[email-masked]> writes:

 >> response to an explit NXT query?

 Derek> That's not the issue.  The issue is if you make a request for
 Derek> NameA/ClassA/TypeA and cache the NXT response, then make a
 Derek> request for NameB/ClassB/TypeB, you should not respond with
 Derek> the NXT obtained from the A/A/A request.  In other words, you
 Derek> should not promote the NXT response from request 1 across to
 Derek> request2 unless the Name/Class/Type are the same.

Suppose my caching resolver first issues the following:

Q: foo.bar. IN A

And gets back:

AUTH: a.bar IN NXT g.bar
      a.bar IN SIG NXT ...

Next, it issues the following:

Q: a.bar. IN NXT

is there a problem returning:

ANS: a.bar IN NXT g.bar
     a.bar IN SIG NXT ...

?

Or even:

Q: a.bar. IN ANY

ANS: a.bar IN NXT ...
     a.bar IN SIG NXT ...

Note that I'm not suggesting that the resolver build negative proof
out of NXT records that it has in its cache.  You (and Roy)
illustrated the potential problems with that fairly clearly.

I am trying to draw a distinction between Roy's stated requirement
that "[NXT records] MUST NOT be stored as individual records", and a
slightly weaker restriction that resolvers MUST NOT use cached NXT
records to construct new negative (or opt-in) proofs.

Of course, I think that this particular example that I'm bringing up
is not very natural.  I'm not sure that this particular query sequence
would occur except for debugging.

 >> toto with the original qname).

When I said this, I was not imagining that the resolver be able to do
anything with the NXT records other than respond to a direct query for
them.

 Derek> As I said, hopefully Roy can better explain this.

You did a pretty good job.

---

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

> 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: Derek Atkins <[email-masked]>
Date: 04 Sep 2002 10:29:06 -0400

[example snipped]

Let me give a different example (similar to before).  Note that
between query-1 and query-2 the zone has changed.

Q: foo.bar. IN A
AUTH: a.bar IN NXT g.bar
      a.bar IN SIG NXT ...

Q: baz.bar. IN A
AUTH: a.bar IN NXT d.bar
      a.bar IN SIG NXT ...

Q: a.bar IN ANY (or IN NXT)
AUTH: ???

What do you return here?  This is still the same problem.  Do you
return both?  Do you choose one?

> would occur except for debugging.

Yes, but as I (hopefully) pointed out, it can be just as problematic.

> You did a pretty good job.

Thank you.  I wasn't so sure last night.

-derek

---

From: Roy Arends <[email-masked]>
Date: Wed, 4 Sep 2002 16:41:57 +0200 (CEST)

> is there a problem returning:

Yes, the problem is that you synthesize parts of a negative response to
satisfy a positive response. Next to the TTL issues involved, the matching
algorithm to satisfy the query from cache is horribly complicated,
especially when different caching methods are used for pos. and neg.
caching.

>      a.bar IN SIG NXT ...

If you mean QTYPE=* then this poses another difficulty (DNSSEC, not
Opt-In). With this optimised matching, you might not find a complete
answer.  Since you probably want all record types that exist at an owner
name (listed in the NXT type bit map), but you only get the NXT record
from cache, since that satisfies the matching. There is no way to get a
better response, other then wait TTL+1 second.

> illustrated the potential problems with that fairly clearly.

Okay, but the first example looked like you are doing exactly that.

> records to construct new negative (or opt-in) proofs.

Wait, it is no problem to cache NXT records as individual records, but
_only_ as a result of a query where QTYPE is NXT.

This is what I said:

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

The key-sentence here is "When not individually queried for". I referred
to type=NXT

Regards,

Roy

---

From: Brian Wellington <[email-masked]>
Date: Wed, 4 Sep 2002 09:40:51 -0700 (PDT)

> of [absent] signed wildcard delegations ?

No, I'm suggesting proof of absent wildcards.  While opt-in might be 
restricted to delegations, that doesn't mean that the zone is.

For example, consider the foo.com zone, with:
@	SOA
	NS
*	A
a	NS
c	NS
e	NS

Without DNSSEC, querying for www.b.foo.com will hit the wildcard A record, 
and querying for www.c.foo.com will return a referral.

Now sign the zone, and have 'a' and 'e' signed, and 'c' unsigned:

@	SOA
	SIG SOA
	NS
	SIG NS
	KEY
	SIG KEY
	NXT
	SIG NXT
*	A
	SIG A
	NXT
	SIG NXT
a	NS
	DS
	SIG DS
	NXT
	SIG NXT
c	NS
e	NS
	DS
	SIG DS
	NXT
	SIG NXT

(Hope I didn't miss anything there)

Query for www.c.foo.com.  According to your claim, you should just give 
out the referral (NS + DS + SIG DS) and the proof that the name is 
insecure (a's NXT and SIG NXT).

Query for www.b.foo.com, and have a malicious server replay a response
with the same insecurity proof, and a forged unsigned referral.  There's
no way to prove it's false, and you've now spoofed away the existence of a
secure name, since www.b.foo.com was secure in the non-optin case.

Yes, this is bad.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Sep 2002 17:46:35 +0000

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

---

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: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 04 Sep 2002 14:48:05 -0400

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

Once you convince the world that following is not needed in any zone.

*       MX      10 <mail1>
         MX      20 <mail2>

Then killing wildcards is becomes a possibility.

         Olafur

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Sep 2002 19:51:24 +0000

> Then killing wildcards is becomes a possibility.

"convincing the world" == "boiling the ocean."  let's just convince the
world that if they want wildcards then they have already discarded all
hope of security, so they don't need dnssec for zones using wildcards.

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Sep 2002 13:14:27 -0700

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

folk use wildcard MX.  expect significant wildcard use in e164.arpa to
point whole city or country codes off to ldap servers.  etc.

randy

---

From: bert hubert <[email-masked]>
Date: Wed, 4 Sep 2002 22:35:49 +0200

> hope of security, so they don't need dnssec for zones using wildcards.

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

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: Ólafur Guðmundsson<[email-masked]>
Date: Thu, 05 Sep 2002 00:19:17 -0400

>hope of security, so they don't need dnssec for zones using wildcards.

Paul, I hope one day to kill wild cards but there is no way that can
be done without educating the current users/abusers of wild cards how to
accomplish the same thing without wild cards.

You (as an author on a book about real popular mail delivery program)
are in much better position than most of us to explain why wildcards
are not needed for Mail delivery.

If that argument can be made, then largest current usage of wildcards
can be explained away, then we can take on the next group and so on.
Before we know it there will be no reason to use wild cards at that point
we can take on the standards action of removing wild card support in DNS.

We must not offend potential users of DNSSEC by taking away something they
depend on every day.

         Olafur

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Sep 2002 05:49:09 +0000

> accomplish the same thing without wild cards.

that's fine, though.  there are three classes of wildcard user, and none
of them is affected in any way by my proposal to preclude wildcard names
from being present in signed zones.

1. for folks who use * because they don't want to enumerate a lot of names,
they can just start enumerating those names.  it's possible that they would
then ask for opt-in depending on how many names we'd be talking about, but
they have a workaround over and above "just don't sign that zone, then."

2. for folks who use * because they cannot enumerate because the names are
not knowable in advance, dnssec would not make their zone more secure and
they should not miss it since it wouldn't do them any good anyway.

3. for folks who use * because it was in some template zone and they never
actually depend on it since their genericfrom mail addresses all end in
@DOM rather than @HOST.DOM, they can just remove the nfg *.

most uses of wildcard are of the third (completely gratuitious and unused)
kind.  i think we have overcomplicated an already fragile dnssec design and 
considerably lengthened its specification/development/deployment cycle for
the protection of wildcarding that does not matter.  the DS problem is just
the last straw for secure wildcards.  let's legislate them out of existence.

> are not needed for Mail delivery.

i see your mail here as From: [email-masked].  no wildcards are needed to
reply to it.  it's only if your mail was From: [email-masked] or
From: [email-masked] *AND* you did not want to install MX's for
both engill and mail.dc that a "* MX" would be necessary.  

> can be explained away, then we can take on the next group and so on.

go for it.

> we can take on the standards action of removing wild card support in DNS.

no.  we must not invalidate existing zones.  we can however make a sieve for
them such that only zones without wildcards can utilize the DNSSEC featureset.

> We must not offend potential users of DNSSEC by taking away something they

show me.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Sep 2002 07:40:33 -0400

>corner case you and Rob Austein investigated.

(Reading this a few days late, so this may have been answered already...)

The danger comes from NXT's whose reported owner name is the result 
of a wildcard match.  Let's say I ask for data whose QNAME that does 
not exist but matches a wildcard.  Further, the QTYPE is absent at 
the wildcard.

So there will be a returned NXT that looks like it belongs to the 
QNAME (but the SIG label count will contain info that says it is a 
wildcard).  Holding this NXT isn't dangerous, and it is fine to 
replay it (from the cache) for a repeat of the same query (QNAME, 
QTYPE, and QCLASS).

The "danger" is in the cache's trying to use the NXT to respond to 
any other query - QTYPE'.  Because the NXT is synthetic, it might be 
used incorrectly to declare QTYPE' does not exist (or that a QTYPE at 
it is absent).  So the danger is not caching the record, the danger 
is in incorrectly using the cached, synthetic NXT.

I can't think of any damage in answering with the cached, synthetic 
NXT if the QNAME is the same as the original and the QTYPE=IN.  (And 
QCLASS is appropriately set - off hand I don't know what is 
"appropriate.")
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

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

> 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: Roy Arends <[email-masked]>
Date: Thu, 12 Sep 2002 17:57:57 +0200 (CEST)

> insecure (a's NXT and SIG NXT).

Almost, you should just give out the referral (NS) and the proof that the
name is insecure (a's NXT and SIG NXT).

> secure name, since www.b.foo.com was secure in the non-optin case.

The problem is that when a query falls in an unsigned interval (yes, I
know, delegations only) there may exist an unsigned delegation for QNAME
eventhough there exist a signed wildcard.

Whenever a query hits an unsigned interval, it is useless to proof of
existing or non-existing wildcards.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Sep 2002 08:40:41 -0400

I would think [0] that if a signed positive answer is given, there is 
no reason to show that there was potentially a wildcard (signed or 
unsigned) available.  If there exists an unsigned positive answer, 
*is* there a need to prove that there is no wildcard?  I guess so, 
but this is getting sticky.

>will mean another SIG and SIG(NXT) in almost every case.

[0] Apologies - I am reviewing the thread while flying back from 
RIPE, so the reply is delayed and possibly confused.

---

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

>existing wildcard delegation is needed.

Question is: does an signed wildcard trump an unsigned delegation name?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

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:04:21 +0200 (CEST)

> Question is: does an signed wildcard trump an unsigned delegation name?

No, I don't think that is the question.

The signer of the zone has give proof that there exist no signed material
in an interval. All bets are off if you query for a record that is not
signed [1]. If the signer of the zone wants to use signed wildcards, she
should know that they can be used to spoof within unsigned intervals.

[1] Note that the response has a signed statement that the interval is not
    secure.

Proof of wildcards in a response with positive unsigned referals leads to
nothing more than ambiguity.

Roy

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 10:06:09 -0400

Edward Lewis <[email-masked]> writes:

> *is* there a need to prove that there is no wildcard?  I guess so, but
> this is getting sticky.

Note that the only "unsigned positive response" you could have is an
NS record.  I didn't think that wildcard NS records were allowed?

What it DOES mean is that you need to send twice as much data to prove
an NXDOMAIN.  It is not sufficient to just show the NXT for the
request, but you must also show the NXT for the wildcard.

-derek

> [0] Apologies - I am reviewing the thread while flying back from RIPE,
> so the reply is delayed and possibly confused.
> 
> --

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 16 Sep 2002 09:54:48 -0400

----- Original Message -----
From: "Edward Lewis" <[email-masked]>

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

Scott

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 10:10:09 -0400

> Question is: does an signed wildcard trump an unsigned delegation name?

What do you mean?  You cannot have a "*.example IN NS ..." record.
The fact that you have a signed "*.example IN MX ..." record has
nothing to do with the fact that you've got an unsigned "foo.example
IN NS .." record.

How would this trumping even happen?  The RTYPEs are different.

-derek

---

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

> 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: Paul Vixie <[email-masked]>
Date: Mon, 16 Sep 2002 14:20:52 +0000

> else needed out of the SOA RR RDATA?

if there's enough info in the signature to be able to tell what other cached
data you should preexpire, then no.  however, i don't think that's the case;
all you can know, afaik, is that the records you're holding were signed less
recently than the records you're now receiving.

---

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

At 4:04PM +0200 9/16/02, Roy Arends wrote:
>in an interval.

The problem is that, when considering wildcards, "interval" is not 
singular but plural.  E.g., there must be proof that there exists no 
signed material in each interval that a name might fit.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

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

>NS record.  I didn't think that wildcard NS records were allowed?

I don't mean to imply that there is a wildcarded NS.  E.g.,:

In my zone I have:

*          900 IN TXT  "This is a wildcard match"
                   SIG  TXT
            900 IN A    10.10.10.10
                   SIG  A
            900 IN MX   10 host
                   SIG  MX
            900 IN NXT  alpha TXT A MX SIG NXT
and

alpha      900 IN NS   nameserver
                   SIG  NS
            900 IN NXT  beta NS SIG NXT(or not)
                   SIG  NXT
alpha1     900 IN NS   nameserver
alpha2     900 IN NS   nameserver
beta       900 IN NS   nameserver
                   SIG  NS
            900 IN NXT  gamma NS SIG NXT(or not)
                   SIG  NXT
...

If I ask for (alpha3 A) I get the wildcard.  If I ask for (alpha2 NS) 
I get the unsigned alpha2 NS.  If I ask for (alpha NS) I get the 
signed alpha NS.  If I ask for (alpha3 NS) I get no such data per the 
wildcard.

The issue here is that it is easy to spoof away the signed wildcard 
with opt-in.  Let's say I do ask for alpha3 A.  Since there's an 
opt-in-ized NXT saying that alpha3 is not explicitly signed in the 
zone, all an attacker needs to do is replay this before the answer 
with the signed * match returns - or - modify a cache to strip away 
the *-synthesized records from an answer.

At first I was surprised by Scott saying that the * trumps opted-out 
data, but now I agree with him.  If you don't assume that there is a 
signed * name in the zone, then it can be spoofed away.

So, if there is an applicable * - then it would hide all the 
unsecured matched "behind it" which is counter-intuitive to the 
algorithm in rfc1034/s4.3.3.

>request, but you must also show the NXT for the wildcard.

To match an opted-out name (unsecured) you have to prove it isn't 
secured, and that there isn't a potential wildcard, the latter may 
require multiple NXT's.

Also - does the presence of an opted-out name impact the scope of a 
wildcard's matches?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 10:48:13 -0400

> signed material in each interval that a name might fit.

No, it's singular because the wildcard is applied to each request
individually.  So you need to show proof-of-nonexistence in the
query-interval on each query.  This is a seperable problem, as queries
are independent.

-derek

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 10:52:45 -0400

> the *-synthesized records from an answer.

As I said, an answer of NXDOMAIN is incomplete without _TWO_ signed
NXT records, so a client would know they were being attacked if they
only received one.  Similarly, an attacker could not add an 'A' record
to this response, because opt-in only allows unsecured delegations.

> So, if there is an applicable * - then it would hide all the unsecured
> matched "behind it" which is counter-intuitive to the algorithm in
> rfc1034/s4.3.3.

Right, but there _are_ no unsecured matches because opt-in only allows
unsecured NS, and you cannot have an NS wildcard.

> secured, and that there isn't a potential wildcard, the latter may

This is correct, but only in the case where you have a multi-layer
zone.

> Also - does the presence of an opted-out name impact the scope of a

It doesn't.  It is no worse than a non-opted-out name.

-derek

---

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: Edward Lewis <[email-masked]>
Date: Mon, 16 Sep 2002 10:40:41 -0400

>How would this trumping even happen?  The RTYPEs are different.

The trumping is whether the algorithm for looking up replies first 
checks the signed data only (hence finds the wildcard) or looks 
through all the data.

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 11:15:42 -0400

> checks the signed data only (hence finds the wildcard) or looks

The algorithm at the server or at a cache?  An authoritative server
still looks at the QNAME first.  If it finds an entry for the QTYPE,
it uses it.  It not, it checks the wildcard.

The fact that opt-in is in use doesn't change this.  Remember: only NS
records can live within an opt-in interval.  This means that the
potential states you have are:

1) signed RDATA at the QNAME and signed wildcard
        RDATA wins
2) no RDATA at QNAME and signed wildcard
        wildcard wins, but must provide the QNAME NXT
3) no RDATA and no wildcard
        NXDOMAIN; must provide both (all?) NXTs

The fact that the NXT is opt-in or not does not matter, because the only
record that can live in an opt-int interval is an NS, and you cannot have
wildcard NS.  If the QTYPE is NS, then you can ignore wildcards completely.

-derek

---

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

On Mon, 16 Sep 2002, Edward Lewis wrote:

> 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

---

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

>query-interval on each query.  This is a seperable problem, as queries

When you follow the wildcard algorithm, you need to search through 
different intervals.  First the explicit one followed by all 
intervals that might hold a wildcard.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

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

>As I said, an answer of NXDOMAIN is incomplete without _TWO_ signed

no need to yell ;)

>to this response, because opt-in only allows unsecured delegations.

Which two NXT's would be sent to prove that alpha3 A does not exist? 
(Would it be that alpha3 is not a signed name and there is no signed 
wildcard?)

>unsecured NS, and you cannot have an NS wildcard.

Remember that wildcards match names, not names&types.  If the 
wildcard has an A record and no NS record, all queries for matching 
names and (QTYPE=)NS get a NODATA response because the name matched.

>It doesn't.  It is no worse than a non-opted-out name.

Okay, I see that, because an opted out name is a zone cut.  (But what 
do you mean by "worse?")

*.zone        TXT "matches names"
               SIG TXT
...
unsec.zone    NS
...

querying for anything below unsec.zone would result in a referral 
answer.  I guess this cements the rationale to diallow non-zone cuts 
in the opted-out portion of a zone.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 11:38:25 -0400

Edward Lewis <[email-masked]> writes:

> different intervals.  First the explicit one followed by all intervals
> that might hold a wildcard.

Ahh, I see -- to collect multiple NXT records in the case of a
multi-level zone.  I keep on assuming zones with single levels.
My appologies.

-derek

---

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

>         wildcard wins, but must provide the QNAME NXT

That's wrong - NODATA @ QNAME wins...once the name matches, I stop searching.

>         NXDOMAIN; must provide both (all?) NXTs

That should be no explicit QNAME and no wildcard
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

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: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 11:43:55 -0400

> (Would it be that alpha3 is not a signed name and there is no signed

Yes.  Two two NXTs are:
        1) prove the alpha3 A does not exist
        2) prove there is no matching wildcard

> Remember that wildcards match names, not names&types.  If the wildcard
> has an A record and no NS record, all queries for matching names and
> (QTYPE=)NS get a NODATA response because the name matched.

HUH?  If I make a query for foo TXT I could get an MX response because
there is a * MX record?  Can you show me where in the RFCs that is
true?

> in the opted-out portion of a zone.

By "no worse" I mean "no different"...

The only issue is the one that Roy pointed out..  You could have an
unsigned NS and a signed "* A" and you need to figure out which one to
believe.

-derek

---

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

---

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

On Mon, 16 Sep 2002, Edward Lewis wrote:

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

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

> >unsecure delegations, and simply spoof away unsecure delegations with

Okay, lets focus on that.

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

>there is a * MX record?  Can you show me where in the RFCs that is

As I said, if (according to your example) you ask for foo TXT, you do 
not follow the wild card because foo is a name in the zone.  BIND 
9.3.3. does this.  The algorithm followed is in RFC 1034, 4.3.2, in 
particular, step 3 a.

Here's much more detail on my test.  Note that the * has an MX, and 
beached-whale does explicitly exist without an MX.  Hence, asking for 
beached-whale's MX results in no data:

[lead-arin-net:~] edlewis% dig @0 beached-whale.ed.ds.isi.edu. MX

; <<>> DiG 9.3.0s20020722 <<>> @0 beached-whale.ed.ds.isi.edu. MX
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6309
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;beached-whale.ed.ds.isi.edu.   IN      MX

;; AUTHORITY SECTION:
ed.ds.isi.edu.          900     IN      SOA 
beached-whale.ed.ds.isi.edu. edlewis.arin.net. 5 1200 300 3600 900

;; Query time: 13 msec
;; SERVER: 127.0.0.1#53(0)
;; WHEN: Mon Sep 16 11:57:11 2002
;; MSG SIZE  rcvd: 97

[lead-arin-net:~] edlewis% dig @0 ed.ds.isi.edu axfr +multiline

; <<>> DiG 9.3.0s20020722 <<>> @0 ed.ds.isi.edu axfr +multiline
;; global options:  printcmd
ed.ds.isi.edu.          900 IN SOA beached-whale.ed.ds.isi.edu. 
edlewis.arin.net. (
                                 5          ; serial
                                 1200       ; refresh (20 minutes)
                                 300        ; retry (5 minutes)
                                 3600       ; expire (1 hour)
                                 900        ; minimum (15 minutes)
                                 )
ed.ds.isi.edu.          900 IN SIG SOA 1 4 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 UhMiJQArMQyYRxAA8edEI2tynsp1klLDaWolvR+Cq8P0
                                 nXkEYdrAjnvaQ/IwILrYT9hg6z9jar7KeeJ+WrgYZg== )
ed.ds.isi.edu.          900 IN NS beached-whale.ed.ds.isi.edu.
ed.ds.isi.edu.          900 IN SIG NS 1 4 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 nrQVW6iteDqIFvsTivQ/nxRlirZYeYyiE+mw/vmkGfE7
                                 tN+a2BWA5xURifBW341j57yNZivcw6RxBOQry88o0A== )
ed.ds.isi.edu.          900 IN KEY 256 3 1 (
                                 AQPJUDzlyI3S2+ea332/86q7AyouGHidz3HeMC86UtVN
                                 68nbuRGhmHfZCSHmCSNmO2WK3mVwbTWNR2MCyGjd2eUj
                                 ) ; key id = 55781
ed.ds.isi.edu.          900 IN KEY 256 3 1 (
                                 AQPuFDhGvOx1W1csG9r1TAGEohxqLKJKFohNNDuN3r+9
                                 8EmbxVMa8VCqIwqnr3D05/ehxNJRnIqPlUGJa8EV1xcL
                                 VtbI0gV9VQ3UsvXR7w8B34/XcEZFhLB3Tx5QlaE1QbF7
                                 oftosSVQ5DJIzWHy8cnEWoBC+s3Y+yX/Y9epU8Q2eQ==
                                 ) ; key id = 50230
ed.ds.isi.edu.          900 IN SIG KEY 1 4 900 20020927193713 (
                                 20020828193713 50230 ed.ds.isi.edu.
                                 VAFn5ZZEwbWO3maEcanM5rjY1vU+m3PGJPZXMLcem8dn
                                 ZFeAA/Ve0Y8Vp8lfUGnYHIJMNm438I1LUHoDncsUEWrT
                                 pYNKyEGu/poyA5Oo2yPkUpkF3UdvtGBdU737LK8rIpWV
                                 ftmewRxC4zvmVJauJZN+xT7YWKcp6h2eg682n6U= )
ed.ds.isi.edu.          900 IN SIG KEY 1 4 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 n8N04exFheDKFo52P0QxZI+xziYXoaEbrtXtgf+Mvkiu
                                 yosVsDNT4EJPEZNuuLiAMe7cjacJAN//IQRlcsutbw== )
ed.ds.isi.edu.          900 IN NXT *.ed.ds.isi.edu. NS SOA SIG KEY NXT
ed.ds.isi.edu.          900 IN SIG NXT 1 4 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 p7r4ABIIWAOzLkb7MZvR9crQDb4ZbLRruzaMRr9XFWtf
                                 PZlv2zidWfNLDG2h0H1lrQ5bBsMd8cx8/e+zkLttew== )
*.ed.ds.isi.edu.        900 IN MX 10 smtp.ed.ds.isi.edu.
*.ed.ds.isi.edu.        900 IN MX 20 host.ed.ds.isi.edu.
*.ed.ds.isi.edu.        900 IN SIG MX 1 4 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 bzbEWzTp4BoUyspMyudPcbNalVXSY2IsyVSw7/IoUeWL
                                 nvz9JJNnbFv8hHAnoDKjqS8J0sQxg97w7omsg2dIeA== )
*.ed.ds.isi.edu.        900 IN NXT beached-whale.ed.ds.isi.edu. MX SIG NXT
*.ed.ds.isi.edu.        900 IN SIG NXT 1 4 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 HXSi3DHfN9Fv+IcUD/08YfCNPA9HqLYR0GApgVQmIUjh
                                 fv4dZW9a2LZQ202UqOdw5s1BX9bWIkYMXmPtZUoqkw== )
beached-whale.ed.ds.isi.edu. 900 IN A 65.123.202.244
beached-whale.ed.ds.isi.edu. 900 IN SIG A 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 Oo80DkHoXXTBryuwd4plMBm2W2dtdXBuPQFBYSQs909/
                                 N23p/0KLfjOz1MD0XOm1mi1qAFnlP7C+8J2MXDtpOQ== )
beached-whale.ed.ds.isi.edu. 900 IN NXT david.ed.ds.isi.edu. A SIG NXT
beached-whale.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 hGtiKOGrHUsWuIkJhZigGF3+U2tzbuCOFHbi/IDQz05G
                                 OmEje0Ta1BMi3RPvCS/eilCMwx1IykB+duJeiUQxZg== )
david.ed.ds.isi.edu.    900 IN NS vogon.david.ds.isi.edu.
david.ed.ds.isi.edu.    900 IN NXT host.ed.ds.isi.edu. NS SIG NXT DS
david.ed.ds.isi.edu.    900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 AQWxgYrY/UnAIyFUkjNTkoiSmD/iEbaWJhD8VH+MI0Ia
                                 tQdIUf927HlKaUF6pMRK9Bv/WmqwAa8SNERF4LnA2w== )
david.ed.ds.isi.edu.    900 IN DS 62959 3 1 (
                                 4A4BEC280149BFFC8268C70EC81FA9D744178F74 )
david.ed.ds.isi.edu.    900 IN SIG DS 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 Ez1mXR2VKx7MjvM856Y6UIuxCg2KoEXunh0En4cVYGBO
                                 /MbKvJPZmigTj52pnvu8+52k9X5eQI0sSbRdhGcJlA== )
host.ed.ds.isi.edu.     900 IN A 65.123.202.244
host.ed.ds.isi.edu.     900 IN SIG A 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 nRY8yYHDR5201t/hA1pX0vVVV7CmuRTTugslcfMkVSbz
                                 5QUVKx9NdBsMpOYNdLQ3mpJdfutRfyFGl5AFf9c/aw== )
host.ed.ds.isi.edu.     900 IN AAAA 2001:5ff::3
host.ed.ds.isi.edu.     900 IN SIG AAAA 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 oqP4p87CVlU03bddJMmLZf5OVnmULuY6fhXodk/bhCw6
                                 aG1Dun7pcoghs+/K3Eb5I+5yXMO/RqlHBVsixBpBKQ== )
host.ed.ds.isi.edu.     900 IN NXT _ftp._tcp.host.ed.ds.isi.edu. A SIG AAAA NXT
host.ed.ds.isi.edu.     900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 DQyvEk4aapa7/HAX/TuASbqezKd19IOZiBvRxVupuWwR
                                 agGm+wzrLh1EHmjzBb/TciPFR1Cmvo88ItnyF5gO0A== )
_ftp._tcp.host.ed.ds.isi.edu. 900 IN TXT "ftp server information"
_ftp._tcp.host.ed.ds.isi.edu. 900 IN SIG TXT 1 7 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 I2qPmjGY9egHq1WvN04Yu7pmBSLwH+no6RsWosDGKxGk
                                 kqFCf0mmm6OXCmP0tbip+PC6jAmKicsEdOoZLMbWFA== )
_ftp._tcp.host.ed.ds.isi.edu. 900 IN NXT localhost.ed.ds.isi.edu. TXT SIG NXT
_ftp._tcp.host.ed.ds.isi.edu. 900 IN SIG NXT 1 7 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 LJwFyoc2YBxBKD6jHlatX+wxXxopMPFEPMTt9sWORebQ
                                 kcwmEMaDj3jDGXDSAGWtxaccJszxmakMpmFyk2i2gQ== )
localhost.ed.ds.isi.edu. 900 IN A 127.0.0.1
localhost.ed.ds.isi.edu. 900 IN SIG A 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 LAFrBp1lLMLHoaMTrCY+ARtaKx8Oa5JDfwVtScSd5BYX
                                 3x74mtFX1ygim53vjwBx3Lv43DA8ssfLcTNbCL6atQ== )
localhost.ed.ds.isi.edu. 900 IN NXT loghost.ed.ds.isi.edu. A SIG NXT
localhost.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 h0Wg8aCFPfjkV4KykZCL7pdOc7GKe/JqcIu5yyVWYB5I
                                 vFNlxjXv4n5TCWrdhc4LBxHPV9v/2CakfNUQ2GXLmA== )
loghost.ed.ds.isi.edu.  900 IN CNAME localhost.newzone.ds.isi.edu.
loghost.ed.ds.isi.edu.  900 IN SIG CNAME 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 H0jkvprDiuDQ3KFMdEk4rAC+dBVS1L37PXVpQMoDSGkM
                                 DFgtUNgQbLg+9A8yyUrP3g2tcceNKPJ5oX1WrxfCbg== )
loghost.ed.ds.isi.edu.  900 IN NXT loopback.ed.ds.isi.edu. CNAME SIG NXT
loghost.ed.ds.isi.edu.  900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 qua6I9c61eMfmU3txLXyXaMflKa0LIDNGHyw0DLr/6lB
                                 xDtlse84K1BM7rTLRxsGZHhBuVCI9LCs7dIB1VBp/A== )
loopback.ed.ds.isi.edu. 900 IN CNAME localhost.newzone.ds.isi.edu.
loopback.ed.ds.isi.edu. 900 IN SIG CNAME 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 xzRYUs2nk3NqaOqaXaEVp73NuT945B4K5ldCt5Y8hqAa
                                 m0OsVDdnLvNpFJauXHnNAFB78VixfE6MPXWHTB+pYQ== )
loopback.ed.ds.isi.edu. 900 IN NXT sec.ed.ds.isi.edu. CNAME SIG NXT
loopback.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 XGRJn1f1ALCwcm7D66kC02PLgwOk3GB/O2kaM3+mXM9+
                                 H8ykGLpdiPK1dI4RLG7d9bC9kdWIbwCemBWCO+DqDw== )
sec.ed.ds.isi.edu.      900 IN NS beached-whale.ed.ds.isi.edu.
sec.ed.ds.isi.edu.      900 IN NXT smtp.ed.ds.isi.edu. NS SIG NXT DS
sec.ed.ds.isi.edu.      900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 qZdL5M/XGTmPnFWSLrsn5IDLUaWZA64ldymrsuXB+u04
                                 RB3oiH6ofVEAc05PkhIiSFE5e19aj+AO5VUdEG5tCQ== )
sec.ed.ds.isi.edu.      900 IN DS 41704 1 1 (
                                 FC2ADFD12402782BA6BFB4C17C5DC52A32E8DDD8 )
sec.ed.ds.isi.edu.      900 IN SIG DS 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 KXG7YeoQWU6/4GDpQVJPeGT6OJY4HB0OYq7+MvxYLRbd
                                 A/zNEuK70cCZ48jesSvXd6CHFPSpOHxpdiqWK0iISA== )
smtp.ed.ds.isi.edu.     900 IN A 65.123.202.244
smtp.ed.ds.isi.edu.     900 IN SIG A 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 EErG7nINF9UFzjHEOetkXY6ogHijhNt13Bw+3196GWgj
                                 jw0abt9+JLt9D8B6V9v0dxYIyd5FQbX99C5WPiLDKw== )
smtp.ed.ds.isi.edu.     900 IN AAAA 2001:5ff::2
smtp.ed.ds.isi.edu.     900 IN SIG AAAA 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 FhQsCREVN1YhpvKHqiQBRhQbsPmaWLvPzGYwKFCnMtYB
                                 kTZR4R3jqupnXJ8DPCJQlqqMMugmfkLe1Qe73lQ9eg== )
smtp.ed.ds.isi.edu.     900 IN NXT unsec.ed.ds.isi.edu. A SIG AAAA NXT
smtp.ed.ds.isi.edu.     900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 xZZ3MEGo4PiCKwAWBnJi5kwWSTDkXJpT6ILVo8KBKVi3
                                 IvZoGx6OOgE+J7aWcQDD+OtYs+Ujm7PCI+pqj9HriA== )
unsec.ed.ds.isi.edu.    900 IN NS beached-whale.ed.ds.isi.edu.
unsec.ed.ds.isi.edu.    900 IN NXT www.ed.ds.isi.edu. NS SIG NXT
unsec.ed.ds.isi.edu.    900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 pjX6if7tDzPuzQknIp5BXdTzrQk5zkqzxN4BksMeeVHS
                                 MQA4ATLKgPIjsCIsJN3G84tezCRPVaNGAS4n8OPK6g== )
www.ed.ds.isi.edu.      900 IN CNAME www1.ed.ds.isi.edu.
www.ed.ds.isi.edu.      900 IN SIG CNAME 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 Xf8Z+OEKVGdiZlQbati0BEzv00n3Lk1vmzCR0Xjjj13n
                                 gyc3tIe97p8irddlrDyTRLUeFMN27xEHzqugKgxbdg== )
www.ed.ds.isi.edu.      900 IN NXT www1.ed.ds.isi.edu. CNAME SIG NXT
www.ed.ds.isi.edu.      900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 f+ECccgy3GPEG4nic8GYMlxip8OgLZYXJveXygS8oaZV
                                 TByKn/oNjNkOBCZyhs1GU4IHnt6b2y7IJwtKBizoZA== )
www1.ed.ds.isi.edu.     900 IN MX 10 smtp.ed.ds.isi.edu.
www1.ed.ds.isi.edu.     900 IN MX 20 host.ed.ds.isi.edu.
www1.ed.ds.isi.edu.     900 IN SIG MX 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 dueZ7jvStmSKn6q3aOBlf1vEJiNMVKNhjrcUiwzZDdvf
                                 16VGQvqimApJgSgJStW+dHXlVyeu+5HHyDHutX2dRQ== )
www1.ed.ds.isi.edu.     900 IN TXT "no stinkin' http here"
www1.ed.ds.isi.edu.     900 IN SIG TXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 or3rujTTdX+Cuv02HFintNte6H//YLsonUGdAFSasEzT
                                 Px14yBADTC2n+7vvpFiauGbeKy8QCWR1j3fGYZb1AQ== )
www1.ed.ds.isi.edu.     900 IN AAAA 2001:5ff::1
www1.ed.ds.isi.edu.     900 IN SIG AAAA 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 dTmx3oVmTlotq8MRifZ/HfMHg8aAPEK8axOlRl1shdW8
                                 7n3Lo/w2BOEeHufImMuHFFu4DSZBj5CeZPco9DT1SQ== )
www1.ed.ds.isi.edu.     900 IN NXT ed.ds.isi.edu. MX TXT SIG AAAA NXT
www1.ed.ds.isi.edu.     900 IN SIG NXT 1 5 900 20020927193713 (
                                 20020828193713 55781 ed.ds.isi.edu.
                                 FKYpsF89LpA+MpxpZr/cnlgU0dwV7t6Lw5J12YzoLcca
                                 uv2m2X2sL9qBVy6+yty5kT6dMxrwgKZIxTrgbt+05A== )

---

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: Paul Vixie <[email-masked]>
Date: Mon, 16 Sep 2002 17:19:01 +0000

> The problem is that, when considering wildcards, ...

...DNSSEC ought not be used.

C'mon, folks.  We're already seven years into this.  Let's cut the things
that don't work and run with what's left.  I posted my analysis of various
uses for wildcards and showed why, imho, none of them intersect with a strong
need for DNSSEC.  I'm here today renewing my proposal:

	Signed zones shall not include RR's with wildcard names.

---

From: Mark Kosters <[email-masked]>
Date: Mon, 16 Sep 2002 14:10:02 -0400

> 	Signed zones shall not include RR's with wildcard names.

I agree with this. I hear what Olafur is saying about supporting wildcards
but that can be done by synthesizing the response based off a wildcard 
defined in a configuration file. 

Mark

-- 

Mark Kosters          [email-masked]       Verisign Applied Research

---

From: David Conrad <[email-masked]>
Date: Mon, 16 Sep 2002 11:34:05 -0700

This will, I'm told by folks who run large zones (other than .COM), will
result in DNSSEC not being deployed in those zones.  Doesn't seem to be an
optimal approach if we want DNSSEC deployed.

Rgds,
-drc

---

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: Roy Arends <[email-masked]>
Date: Tue, 17 Sep 2002 00:00:34 +0200 (CEST)

On Mon, 16 Sep 2002, David Conrad wrote:

> 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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 16 Sep 2002 22:35:37 +0000

>> ...  I'm here today renewing my proposal:
>> 

i either disagree or disbelieve, depending.

> Doesn't seem to be an optimal approach if we want DNSSEC deployed.

imho, wildcards will not change dnssec's deployment curve even a little bit.

---

From: David Conrad <[email-masked]>
Date: Mon, 16 Sep 2002 15:50:32 -0700

Roy,

On 9/16/02 3:00 PM, "Roy Arends" <[email-masked]> wrote:
> Could you phrase their concerns ?

"We use wildards.  Removing them would be annoying."  -- a direct quote from
someone at a RIPE meeting a while back.

> no alternative present. I can't think of any.

Nor can I.  However, does that matter?

Rgds,
-drc

---

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

> someone at a RIPE meeting a while back.

Okay, I can imagine its annoying. But I don't think "annoying" is a strong
case for keeping wildcards in DNSSEC.

> Nor can I.  However, does that matter?

No, who cares what you or I can't think of. I just want to assess
compelling and real arguments for keeping wildcards in DNSSEC ("annoying"
is not one of them), since I don't have any right now.

Roy

---

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

> > I'm looking for the case where wildcards are vital, and for which
> > there is no alternative present. I can't think of any.
> 

yes, it does.  "design" is a process involving both creativity and tradeoffs.
in order to decide whether our seven year dnssec effort should be turned into
an eight or nine year dnssec effort, we need to know exactly how important
wildcards are and to whom.

several of us here have asserted that there are workarounds for all common
cases and that we can cut wildcards out of the dnssec specification with no
actual loss of functionality.  one of us has even enumerated the common cases.

the onus is now on the other side of the argument.  if there's a common case
we've missed, or an uncommon case that's vital, then enumerate it.  if our
analysis of the common cases was faulty, then correct us.  but don't just
say "if we don't have wildcards, dnssec is not worth doing" because the
argument has since moved to more detailed ground where actual facts are
going to be required to keep it from ending in the "no wildcards in dnssec"
mode.

---

From: David Conrad <[email-masked]>
Date: Mon, 16 Sep 2002 18:29:02 -0700

On 9/16/02 4:14 PM, "Paul Vixie" <[email-masked]> wrote:
> the onus is now on the other side of the argument.

Hmmm.

Way back in a previous life when I was trying to encourage people to use
DNSSEC and I mentioned BIND didn't support signing zones with wildcards in
them, the vast majority of responses were along the lines of "too much of a
hassle to redo the way we're doing business, particularly as we haven't seen
any attacks that DNSSEC would have helped against, so I guess we won't be
signing our zones".

Perhaps times have changed and the folks who host zones with wildcards in
them might consider taking the onus upon themselves to argue as you assert
they must.  

Or perhaps not.  Particularly given those folks are not likely to found on
namedroppers.

Seems to me if you want to keep DNSSEC from ever getting deployed, then
creating yet another barrier to entry by removing wildcards is a step in the
right direction.

Rgds,
-drc

---

From: David Terrell <[email-masked]>
Date: Mon, 16 Sep 2002 20:07:13 -0700

> going to be required to keep it from ending in the "no wildcards in dnssec"

If I'm a major website that puts different content under different
DNS names, it sure would be nice to catch misspellings and try to
redirect them to an appropriate page without turning an 8 name zone
into a 500 name zone.  Cuts down on the NXT record generation, for
one thing.

I would, however, like to be able to secure the records in this zone,
so that my server addresses can't be spoofed.

How about this:
"A signed zone with a signed wildcard SHOULD NOT have any unsecured
labels."

That eliminates any funny business.  You're not going to put a *
record in .com anyway.  I thought that partially secured zones were
mostly a "only use this if you have a real reason to" thing anyway.

-- 
David Terrell           | If a crypto algorithm is cracked in a forest
Nebcorp Prime Minister  | and a tree falls on a mime, does microsoft
[email-masked]            | need to publish an advisory on it?
http://wwn.nebcorp.com/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 17 Sep 2002 04:08:31 +0000

> any attacks that DNSSEC would have helped against, so I guess we won't be

that turned out to be a good thing, too.  those folks might've ended up using
pre-DS, or using RSA keys, or any of the other things that dnsext/dnssec has
sent to the IESG even though we clearly weren't done baking them yet.

but more fundamentally, i dispute that lack of wildcarding has ever stopped
anyone, even one user, from signing a zone that they would otherwise have
signed.  and also, a continued lack of wildcarding will not stop anyone from
signing a zone that they otherwise want to sign.  whether they otherwise
want to sign or not is the important question, and that will have to do with
factors like a stable specification, decent tools, useful documentation, and
a sense that other people are actually using this stuff.

> Or perhaps not.  Particularly given those folks are not likely to found on

i think name service providers (such as nominum, ultradns, and lots of others)
have employees on this list who know what their customers are using DNS for,
and that this is a fine place to do "feature research" of this kind.  but if
you know of another place, please suggest it.

> Seems to me if you want to keep DNSSEC from ever getting deployed,
> then creating yet another barrier to entry by removing wildcards is a
> step in the right direction.

in december, in salt lake city, the DS plan was hatched and campaigned for,
and my support for it (as well as for opt-in) was contingent on a quick close.
that hasn't happened.  best case, it'll be december -- a full year later --
before we're done arguing about how to prove the unknown (sign wildcards) and
are ready to ask IESG for a last call on some form of dnssec, with or without
opt-in but probably with DS.

unless someone comes forward and says "here is a case of wildcard usage for
which there is no workaround, and here's why the kind of zone or user who
needs it is critical to the success of a dnssec rollout" then there is just
no basis for continuing the argument.

---

From: [email-masked]
Date: Tue, 17 Sep 2002 15:24:54 +1000

> no basis for continuing the argument.

	Well gatewaying of ACSNet mail (*.oz.au) would have been
	such a case.  No node in ACSNet knew all the other nodes
	so it was impossible to enumerate the space.  However not
	being able to spoof the wild card MX's would have prevented
	mail being intercepted.

	To mail to foo.bar.xxx.oz.au you only needed to know how to
	reach a machine in xxx.oz.au.  You had to ensure that one of
	you machines was visible but not all of your machines.

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Sep 2002 11:12:36 +0300

> Signed zones shall not include RR's with wildcard names.

<since we seem to be in repeat mode>

unfortunately this won't fly.  enum alone has a serious need
for it.

randy

---

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: Roy Arends <[email-masked]>
Date: Tue, 17 Sep 2002 11:41:10 +0200 (CEST)

> unfortunately this won't fly.  enum alone has a serious need

The enum WG is well aware that the use of wildcard NAPTR RRs are A Bad
Thing. They seriously advice against it, and advice to simply enumerate
every number that is in the repository of the zone.

Regards,

Roy

---

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

> >From exactly where do people dream up these restrictions?

....

> 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: David Conrad <[email-masked]>
Date: Tue, 17 Sep 2002 10:51:09 -0700

Paul,

On 9/16/02 9:08 PM, "Paul Vixie" <[email-masked]> wrote:
> signed.  

I am not saying it has.  What I am saying is that removal of functionality
from the DNS that people use today is going to impede the deployment of
DNSSEC in the future.

> before we're done arguing about how to prove the unknown (sign wildcards)

It is not unknown.  There is at least one implementation that fully supports
wildcards in DNSSEC.

Rgds,
-drc

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Sep 2002 22:02:12 +0300

> no alternative present. I can't think of any.

   *.3.3.e164.arpa NAPTR ...ldap...

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Sep 2002 22:12:07 +0300

> every number that is in the repository of the zone.

that's really gonna work great for anything larger then andora

randy

---

From: Paul Vixie <[email-masked]>
Date: Tue, 17 Sep 2002 19:17:58 +0000

> that's really gonna work great for anything larger then andora

that's off-topic for us.  anyone who wants to change the way enum works
should issue their opinions over on the enum wg's list.

---

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 18 Sep 2002 13:02:14 +0300

> should issue their opinions over on the enum wg's list.

i have been on enum since day zero.  and enum works

so i guess we agree.

randy

---

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

---

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

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

> 	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

---

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

---

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

> 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

---

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

> 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

---

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

> be fun - not. But then, I'd not call delegations failing these validity

	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