To:
Roy Arends <roy@dnss.ec>
cc:
dnssec@cafax.se
From:
Paul Wouters <paul@xelerance.com>
Date:
Mon, 21 Jun 2004 12:30:12 +0200 (MET DST)
In-Reply-To:
<Pine.BSO.4.56.0406191746110.30010@trinitario.schlyter.se>
Sender:
owner-dnssec@cafax.se
Subject:
Re: continued: rrsig(qtype)
On Sat, 19 Jun 2004, Roy Arends wrote: > 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. I missed some of the previous discussion, but how does this dynamicly signing work? It seems from below that I would have to not only add a bunch of keys (per master/slave) but also have to keep those available online, instead of on the super-secure signing-machine. Even if this approach is optional, I think it would be a very bad practise to promote. Also, if the nameservers needs to use crypto, it will use significant resources and can be easily DDOS'ed. And if hacked, they can be manipulated to serve changed zone data which is signed in this new "dynamic" way. Seperating the signing from the serving of data was in my view an essential part of dnssec security. > 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 This will significantly increase data transfer. If I understood you right, this is mandatory, since we need dynamic signing for a signed denial of existence. > 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 no DS RR "should" exist? You can't proof anything about the parent. I personally think this causes much more headaches then it solves. DNS data is public, even the .com zone. Don't contaminate the protocol to hide public data. Paul