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


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


Home | Date list | Subject list