Authentication is provided by associating with resource records in
the DNS cryptographically generated digital signatures. Commonly,
there will be a single private key that signs for an entire zone. If
a security aware resolver reliably learns the public key of the zone,
it can verify, for signed data read from that zone, that it was
properly authorized and is reasonably current. The expected
implementation is for the zone private key to be kept off-line and
used to re-sign all of the records in the zone periodically.
This data origin authentication key belongs to the zone and not to
the servers that store copies of the data. That means compromise of
a server or even all servers for a zone will not necessarily affect
the degree of assurance that a resolver has that it can determine
whether data is genuine.
A resolver can learn the public key of a zone either by reading it
from DNS or by having it staticly configured. To reliably learn the
public key by reading it from DNS, the key itself must be signed.
Thus, to provide a reasonable degree of security, the resolver must
be configured with at least the public key of one zone that it can
use to authenticate signatures. From there, it can securely read the
public keys of other zones, if the intervening zones in the DNS tree
are secure and their signed keys accessible. (It is in principle
more secure to have the resolver manually configured with the public
keys of multiple zones, since then the compromise of a single zone
would not permit the faking of information from other zones. It is
also more administratively cumbersome, however, particularly when
public keys change.)
Adding data origin authentication and integrity requires no change to
the "on-the-wire" DNS protocol beyond the addition of the signature
resource type and, as a practical matter, the key resource type
needed for key distribution. This service can be supported by
existing resolver and server implementations so long as they can
support the additional resource types (see Section 8). The one
exception is that CNAME referrals from a secure zone can not be
authenticated if they are from non-security aware servers (see
Section 2.3.5).
If signatures are always separately retrieved and verified when
retrieving the information they authenticate, there will be more
trips to the server and performance will suffer. To avoid this,
security aware servers mitigate that degradation by always attempting
to send the signature(s) needed.
