Subject: NS, *, and DNSSEC

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Feb 2005 17:17:46 -0500

In writing up a seciton on the interaction of NS's, *'s and DNSSEC, I 
found a problem.

This comes from the Nove IETF meeting:

    For example, a zone has the following records (not complete):

        *.example. IN 3600 NS bogon.example.
        *.example. IN 3600 NSEC twn.example. NS NSEC RRSIG

        twn.example. IN 3600 NSEC twp.example. ...
        twn.example. IN 3600 RRSIG NSEC ... signed by example. ...

        twp.example. IN 3600 NSEC example. ...

    The query is for: two.example. IN NS

    The response is :
       Authoritative Answer, response code of no error
       Answer:
         two.example. IN 3600 NS    bogon.example.
       Authority:
         twn.example. IN 3600 NSEC  twp.example. ...
         twn.example. IN 3600 RRSIG NSEC ... signed by example. ...

What I've noticed is that there is no signature over the NS in the 
answer section.  It's not there because the signer would not have 
signed the *.example NS record - valid because if I were looking for 
www.*.example, this behaves as any other delegation.

But without the RRSIG (NS), there's a tear in the fabric of DNSSEC.

Let's say that there is no wildcard NS set.  The response for the 
query would then be:

       Authoritative answer, authoritative name error:
       Answer:
       Authority:
         twn.example. IN 3600 NSEC  twp.example. ...
         twn.example. IN 3600 RRSIG NSEC ... signed by example. ...
         example.     IN 3600 NSEC  a.example. ...
         example.     IN 3600 RRSIG NSEC ... signed by example. ...

This shows there is no "two.example." and no "*.example."

This message is vulnerable to a substitution of this:
       Authoritative Answer, response code of no error
       Answer:
         two.example. IN 3600 NS    bogon.example.
       Authority:
         twn.example. IN 3600 NSEC  twp.example. ...
         twn.example. IN 3600 RRSIG NSEC ... signed by example. ...

There is no way to tell that the latter response was substituted for 
the first.  If the client asks the authority for "*.example" with 
type ANY, then the client can deduce a problem as an afterthought.

OTOH, the client will probably detect that the zone is signed, hence 
seeing an unsigned answer is suspicious and will probably reject the 
answer.  However, the latter answer would be legit given the example 
zone data.

This is a really small and annoying corner case, no doubt.  I don't 
like it because it means there is a point of ambiguity in the 
protocol, a non-determinism.  We had the same problem with opt-in.

It's probably not right to sign *-owned NS records not at the apex, 
but that is what would be needed for this particular record.  I doubt 
that we would want the servers have to hold signatures for all 
wildcards and only dole them out when the wildcards are in answer 
sections (i.e. expanded).

Suggestions?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Feb 2005 17:29:58 -0500

A problem with the problem... the *.example. NSEC shouldn't exist.

At 17:17 -0500 2/7/05, Edward Lewis wrote:
>In writing up a seciton on the interaction of NS's, *'s and DNSSEC, 
>I found a problem.
>
>but that is what would be needed for this particular record.  I 
>doubt that we would want the servers have to hold signatures for all

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Feb 2005 17:31:31 -0500

Forget the problem with the problem, the problem was correct before it.
(My mind's fuse blew when writing this.)

At 17:29 -0500 2/7/05, Edward Lewis wrote:
>>signed the *.example NS record - valid because if I were looking 
>>for www.*.example, this behaves as any other delegation.
>>
>>There is no way to tell that the latter response was substituted 
>>for the first.  If the client asks the authority for "*.example" 
>>with type ANY, then the client can deduce a problem as an 
>>afterthought.
>>
>>OTOH, the client will probably detect that the zone is signed, 
>>hence seeing an unsigned answer is suspicious and will probably 
>>reject the answer.  However, the latter answer would be legit given 
>>the example zone data.
>>
>>doubt that we would want the servers have to hold signatures for 
>>all wildcards and only dole them out when the wildcards are in 
>>answer sections (i.e. expanded).
>>
>>Suggestions?
>>--

---

From: Roy Arends <[email-masked]>
Date: Tue, 8 Feb 2005 09:33:01 +0100 (CET)

> sections (i.e. expanded).

You must include the appropriate NSEC (and concomitant RRSIG) to prove
that the delegation is not secured.

So, in your latter example:

You MUST include a NSEC for two.example. In this case:

(but then with expanded wildcard).

In other words, a resolver would drop the response.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Feb 2005 08:26:37 -0500

>that the delegation is not secured.

Why "must include?"  This isn't a delegation, it's an authoritative 
answer.  By virtue of following what is in 1034/4.3.2/3.c instead of 
b, we aren't dealing with a delegation point.

>In other words, a resolver would drop the response.

The problem is that when we decide to let the server treat the 
expanded wildcard NS as "just other data" we are messing with the 
signer and validator's mind.  If we were to revert to treating the * 
NS expansion as a cut point, the signer and validator are happy, but 
the server is different.

Options are (I am including discarded ones for completeness):

1) Alter the name servers to never accept a * NS record, whether via 
zone load, AXFR, IXFR, or dynamic update.

