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