[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MagicType draft
On Tue, 16 Nov 2004, Miek Gieben wrote:
> Hello,
>
> this is the draft explaining the MagicType option we have for
> the new nsec. Draft is below.
I _love_ the name.
I don't like subtyping in DS records, why not a different type altogether.
I don't understand the need for 8 bits to distinguish between
noerror/no-data and nxdomain. 1035 specifies 4 bits, and 2671 specifies 8
more, so 12 in total. Furthermore, this implies you are able to sign
rcodes such as SERVFAIL or NOTAUTH or NOTIMP. What is the purpose of that
?
Why not use type=255 (ANY) to claim that no name exist (NXDOMAIN), while
any other type denies the type.
With that, you don't need a seperate BERT record to deny records.
You can just use SIG(qtype,qname,qclass), as I proposed some months ago
[see below]. If you really want to distinguish between these and static
signatures, use the subtyping hack for the signature algorithm.
Roy
----------------------------------
Date: Fri, 18 Jun 2004 12:50:25 +0200 (CEST)
From: Roy Arends <roy@dnss.ec>
To: dnssec@cafax.se
Subject: continued: rrsig(qtype)
Hi,
A short write-up for working with dynamically generated RRSIGs, for those
who are interested.
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
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>