2) Alter the algorithm in 4.3.2 to exclude expanding NS records in 
step 3, part c.

3) Alter the rules in the signer to apply the signature to a * NS and 
then instruct the server to not include the RRSIG when adding this to 
the authority section.

Option 3 is complicated because there is one execution path that goes 
through part b (the referral message result) that needs to be 
maintained as legal.

I'm not as worried that we need to instruct the validator to 
understand this, that's the easy part.  The problem is that we have a 
situation in the protocol where there are two distinctly different 
yet plausible answers to a query.  The validator cannot distinguish 
which is right - meaning we are failing the source authenticity and 
data integrity goals.

Before getting too excited about this, this is a really rare corner 
case we are talking about.  The QTYPE has to be NS for this to come 
up, and rarely does anyone ask for the NS set outside of debugging 
operations.  (Wildcards are not expanded in the authority section.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Roy Arends <[email-masked]>
Date: Tue, 8 Feb 2005 16:47:35 +0100 (CET)

I envision endless discussion over beer... (the beer makes it A Good
Thing).

> b, we aren't dealing with a delegation point.

Ah, not a delegation, eh ?

Okay, why wouldn't this NS set be signed ?

dnssec-records:

   The NS RRset that appears at the zone apex name MUST be signed, but
   the NS RRsets that appear at delegation points (that is, the NS
   RRsets in the parent zone that delegate the name to the child zone's
   name servers) MUST NOT be signed.  Glue address RRsets associated
   with delegations MUST NOT be signed.

Note that wildcard NS records are not 'zone cuts' or delegation points by
your reading of the algorithm in 1034/4.3.2/3

Roy

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Feb 2005 11:09:32 -0500

>Ah, not a delegation, eh ?

Not in this context, no.

>Okay, why wouldn't this NS set be signed ?

Because in another context it is a delegation. ;)

(Ever take a Quantum Physics course?)

>your reading of the algorithm in 1034/4.3.2/3

'Zactly.

There are two frames of reference.  In one, the observer is standing 
still, looking at the tree.  To this observer, the * NS is a zone 
cut.  In the other frame of reference, the observer is moving along 
the execution path of a response and falls into step c (authority 
record synthesis) and not step b (referral across a zone cut), 
concluding that the answer is not a zone cut.

Both observers are witnessing the same structure.

Ergo, the speed of light is a constant for the given medium.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Roy Arends <[email-masked]>
Date: Wed, 9 Feb 2005 11:46:25 +0100 (CET)

> (Ever take a Quantum Physics course?)

The moment I tried to observe the course, it ceased to exist.

> Ergo, the speed of light is a constant for the given medium.

Actually, what I tried to argue here is that in any way, shape or form, a
wildcard NS RRset is NOT (as in NEVER) a zone cut. I know this is a long
shot, but 1034/4.3.2/3 backs the argument.

The first observer would therefor never observe a zone cut.

Roy

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Feb 2005 19:57:27 +0700

Date:        Wed, 9 Feb 2005 11:46:25 +0100 (CET)
    From:        Roy Arends <[email-masked]>
    Message-ID:  <[email-masked]>

  | Actually, what I tried to argue here is that in any way, shape or form, a
  | wildcard NS RRset is NOT (as in NEVER) a zone cut. I know this is a long
  | shot, but 1034/4.3.2/3 backs the argument.

