Below is a breakdown of how DNSSEC will
impact storage requirements for authoritative name servers. In these two
examples, the system and software is the same, and only the number of unique
hostnames changes. Note that different zones will produce different results.
Your results will vary.
System information: Fedora Core 5, 2GB physical memory
(1.9GB swap), running BIND v.9.4.1
DNSSEC information: The charts below feature 3 versions of the same zone file:
Unsigned, signed using a 1024bit RSA/SHA-1 key and signed using a 2048bit RSA/SHA-1 key.
In the tables below, each unique name has either
single A resource record (~26 bytes), 5 unique RRtypes, or 10 unique RRtypes associated
with the name. When signed, DNSSEC will include an NSEC
resource record for every name, and an RRSIG resource record for each RRset
(here, the number of RRsets is either 2, 6 or 11 for every unique name
in the zone). This could be
considered the "worst case" scenario for zone signing: A flat zone
file with many ownernames and multiple types at each ownername, resulting in
the signer having to generate multiple digital signatures (RRSIG RRs) for each
ownername.
|
For 1 RR per ownername
|
|
|
For 5 RRs per ownername
|
|
|
For 10 RRs per ownername
|
|
In the table below, each unique name represents a delegation consisting of two NS resource record (~60 bytes), 2 glue A resource records and a single DS RR.
The zone files used were different (as described above) and only the number of ownernames in the zone being variable, not the number of RRs associated with a name. Signing was done by a single 1024 bit RSA/SHA-1 key or a single 2048 bit RSA/SHA-1 key.
|
For Delegation Only Zones
|
|
The above numbers are obtained using the BIND DNS implementation. Those who use NSD (from NLNet Labs) can use the on-line tool to get the memory use estimation for a particular zone.
Some basic understanding of how DNS data is
signed is required to better understand these numbers. In DNSSEC, every RRset
has a signature (stored in a RRSIG signature) and every ownername may have an
NSEC RR. An ownername is any fully qualified domain name (FQDN) - e.g.
www.dnssec-deployment.org is an ownername. An RRset is all the DNS resource
records that share the same ownername, DNS class and type: e.g. all the address
records (A RRs) for www.dnssec-deployment.org.
In the authoritative zone chart, each zone
has a single RRset at each ownername (a set containing a single A RR). So
DNSSEC adds one NSEC RR for each name, and two RRSIG RRs: one for the A RRset,
and one for the new NSEC RR. If each name had two A RRs per owner name, the
number of NSEC and RRSIG records added by DNSSEC would be the same, but when
there were other types added (every name has a mail exchange RR (MX RR) and
Host Information (HINFO RR)), there would still be one NSEC RR for every name,
but four RRSIGs added: One for the A RRset, one for the MX RRset, one for the
HINFO RRset, and one for the NSEC RR.
In the delegation only chart, each ownername
in the zone is actually a delegation consisting of two name server RRs (NS RR)
and two accompanying glue A RRs. In DNS, delegations are not considered
"authoritative" but only a hint about where the desired information
could be, which means they are not signed in DNSSEC. So for each owner name,
only one NSEC RR is generated, and one RRISG (for the NSEC RR). No DNSSEC RRs
are generated for the glue A records in the zone. If the delegated zone is also
signed, then there may be security information in the delegating zone in order
to establish a chain of trust. This takes the form of a Delegated Signer RR
present at a delegation owner name. In this case, there are a total of four
DNSSEC RRs now present at every owner name: One NSEC RR, one DS RR, and two
RRSIGs - one covering the NSEC RR and one covering the DS RR.
last updated 04/18/2008. Questions or comments should be sent to
proj-dnssec@antd.nist.gov