Setup a DNSSEC with my own public and private key
Edward Lewis
edlewis at arin.net
Mon Jun 28 13:31:52 UTC 2004
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.
More information about the bind-users
mailing list