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