Subject: Wildcard NS and DNSSEC

From: David Blacka <[email-masked]>
Date: Fri, 24 Oct 2003 17:09:05 -0400

I think that there is a conflict between the wildcard clarify and
DNSSEC.  Section 6.2 of wildcard-clarify says (essentially):

   Is it not a protocol error to have a NS RR owned by a wild card
   domian name, complimentary to the case of a SOA RR.  However, for
   this to work, an implementation has to know how to synthesize a
   zone.

In other words, wildcard NS records are technically legal.  I am
not taking a position on whether or not they should be legal.

However, I cannot see how they work with DNSSEC.  Imagine your fancy
zone, example.net:

   example.net IN SOA ....
   example.net IN RRSIG SOA ...
   ...
   *.example.net IN NS ns1.super-wcard.example.com.
   *.example.net IN NS ns2.super-wcard.example.com.

(ns1 & ns2 are nameservers that can synthesize entire zones ending
with example.net).

Continue to imagine that example.net is signed.  And now imagine a
referral generated by this wacky wildcard:

  QUESTION
     foo.example.net  IN A
  ANSWER
  AUTHORITY
     foo.example.net IN NS ns1.super-wcard.example.com.
     foo.example.net IN NS ns2.super-wcard.example.com.
     f.example.net IN NSEC g.example.net A RRSIG NSEC
  ADDITIONAL
     ...

Ok, so like a normal positive wildcard match, a NSEC record is
included to show that there wasn't a non-wildcard record that should
have matched or blocked.  BUT, since delegation NS sets aren't signed,
there is no RRSIG for the referral itself.

For starters, I know for certain that this will not validate.  It
looks just like an Opt-In response (except for the NSEC bit on the
NSEC record), and we have some experience with unaware validators
choking on this sort of response.  Additionally, you might be able to
see that part of the standard wildcard validation is missing: proof
that (at least) the wildcard actually exists.  This is, IMHO, because
a wildcard NS RRset is a truly odd thing: the zone is synthesizing
records for which it isn't even authoritative.

I suppose that it might be possible to handle this by adding another
NSEC record for the wildcard, which may solve some nagging security
issues, but would be a pretty odd special case.

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

--
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: Sun, 26 Oct 2003 15:11:59 -0500

On Sunday 26 October 2003 06:11 am, [email-masked] wrote:
> 	perhaps this is the distinction btwn
> 	"newtonian DNS" and "quantum DNS" ... :)
>
> 	what would the zone "*.example.net" look like?
> 	specifically the SOA.

Why does this matter?

In my mind, the zones are not necessarily represented by a bunch of wildcard 
records.  It would be sufficient to write a special authoritative server that 
just had rules for generating the correct responses base on the query.

> 	-IF- we go this far, then an NSEC rr for the wildcard
> 	would be useful.

-IF- we went this far, the validator wouldn't just need the NSEC record, it 
would need to know what to do with it.