You're right, and wrong ... a wildcard is never a zone cut, but a '*'
as a label can be.   The problem is that nothing ever prohibited '*' from
being either a character in, or the whole text of, a label in a domain
name.   All that was done was to make it be the representation of a
wildcard when a wildcard is needed.

  | The first observer would therefor never observe a zone cut.

Someone will, if they query for x.*.example. in the example given in the
earlier message.   They'll get a referral to bogon.example. when the
server for example. is queried.

There's no way to run the algorithm without this happening, as the wildcard
stuff only ever happens when there isn't an exact match (a case independent
exact match of course...) between the label in the QNAME and a label in the
zone being searched - and here that exact match exists (strcmp("*","*") == 0).

kre

---

From: Edward Lewis <[email-masked]>
Date: Wed, 9 Feb 2005 08:46:49 -0500

>shot, but 1034/4.3.2/3 backs the argument.

One problem here is in the terminology.  "A wildcard NS RRset" has a 
fuzzy meaning.

In the draft I use the idiom "source of synthesis."  This is the 
domain name that is consulted to synthesize records in 3c.  Such a 
domain name has to "begin with" an asterisk label, the rest of the 
domain name is the closest encloser.   Only in this role does being a 
wildcard have any special meaning.

("Begin with" doesn't precluse there being subdomains of the name, 
they just don't matter.)

The reason a source of synthesis (well it's not "never a zone cut" 
but it) "never acts like a zone cut" is because in 3c, where the 
chimera called a source of synthesis briefly appears, there is no 
provision for a referral message reply.

Outside of step 3c, wild card domain names really have no 
significance.  (A source of synthesis is <asterisk label>.<closest 
encloser> - and there is no closest encloser until you define one, in 
3c.)  From that rule, a domain name starting with an asterisk label 
can be a cut point.

I've been mulling this over and it isn't a problem in base DNS, it's 
a problem in the definition of DNSSEC.  I have come to believe that 
we ought *not* to restrict * NS and still think so.  I toyed with 
suggesting that we say in 3c that * NS is never expanded, but this 
would mean a change to all the legacy name servers.  If DNSSEC were 
to fail, we'd have made a permanent change for a temporary problem.

Perhaps what is needed are some rules added to DNSSEC processing. 
I.e., a signer does sign a * NS set.  A server does not include the 
RRSIG(NS) in the authority section in step 3b.  A validator is given 
the proper authorization information regarding the signer name in the 
RRSIG(NS).

>The first observer would therefor never observe a zone cut.

Usually because first observers wind up with an arrow in the back. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 9 Feb 2005 08:53:09 -0500

>server for example. is queried.

I don't think that is right - they'd get a referral to *.example.  We 
don't "expand" the wildcard in 3b.

NSD 2.2.0 does it that way...the other implementation I tried 
wouldn't let me load a "* NS."

>zone being searched - and here that exact match exists (strcmp("*","*") == 0).

Right - that's step 3c.

PS -> (strcmp(label,"*") == 0) || (strcmp(label,"\*") == 0)
       || (strcmp(label,"\042") == 0)

You can't escape the asterisk...;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 Feb 2005 04:44:31 +0700

Date:        Wed, 9 Feb 2005 08:53:09 -0500
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06200702be2fc4f021a8@[192.168.1.103]>

  | I don't think that is right - they'd get a referral to *.example.  We 
  | don't "expand" the wildcard in 3b.

Difference in terminology, I meant they'd get an NS record with bogon.example
in the RDATA (difference between "referral to" and "referral for")

I don't think we have a different opinion on what actually happens.

  | PS -> (strcmp(label,"*") == 0) || (strcmp(label,"\*") == 0)
  |        || (strcmp(label,"\042") == 0)
  | 
  | You can't escape the asterisk...;)

I expect this is humour, but it flew right past me ... For C, "\*"
is identical to "*", so you most probably meant "\\*" in that second
strcmp, but all those would be incorrect.

When loading the zone file, any escape processing would (should) have
been done when it was loaded, leaving just the desired name in the zone.
So * \* and \042 all result in a "*" label in the zone data.   You don't
want to be repeating all of that for every query (quite apart from the
possibility to make a mess of it - "\*" added to a zone via dunamic update
is a 2 character label, \* in a master file is one...)

If the "label" in your strcmp was from the QNAME, then a query for
"\*" (not a C string, just 2 characters) would certainly only reference
'*' RRs when that '*' is in its wildcard role.

kre