[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnssec@cafax.se
From: Roy Arends <roy@dnss.ec>
Date: Sat, 19 Jun 2004 18:00:34 +0200 (CEST)
Sender: owner-dnssec@cafax.se
Subject: continued: rrsig(qtype)

Hi,

According to some private mail, the interest in the rrsig(qtype) approach
is fairly big, and folks would like to see a draft of it, so here is a
short write-up from a braindump on dynamic rrsig(qtype) denial as an
alternative for NSEC. I'll draft this braindump and send it in as
individual submission to the wg.

View quick pro's of this approach:

  NO MORE WILDCARD PROCESSING. Wildcard expansions are dynamically signed.
  Special processing due to (absence of) wildcards is therefor not
  necessary.

  NO MORE NSEC. No traversal possible.

  Less RRtypes in message

View quick con's of this approach:

  Asynchronous crypto, which may lead to DDoS attack.
  No support for this approach yet in existing standards and software.

Since there is no more NSEC, resolver has to be able to understand
rrsig(qtype). In a response, this would be a RRSIG(X) without accompanying
X, where X is either QTYPE or ANY.

notes:
(1) a signature for a non-existant name is generated as follows:

    sign(RRSIG_RDATA | QNAME | QCLASS ) where type covered field=ANY

(2) a signature for a non-existant type is generated as follows:

    sign(RRSIG_RDATA | QNAME | QCLASS ) where type covered field=QTYPE

(3) a signature for a expanded wildcard is generated as follows:

    sign(RRSIG_RDATA | RR(1) | RR(2) .. ) where RR(N) is the expanded
    wildcard.

The resolver never has to consider proof of wildcards. Just as with
vanilla DNS, a resolver is completely oblivious that this was a
dynamically signed synthesised record using wildcard expansion instead of
a pre-signed static record.

Operational detail:

It is recommended to use a unique zone-key per authoritative server. The
apex keyset might look as follows:

example. IN DNSKEY ksk 000 ; key-signing-key
example.    DNSKEY zsk 001 ; offline zsk for pre-signing.
example.    DNSKEY zsk 111 ; online zsk for dyn-signing by ns1.example.
example.    DNSKEY zsk 222 ; online zsk for dyn-signing by ns2.example.
example.    DNSKEY zsk 333 ; online zsk for dyn-signing by ns3.example.
example.    DNSKEY zsk 444 ; online zsk for dyn-signing by ns4.example.
example.    DNSKEY zsk 555 ; online zsk for dyn-signing by ns5.example.
example.    RRSIG DNSKEY 000
example.    RRSIG DNSKEY 001
example.    RRSIG DS 001 ; pregenerated denial for DS@child

Responses coming from ns3.example would have dynamically generated RRSIGs
by DNSKEY 333, etc.

The RRSIGs which are dynamically signed are marked with '!!' for clarity.
Note that it is not possible for the resolver/validator to notice the
difference between a dynamically signed and a pre-signed RRSIG (which is
good).

Denial for DS for unsigned delegations and at the apex is pregenerated.

In the response types below, only A.2 and A.3 have dynamically generated
RRSIG's. A.1 might have one if this is an expanded wildcard. The set below
covers the entire spectrum.

A.1 Answer

   A successful query to an authoritative server. No dynamically generated
   RRSIG in this response type, unless this in an expanded wildcard. In
   that case the (!!) marked RRSIG record is dynamic.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   x.w.example.        IN MX

   ;; Answer
   x.w.example.   3600 IN MX  1 xx.example.
   x.w.example.   3600 RRSIG  MX ..           (!!)

   ;; Authority
   example.       3600 NS     ns1.example.
   example.       3600 NS     ns2.example.
   example.       3600 RRSIG  NS ..

   ;; Additional
   xx.example.    3600 IN A
   xx.example.    3600 RRSIG  A ..
   xx.example.    3600 AAAA   ..
   xx.example.    3600 RRSIG  AAAA
   ns1.example.   3600 IN A   ..
   ns1.example.   3600 RRSIG  A ..
   ns2.example.   3600 IN A   ..
   ns2.example.   3600 RRSIG  A ..

A.2 Name Error

   An authoritative name error.  The special RRSIG RR proves that the name
   does not exist.

   ;; Header: QR AA DO RCODE=3
   ;;
   ;; Question
   ml.example.         IN A

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ...
   example.       3600 RRSIG  SOA ...
   ml.example.     600 RRSIG  ANY ...   (!!)

   ;; Additional
   ;; (empty)

A.3 No Data Error

   A "NODATA" response.  The special RRSIG RR proves that the name exists
   and that the requested RR type does not.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   ns1.example.        IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   example.       3600 IN SOA ...
   example.       3600 RRSIG  SOA ...
   ns1.example.    600 RRSIG  MX ...   (!!)

   ;; Additional
   ;; (empty)

A.4.1 Referral to Unsigned Zone

   Referral to an unsigned zone.  The special RRSIG RR proves that no DS
   RR for this delegation exists in the parent zone. Not that the special RRSIG
   RR to signal absence of DS is not dynamically generated, hence no dynamic
   generation of RRSIG

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.b.example.       IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   b.example.     3600 IN NS  ns1.b.example.
   b.example.     3600 IN NS  ns2.b.example.
   b.example.     3600 RRSIG  DS ..

   ;; Additional
   ns1.b.example. 3600 IN A
   ns2.b.example. 3600 IN A

A.4.2 Referral to Signed Zone

   Referral to a signed zone.   The DS RR contains the data which the
   resolver will need to validate the corresponding DNSKEY RR in the
   child zone's apex.

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.a.example.       IN MX

   ;; Answer
   ;; (empty)

   ;; Authority
   a.example.     3600 IN NS  ns1.a.example.
   a.example.     3600 IN NS  ns2.a.example.
   a.example.     3600 DS ...
   a.example.     3600 RRSIG  DS ...

   ;; Additional
   ns1.a.example. 3600 IN A
   ns2.a.example. 3600 IN A

Roy

Home | Date list | Subject list