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