Setup a DNSSEC with my own public and private key

[Edward Lewis]

At 13:24 +0100 6/28/04, Jim Reid wrote:
>>>>>>  "Manuel" == Manuel Gil Perez <manuel at dif.um.es> writes:
>
>     Manuel> Hi and thanks both Jim and Edward.  Currently, the
>     Manuel> dnssec-* tools permit to sign the zones and authenticate
>     Manuel> the source of a dynamic update. The user can check this
>     Manuel> signature for testing out the integrity/authenticity of
>     Manuel> the responses but, how the user can be sure that this
>     Manuel> signature is of trust??
>
>I'm not sure I understand the question. The decision about trusting
>(or not) a SIG(0) key pair is simple. If the DNS administrator trusts
>a particular key, he/she puts it in the zone file and has an
>allow-update{} or update-policy{} clause which determines what update
>requests are allowed or denied with that key. If a key isn't trusted,
>the DNS administrator simply shouldn't be introducing it to their name
>servers. Except perhaps to put it in an ACL which defines clients that
>aren't allowed to update anything. Which isn't really necessary since
>the BIND9 default is to reject all dynamic updates except for those
>that are explicitly allowed.

I think the question is a two part-er. ;)

Signing zones and authenticating dynamic updates use similar tools, 
but are very different operations - and involve very different trust 
models (arrangements).

Signing a zone is from an administrator to anyone out there.  It's 
like this - imagine a produce vendor at a market.  He has a array of 
vegetables on a cart that customers can inspect.  People "trust" the 
carrot they want is good by inspection, and place a little trust in 
the vendor as he is there, and he is part of the market.

In DNSSEC, the signed zone data is evaluated by the receiver 
(resolver or customer).  More significantly than in the market 
analogy, the signed data relies on a chain of keys to someplace the 
receiver trusts.  E.g., the receiver may trust the root, who vouches 
for com, who vouches for the zone of data.

In this case, testing if the "signature is of trust" means testing 
what a receiver would experience.  That would be hard to do 
completely.  You never know what receivers trust.  The best you, as a 
zone admin can do is make sure that your parent delegates cleanly to 
you, and that you sign cleanly.  The only real test is to set up a 
resolver with the root key(s) and see what happens.

Authorizing dynamic updates is much different.  It is a private 
arrangement between the updater and the zone.  In this case, the zone 
is the one evaluating trust in the signature, the reverse of zone 
signing.  The concept of a chain of trust is much less important, as 
the usual case is a member of my staff will be the one updating the 
zones.  (So, I can give them keys ahead of time and configure them in 
my server.)

I can use public key for this, but again, it'll probably be the case 
that all the keys needed to verify the request will be in my zone and 
therefore locally trusted.

To see if update signatures are accepted, all the debugging work is 
on the updated server - it should log these events as security or 
update categories.  (I'd have to re-read the ARM to make sure.) 
There's no external work to do for trouble shooting this.

Any closer to an answer?  I may have misunderstood the question.

>
>     Manuel> For this, I'd like to establish my keys where the PKI
>     Manuel> provides this trust.
>
>Hmm. I can't see how that could work unless the name server was able
>to authenticate things like X.509 certificates. Good luck writing up
>an internet draft for that and steering it through the IETF. :-)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.