Brian Kroth <bpkr...@gmail.com> wrote:
>
> > RFC 4035 sec 2.2 says
> >
> > There MUST be an RRSIG for each RRset using at least one DNSKEY of
> > each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
> > itself MUST be signed by each algorithm appearing in the DS RRset
> > located at the delegating parent (if any).
> >
> > This says to me that you can have extra DNSKEY records (that don't yet have
> > a corresponding DS pair upstream), but not extra DS records (that don't yet
> > have a corresponding DNSKEY downstream), since every DS records must have a
> > key and sig associated with it.
Be careful: this paragraph is about zones that are signed with more than
one algorithm. It says that you can't have a DS record for an algorithm
that isn't used to sign a zone. It's fine to have DS records without
matching DNSKEY records, provided there is another DS with the same
algorithm that does have a matching DNSKEY record.
> > This says to me that the RFC also acknowledges that things might/will get
> > out of sync due to caching in DNS, but doesn't describe to me what resolvers
> > do in that context. Do they complain that the DS they happened to choose to
> > look for a valid chain of trust didn't work and throw the whole thing out,
> > or do they just move along to the next one in the hopes that it might
> > succeed?
The latter.
> Given the latest RFC evidence I posted, I think my summary view is as follows,
> please correct me if it seems wrong:
>
> 1) DS records are just used to validate the chain of trust upstream for DNSKEY
> records found downstream, so there MUST exist a DS record for each
> DNSKEY/RRSIG chain you intend to have used for validating RRSIGs (though not
> for just standby keys that are listed in DNSKEY records but not signing), but
> there need not exist a DNSKEY/RRSIG chain for each DS record (which is what
> contradicts 4035 2.2). So, we could prepublish DS records without an issue,
> but DNSKEYs that are published must be validated by an existing chain of trust
> (DNSKEY/DS pair) before they can be used to validate other RRSIGs.
That doesn't sound quite right to me. It's probably easiest to work
upwards:
Each RRset in a zone must be signed by a private key corresponding to one
of the zone's DNSKEY RRs. Different RRsets can be signed by different
keys. In particular, it is common for the DNSKEY RRset to be signed by a
different key (a key-signing key) from the rest of the zone (which uses
a zone-signing key); there may be more differences during a key rollover.
The KSKs are special in that they authenticate the zone's keys. For a zone
to be secure there must be a DS record in the parent corresponding to a
KSK. If a particular DNSKEY is not self-signed then it fails to prove the
zone admin has both private and public halves of the key. DS records
corresponding to ZSKs are useless.
There can be extra DS records and extra DNSKEY records. They are ignored
if they aren't usable as part of a validation chain.
So the usual chain of authentication is
parent
RRSIG(DS) child
DS -> DNSKEY(ksk) <-> RRSIG(DNSKEY)
DNSKEY(ksk)
DNSKEY(zsk) -> RRSIG(A,NS,MX etc)
A,NS,MX etc
If you are signing with multiple algorithms then it must be possible to
validate the zone using each algorithm by itself. That is, each algorithm
must have a ZSK and a KSK and an RRSIG on every record. The zone is
considered bogus if it is bogus according to any of the algorithms. A
validator knows whether to expect multiple algorithms for a zone by
examining its DS RRset in the parent. So for an algorithm rollover you
need to get all the DNSKEYs and RRSIGs for the new algorithm in place
before adding it to the DS RRset, and you must remove the old algorithm
from the DS RRset before removing its DNSKEYs and RRSIGs. You have much
less flexibility than there is for normal key rollovers. Pay attention to
the following sentence in RFC 6781 section 4.1.4!
Note that the Double-DS KSK rollover method cannot be used, since
that would introduce a parental DS of which the apex DNSKEY RRset has
not been signed with the introduced algorithm.
It is also worth looking at
http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing
You do not need to follow the timing restrictions in RFC 5011 unless you
support users that have configured a trust anchor for your zone. If you
only support the normal validation chain from the root then RFC 5011 is
not relevant.
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
