Brocade Communications Systems ServerIron ADX 12.4.00 Manuale Utente
112
ServerIron ADX Global Server Load Balancing Guide
53-1002437-01
DNSSEC
1
DNSSEC
DNSSEC (Domain Name System Security Extensions) is a set of extensions that provide DNS
resolvers origin authentication of DNS data, data integrity and authenticated denial of existence. It
protects DNS resolvers from forged DNS data (from cache poisoning, etc.). DNSSEC does not
provide confidentiality.
resolvers origin authentication of DNS data, data integrity and authenticated denial of existence. It
protects DNS resolvers from forged DNS data (from cache poisoning, etc.). DNSSEC does not
provide confidentiality.
With DNSSEC, the responses are signed using public key cryptography. In addition to the answer
RRsets, the response contains a RRSIG record which is an encrypted digital signature for the
RRset. A DNSSEC aware client (resolver) sets the DO (DNSSEC OK) bit in the EDNS OPT section to
indicate that it prefers DNSSEC signed responses. If the DO bit is set and if the server is DNSSEC
capable, it copies the OPT section (including the DO bit) to the response and includes the DNSSEC
signatures for each RRset in the response. The resolver can validate this signature by obtaining the
public key of the ADNS server as a DNSKEY record.
RRsets, the response contains a RRSIG record which is an encrypted digital signature for the
RRset. A DNSSEC aware client (resolver) sets the DO (DNSSEC OK) bit in the EDNS OPT section to
indicate that it prefers DNSSEC signed responses. If the DO bit is set and if the server is DNSSEC
capable, it copies the OPT section (including the DO bit) to the response and includes the DNSSEC
signatures for each RRset in the response. The resolver can validate this signature by obtaining the
public key of the ADNS server as a DNSKEY record.
Because the DO bit in EDNS is used to indicate DNSSEC responses and because the responses are
in general larger due to the RRSIG records, a DNSSEC capable server (and the ServerIron ADX)
must support EDNS and packet sizes of up to 4k. Also, if there are intermediate firewalls that drop
fragmented UDP traffic, we'd have more resolvers retrying with TCP.
in general larger due to the RRSIG records, a DNSSEC capable server (and the ServerIron ADX)
must support EDNS and packet sizes of up to 4k. Also, if there are intermediate firewalls that drop
fragmented UDP traffic, we'd have more resolvers retrying with TCP.
A DNSKEY record is validated via an "authentication chain". A well known public-key forms a "trust
anchor" for this authentication chain. This can be used to verify a "designated signer" (DS) record—
a signed hash of the DNSKEY of a child zone. Since the parent zone is trusted, the DS record
validates the DNSKEY of the child zone. The child zone can contain other DS records to verify its
child zones.
anchor" for this authentication chain. This can be used to verify a "designated signer" (DS) record—
a signed hash of the DNSKEY of a child zone. Since the parent zone is trusted, the DS record
validates the DNSKEY of the child zone. The child zone can contain other DS records to verify its
child zones.
Signing KEYs are supposed to be changed regularly. However, for each new key, a child zone must
have its parent zone create a DS record to validate the child zone's key. To simplify this, DNSSEC
uses two keys—a zone-signing key (ZSK) and a key-signing key (KSK). All KEY records are signed
with the KSK, and the entire zone is signed with the ZSK. The KSK is the key for which our parent
publishes the DS record. The ZSK can be smaller and can be cycled more frequently (~monthly).
The KSK is cycled less frequently (~annually). In such a scenario, a resolver would first validate the
KSK through the parent zone DS record. A valid KSK is used to validate the RRSIG of the ZSK.
have its parent zone create a DS record to validate the child zone's key. To simplify this, DNSSEC
uses two keys—a zone-signing key (ZSK) and a key-signing key (KSK). All KEY records are signed
with the KSK, and the entire zone is signed with the ZSK. The KSK is the key for which our parent
publishes the DS record. The ZSK can be smaller and can be cycled more frequently (~monthly).
The KSK is cycled less frequently (~annually). In such a scenario, a resolver would first validate the
KSK through the parent zone DS record. A valid KSK is used to validate the RRSIG of the ZSK.
FIGURE 8
DNSSEC Example with Authentication Chain
The steps involved in a DNSSEC resolution are:
DNSKEY RESPONSE (with its RRSIG)
A REQUEST
DS Record for .com
LDNS
REQUEST
A RESPONSE (with RRSIG)
(root)
.com
ns.mydnssec.com
(ADNS)
(ADNS)
A REQUEST
DS Record for mydnssec.com
DS Record for mydnssec.com