The EURid Insights series aims to analyse specific aspects of the domain-

name environment. The repor ts are based on sur veys, studies and research
developed by EURid in cooperation with industr y exper ts and sector leaders.

DNS SECurity Extensions technical over view

EURid shares its deployment experience and DNSSEC

operational recommendations for the transfer of DNSSEC-
enabled domain names, managing bogus name servers
and working with for warding name servers.

October 2010
 Introduction
The Domain Name System (DNS) provides responses without validating their source.
This means that it is vulnerable to the inser tion of invalid or malicious information, a
f law discovered by Dan Kaminsk y in 20 08.

This technical repor t documents the various components of the long-term solution to
this kind of cache - poisoning at tack: Domain Name System Securit y Ex tensions
(DNSSEC). This is followed by EURid’s recommendations to DNS operators planning to
deploy the protocol themselves.

Finally, EURid shares its experiences - gained since deploying DNSSEC to the .eu
top - level domain ( TLD) on 15 June 2010 - of the DNS operations indirectly af fected by
the deployment of the DNSSEC protocol:

• Transfers of DNSSEC - enabled domain names bet ween registrars

• DNS architecture and bogus name ser vers
• DNS architecture and for warding name ser vers.

For a status summar y of the implementation of DNSSEC across the world’s 283 active
TLDs, as of October 2010, please refer to the supplementar y .eu Insights repor t,
“Over view of DNSSEC deployment worldwide”.

DNSSEC Over view

In a nutshell, DNSSEC adds signatures to regular DNS responses in the form of
Resource Record Signature (RRSIG) resource records. A signature is the hash 1 of a
DNS response, encr ypted with the private par t of a key pair 2 .

1
A hash of a sequenc e of characters is a transfor mation of that sequenc e to a shor ter sequenc e
applying a c er tain mathematic al for mula. By rec alculating the hash af ter transmission of the
characters, one c an detect changes to this sequenc e as the rec alculated hash will dif fer from the
or iginal hash.

2
Public /pr ivate key encr yption is a well - known encr yption technology, in which a message is
encr ypted with one par t of a key pair. The resulting encr ypted message c an only be decr ypted
using the other par t of the key pair.

2
 Insights

To be able to verif y whether the response is legitimate, the receiver of a signed

response should:

• Calculate the hash of the response

• Decr ypt the signature with the public par t of the key pair
• Compare the newly calculated hash with the result of the decr ypted signature.

If this comparison shows no dif ferences, the receiver is sure of t wo things:

• Integrit y - the response has not been modif ied

• Authenticit y - the response comes from the expected source
(the only one to possess the private par t of the key pair).

Note that the response itself is not en -

cr ypted. DNSSEC adds RRSIG records
DNSSEC uses public/private
to responses, but the records that hold
cr yptography technology
the data remain unaltered. In this way,
to validate DNS answers.
DNSSEC is back wards compatible as
non DNSSEC -aware name ser vers can and should ignore unknown data and continue to
function as expected.

The challenge in this scenario is to get the public par t of the key pair to the users who
need it for verif ication in a secure way.

The public par ts of key pairs are available via the DNS as they are published as Domain
Name System KEY (DNSKEY) resource records. When quer ying for DNSKEY records,
the response to a quer y also holds a signature for the DNSKEY record. But the question
remains, should the receiver simply accept that the data is authentic and use it?

The answer is no. To verif y the signature of a DNSKEY record, the user must consult
the parent of the domain name. For domain names, such as eurid.eu, the parent is the
TLD. For a TLD, the parent is the root domain. To enable users to obtain the public par t
of a signed domain name in a secure way, a hash of the public key is put in the parent
zone as a Delegation Signer (DS) resource record.

There it is signed with the private par t of the parent zone key pair. In the case of
eurid.eu, a hash of the public key (DS) is put in the .eu zone where it is signed with the
private key of .eu. For the .eu zone itself, a hash of the .eu public key (DS) is put in the
root zone, where it is signed with the private key of the root zone.

3
 This means that the receiver can obtain the public par t of a key pair by quer ying for
its hash in the parent zone, and verif y its signature with the public par t of that parent
zone’s key pair. This process only takes us up one level in the DNS hierarchy.

There the question repeats itself: how

can the receiver trust the signature from The DNSSEC chain of trust star ts
that parent zone f ile? The answer lies in with one key that should be
applying the same procedure: retrieving trusted by ever y layer of the DNS.
the public par t of its key, the hash from its
parent and the hash’s signature.

But ultimately, some trust must be built in.

Herein lies the impor tance of having a signed Internet root zone, because receivers that
verif y signatures need only trust the public key of the root zone. This is the only public
key necessar y and it can be obtained outside the DNS. It is available for download in
several dif ferent formats together with a signature f ile at:
ht tp://data.iana.org/root-anchors/. Before the root zone was signed on 15 July 2010,
administrators had to manually conf igure and maintain public key information from
dif ferent branches in the DNS tree.

It is also understandable that TLD operators are working hard to publish their data with
signatures, because it is only if a TLD is DNSSEC - enabled that receivers can f ind a
completed chain of trust, allowing them to easily verif y domain name signatures within
that TLD. Now that the root zone is signed and TLDs sign their data as well, registrars
are also able to sign their DNS data.

4
 Insights

Types of key pairs

Two t ypes of keys are used in DNSSEC:

• The key-signing key (KSK) - used only to sign the hash of DNSKEY information
• The zone -signing key (ZSK) - used to sign the hashes of all resource records
(A , NS, MX, etc).

The more signatures generated with a par ticular key pair, the greater the chance of a
successful cr ypto -at tack, in other words deducing the private par t of a key pair by using
the public par t and the available signatures. To prevent the signing of false informa-
tion, key pairs should not be used indef initely. Ever y so of ten, new key pairs should be
generated and used to resign the zone. The frequency of key generation depends on the
strength of the algorithm, key length and how of ten a key is used.

Because strong algorithms and long keys require more resources, such as more CPU,
the practice is to use a weaker key pair, the ZSK , for all signatures but to change it
regularly, ever y three to six months at most. A stronger key pair, the KSK , is only used
to sign the public key information. The KSK is changed less frequently, ever y one to t wo
years. Only a hash of the KSK appears in the root zone (as the DS record). Since this
key is changed, or rolled, less of ten interaction with the parent is less frequent.

5
 Figure 1 illustrates the validation of the chain of trust for the quer y w w w.eurid.eu. It is
followed by explanator y comments.

A record for RRSIG record DNSKEY(ZSK)

www.eurid.eu is signed by covering is verified by record for is signed by
www.eurid.eu/A eurid.eu

RRSIG record DNSKEY(KSK) DS record

covering is verified by record for is verified by
for eurid.eu is signed by
eurid.eu/DNSKEY eurid.eu

RRSIG record RRSIG record

covering DNSKEY(ZSK)
is verified by
record for eu.
is signed by covering is verified by
eurid.eu/DS eu./DNSKEY

DNSKEY(KSK) DS record RRSIG record

is verified by is signed by is verified by
record for eu. for eu. covering eu./DS

RRSIG record
DNSKEY (ZSK) is signed by covering is verified by
DNSKEY(KSK)
record for . ./DNSKEY record for .

Figure 1 - Validation of the chain of trust for a quer y to w w w.eurid.eu

• w w w.eurid.eu is signed with the ZSK of eurid.eu, so the public par t of the ZSK
DNSKEY information is needed.
• The ZSK DNSKEY is signed with the KSK of eurid.eu; consequently the KSK DNS -
KEY information is needed.
• A hash of the KSK DNSKEY for eurid.eu is stored as a DS record in the .eu zone.
• The DS record for eurid.eu is signed with the ZSK of .eu, requiring the ZSK
DNSKEY.
• The ZSK DNSKEY is signed with the KSK of .eu.
• A hash of the KSK DNSKEY for .eu is stored as a DS record in the root zone.
• The DS record for .eu is signed with the ZSK of the root zone.
• Finally, the ZSK DNSKEY is signed with the KSK of the root zone.

The KSK of the root zone, available since 15 July 2010, can and should be conf igured
on a caching validating name ser ver as the root of all trust, the one and only trust
anchor.

6
 Insights

Algorithms
Several algorithms for calculating hashes and signatures have been def ined. Specif ic
name ser ver implementations or versions may not suppor t all of the algorithms men -
tioned in the following summar y:

RSASHA1 (algorithm number 5) is declared mandator y by RFC 403 4 3 . RSASHA1-

NSEC3 - SHA1 (algorithm number 7) is def ined by RFC 5155 4 . It is essentially the same
algorithm as RSASHA1, although the Nex t SECure records are NSEC3. The stronger
algorithms, RSASHA 256 (algorithm number 8) and RSASHA512 (algorithm number 10)
are both def ined by RFC 5702 5 .

The use of these algorithms is recommended, as at tacks against SHA1 (used in algo -
rithms 5 and 7) are increasing. Bear in mind that the newer algorithms, numbers 8 and
10, may not be available in older DNS ser ver implementations and, as verif ying DNS
name ser vers that do not recognise an algorithm will treat the data as unsigned, it is
unclear at the time of writing whether end users will actually benef it from these stronger
algorithms.

3
RFC 403 4: Resourc e Rec ords for the DNS Secur it y E x tensions
(ht tp:// w w w.iet f.org/r fc /r fc 403 4.t x t).

4
RFC 5155: DNS Secur it y (DNSSEC) Hashed Authentic ated Denial of E xistenc e
(ht tp:// w w w.iet f.org/r fc /r fc 5155.t x t).

5
RFC 5702: Use of SHA -2 A lgor ithms with RSA in DNSKE Y and RRSIG Resourc e Rec ords for
DNSSEC (ht tp:// w w w.iet f.org/r fc /r fc 5702.t x t).

7
 Next SECure (NSEC) and zone walking
As previously mentioned, algorithms 5 and 7 dif fer only in their use of NSEC record
t ypes. Algorithm 5 uses NSEC, while algorithm 7 uses NSEC3.

What are NSEC and NSEC3? What are they used for and what is the dif ference
bet ween the t wo?

Before DNSSEC, if there was no answer for a specif ic DNS quer y, the response did not
change signif icantly in function of the quer y. It held the Star t of Authorit y (SOA) record
of the zone.

Considering that DNSSEC adds signature information, a DNSSEC reply which indicates
that something does not exist could hold that SOA record and its corresponding signa-
ture information. While this is acceptable in theor y, in practice it could be abused by an
at tacker, who would ask for something that does not exist, receive the signed answer
and use the answer to spoof replies to other users who have legitimate queries. In this
way an at tacker could, for example, force a website into non- existence. The NSEC
record adds additional information to prevent this kind of at tack.

An example

Consider a zone f ile for the domain name somedomain.eu as shown in Figure 2, where
only three labels exist: mail, w w w and zone. When signing this zone f ile, NSEC records
will be created that point from one label to the nex t. Essentially the NSEC records prove
that no other labels exist in the space bet ween the t wo labels mentioned in each NSEC
record. For obvious reasons, each NSEC record is accompanied by its own signature.
To make end users believe that “ w w w ” did not exist, an at tacker would have to create
a NSEC record in which “mail” points to “zone”. This is not ver y dif f icult to do, but the
at tacker would also have to provide a signature for that record, which is vir tually impos-
sible to do without the correct private key for the domain name - information which an
at tacker should never be able to obtain.

8
 Insights

somedomain.eu

NSEC (SOA, NS, RRSIG,

NSEC (A, RRSIG, NSEC)
NSEC, DNSKEY)

zone.somedomain.eu mail.somedomain.eu

NSEC (A, RRSIG, NSEC) NSEC (A, RRSIG, NSEC)

www.somedomain.eu

Figure 2 - A zone f ile containing NSEC records

In ef fect, Nex t SECure records prevent at tackers from claiming that a domain name
does not exist, when in realit y it does (known as authenticated denial of existence).

The drawback of NSEC is that the entire content of a zone f ile can be obtained by
simply “hopping” from one NSEC record to the nex t. For example, if you know that the
“mail” record exists, the NSEC record will indicate that the “ w w w ” record exists. From
that point, the NSEC record will point to the “zone” record, etc. This is called zone
walking.

By def inition, data in public DNS ser vers is available to ever ybody, and since unneces-
sar y data should never be published, zone walking is ordinarily not a problem. However,
cer tain TLDs want to prevent zone walking as it allows spammers to easily obtain a list
of all the domain names registered under that TLD and send them unsolicited email.

9
 NSEC3 prevents zone walking. It essentially of fers the same functionalit y as NSEC but
hashes the domain names. Also, where NSEC forces a NSEC record for each domain
name in the zone, NSEC3 allows an opt- out which only creates NSEC3 records for
signed data. The advantage of the opt- out is that the zone f ile, which normally grows
by several factors, does not grow as much in zones with relatively few signed records.
While NSEC3 requires more CPU power (to generate and verif y), it is recommended for
TLDs, such as .eu.

10
 Insights

Implementing DNSSEC
DNSSEC must be deployed carefully, step by step, with verif ication of each stage in the
process. This is because:

• DNSSEC requires additional data to be transpor ted in DNS packets, such as

RRSIGs, DNSKEYs and DSs. This data increases the size of DNS responses and
DNS queries must be sent over TCP more of ten (UDP is the default). Securit y
equipment could reject larger DNS responses because, for example, it is not cor-
rectly conf igured to suppor t EDNS0, mandator y for DNSSEC, which permits UDP
packets bigger than 512 data by tes. Similarly, DNS responses over TCP could be
blocked because a securit y administrator (wrongly) believes that DNS over TCP is
for zone transfers only.
• The chain of trust is fragile but must be kept intact. If broken, validating receiv-
ers will refuse responses they cannot verif y, even though the data in the answers
might be correct. Procedures are being developed and tested to ensure that, when
new key (KSK) information is given to the parent - for example, from a TLD to the
root or, more frequently, from a registrar to the registr y of the TLD - this informa-
tion is verif ied and results in correct DS records in the parent ’s zone f ile.

DNSSEC deployment of domain names under a DNSSEC-ready

top-level domain, such as .eu

EURid recommends that registrars and DNS operators deploy domain names under a
DNSSEC - ready TLD in a way similar to that in which a TLD is deployed to the DNSSEC -
ready root zone. In other words:

• Add DNSSEC information to the domain names, but not share it with the TLD
operator. As such, no DS records will appear in the parent ( TLD) zone.
• Once the setup works, share the public par t of the KSK with the TLD operator.

11
 Deployment experience: Transfer of a DNSSEC-enabled
domain name between registrars

Background

The transfer of a domain name to another registrar is both an administrative and techni -
cal operation, as the registrar of the domain name being transferred of ten also acts as
the DNS ser vices provider. This means that when the domain name is transferred out of
the por t folio, the name ser vers related to that domain name of ten have to be changed
as well.

The administrative aspects of a transfer, such as the validation of the request, dif fer
from TLD to TLD, but when the transfer is concluded the former registrar is usually in -
formed that they are no longer in charge of the domain name.

If the former registrar was also the DNS ser vice provider for the transferred domain
name, it is logical that they then decommission that domain name from their DNS infra-
structure.

This operation introduces a period of potential instabilit y, as the old name ser ver (NS)
records might still be cached in caching name ser vers, even though these name ser vers
no longer provide answers.

Transfer of a DNSSEC-enabled domain name

When the transferred domain name has DNSSEC information, both its old NS and DS
records are present in the TLD zone. The DS records hold hash information about the
public keys on the former authoritative name ser vers. This outdated information is
another reason why DNS answers might not be available for a transferred domain name.

There are t wo possible situations that could result in invalid DS information:

1. The transferred domain name, on the name ser vers of the new registrar, might not
be signed, meaning that no DNSKEY resource records exist to provide the public
key. As such, DS records should not appear in the parent zone.
2. The transferred domain name is signed on the new registrar ’s name ser vers, but
the DS record does not correspond to the public key in the DNSKEY resource
record.

If a caching name ser ver has the (void) DS information in its cache, either scenario can
result in interrupts for the transferred domain name. The presence of a DS record
(assumed to be in the cache) implies that the name ser ver must insist on valid
signatures.

12
 Insights

In the f irst scenario there are no signatures, consequently the caching name ser ver will
quer y all (new) authoritative name ser vers and, failing to f ind any signatures, will have
no answers for its clients. If the domain name in its new location does have signatures
but they have been generated with a dif ferent key pair, the DNSSEC validation will fail.
Again, the caching name ser ver will quer y all (new) authoritative name ser vers and,
since DNSSEC verif ication will fail ever y where, will have no answers for its clients.

Possible scenarios

The following scenarios exist to prevent discrepancies following the transfer of

a DNSSEC - enabled domain name:

1. Explicit cooperation from former registrar

• Prior to the transfer, the former registrar removes DNSSEC information for the
domain name. When the domain name is transferred, no DS information will be
available to potentially confuse caching name ser vers. Suf f icient time needs to
elapse bet ween the removal of DNSSEC information from the zone and the actual
transfer to make sure that the caches of caching name ser vers have had time to
ref lect the new situation.
• The former registrar provides the new registrar with the private/public key pair in
use for the domain name being transferred. The zone f ile on the new name
ser vers is then signed using the same key pair and DNSSEC validation simply
continues to work.
• The new registrar provides the newly generated public keys to the former
registrar, who includes them in the zone.

Regardless of which scenario is followed, the former registrar needs to keep the DNS
infrastructure for the transferred domain name running for some time af ter the transfer
has taken place in order to eliminate all possible “ DNS darkness”.

Note: If the former registrar uses the key pair for multiple domain names, handing it over
is not an option. Similarly, the new registrar ’s system might not be able to impor t ex ter-
nally generated keys. Lastly, handing over a key pair implies that the former registrar
possesses the private key of a domain name of which they are no longer in charge. This
key is then considered compromised and a key rollover is strongly recommended.

13
 2. No cooperation from former registrar

Unless the domain name is, at the ver y least, lef t provisioned on the current name
ser ver infrastructure for some time af ter the execution of its transfer, there is no scena-
rio which guarantees the fail-safe transfer of a domain name (if the transfer also
involves changes in the name ser ver set) without the cooperation of the former registrar.

There is a precaution new registrars can take to limit the chances of “ DNS darkness”.
They can initiate a transfer without linking any DNSSEC key material to the domain
name. This eliminates one possible issue, but brings the domain name into a temporar y
insecure state.

Since caching name ser vers need not refresh data if it is still in the cache, it is advan -
tageous to publish DS information with somewhat shor ter time -to - live ( T TL) values. In
this way, DNSSEC information that becomes invalid af ter a transfer will disappear more
quickly from caches all round. This reduces the period of time during which a trans-
ferred domain is inaccessible due to DNSSEC incompatibilities.

Summar y and explanation

With or without DNSSEC information, there is always the risk that DNS answers will be
temporarily unavailable during a domain name transfer. This is due to caching, which is
responsible for invalid information (invalid because of the transfer) still being remem -
bered. Adding DNSSEC to a domain name does not make the period of potential unavail-
abilit y longer, but it does add another possible cause of unavailabilit y.

14
 Insights

Deployment experience: DNS architecture and bogus name ser vers

A bogus name ser ver is a name ser ver that is authoritative for a domain, but to which
there is no of f icial delegation.

An authoritative name ser ver is a name ser ver that has knowledge of the content of a
domain because it has a local copy of it, either in a f ile or database, such as Windows
Active Director y.

A problem could arise in a situation where a name ser ver operates both in an authorita -
tive role (of fering data to the Internet) and a caching role (looking for answers for its
clients).

The of f icial delegation for the domain name could change (due to it being transferred)
but be ignored by the name ser ver.

As local knowledge is taken f irst, clients that use the (caching) name ser ver may receive
information that should have been removed. This is the primar y reason to operate au -
thoritative and caching name ser vices on dif ferent IP addresses.

This situation could also be desirable, however. By explicitly providing local knowledge
on a caching name ser ver, the administrator can give specif ic replies, valid only for the
clients of that name ser ver. For example, they can return private addresses to internal
users or publish more (internal) ser vices and ser vers to internal users.

As a rule of thumb, if an internal caching name ser ver has local content, it may well be
set up correctly. If an ex ternal caching name ser ver (to be used by ex ternal users) has
local content, this is more questionable.

A correct bogus name ser ver

But what happens when a caching name ser ver, already bogus for a domain name, is
conf igured to per form DNSSEC validation, especially when that domain name is
DNSSEC - enabled on the public side?

Take the following scenario: the root domain, .eu TLD and somedomain.eu are
DNSSEC - enabled. The caching name ser ver is bogus for somedomain.eu, which it
of fers without signatures.

15
 Either the caching name ser ver is DNSSEC - enabled or it is not. Table 1 illustrates the
possible outcomes.

Caching name ser ver is Caching name ser ver

not DNSSEC - enabled is DNSSEC - enabled

Any quer y about the OK OK

bogus domain name Information received. Information received.
Authenticated Data bit Authenticated Data bit
not set. not set.

Quer y for DS records No DS information DS information available.

of the domain name available. Authenticated Data bit
set. (Provided all valida-
tions are OK , other wise
there will be no answer.)

Table 1 - Possible outcomes when a caching ser ver is DNSSEC - enabled, or not

Summar y and explanation

When a validating, caching name ser ver has local knowledge of a domain name and is
bogus for that domain name it will use the local data, even if that data cannot be veri -
f ied and a validation quer y (for the DS records at the parent) reveals that correct signa-
tures are required.

Even before DNSSEC was available, caching name ser vers always gave preference to
local data. The introduction of DNSSEC does not modif y that behaviour.

The only dif ference is that a DNSSEC - enabled name ser ver is aware that DS informa-
tion is at the parent of a domain name. As regards queries for DS records, the obser ved
behaviour is consistent in that the non DNSSEC - enabled caching name ser ver looks for
DS information in the local data, but will not f ind any. The DNSSEC - enabled caching
name ser ver looks for DS records at the of f icial parent (following normal DNS delega-
tion rules) and f inds them there, with their signatures. If this information validates cor-
rectly, the client receives the DS record(s), with the signatures and the Authenticated
Data bit is set.

16
 Insights

Deployment experience: DNS architecture and

for warding name ser vers
A for warding name ser ver, a caching name ser ver that for wards queries, deliberately
breaks the rules of DNS delegation by addressing itself directly to conf igured name
ser vers, also called for warders.

This situation arises of ten and presents t wo possible scenarios when considering
DNSSEC:

1. An internal name ser ver with no Internet access, due to policy rules on a f irewall,
for wards all its queries to one or more dedicated name ser vers in a demilitarised
zone (DMZ).
2. An internal name ser ver in a DMZ for wards all its queries to the Internet Ser-
vice Provider (ISP) caching name ser vers, or another instance that of fers cach -
ing name ser vices, with or without ex tra ser vice. For example, Google 8.8.8.8 or
OpenDNS 208.67. 222. 222.

As more and more public authoritative name ser vers make the move towards DNSSEC,
for warding name ser vers require additional at tention.

In a situation where both the root domain and .eu TLD are DNSSEC - enabled, t wo .eu
domain names are queried. One domain name is DNSSEC - enabled, the other is not.
The for warding name ser ver, as well as the conf igured name ser ver could similarly be
DNSSEC - enabled, or not. Table 2 illustrates the outcome of all possible scenarios.

17
 Conf igured NS Conf igured NS
Not DNSSEC - enabled DNSSEC - enabled

For warding NS OK OK
Not DNSSEC - enabled Information received. Information and cor-
Authenticated Data bit responding signatures
not set. received.
Authenticated Data bit
not set.

For warding NS Not OK OK

DNSSEC - enabled No data received. Information and cor-
Reply status code: responding signatures
SERVFAIL. received.
(For both the DNSSEC - Authenticated Data bit
enabled and the non set.
DNSSEC - enabled domain (Provided all validations
name.) are OK , other wise there
will be no answer.)

Table 2 - Possible outcomes of interactions bet ween DNSSEC - enabled and non
DNSSEC - enabled for warding and conf igured name ser vers

Summar y and explanation

A validating and for warding name ser ver should only for ward to another DNSSEC -
enabled name ser ver.

When a validating name ser ver receives a reply from the for warder it also checks for the
existence of DS records. In the case of somedomain.eu, it will quer y the DS records of
that domain name and of .eu.

Because of its conf iguration, the quer y is sent to the for warder. A non DNSSEC - enabled
for warder will look for the DS records at the domain name’s authoritative name ser vers.
But the DS records are located on the authoritative name ser vers of the parent. There -
fore, it will look for the DS records of somedomain.eu at the somedomain.eu authorita -
tive name ser vers and for the DS records of .eu at the .eu authoritative name ser vers,
which is incorrect.

Consequently the validating and for warding name ser ver obtains replies that do not al -
low it complete verif ication, regardless of the DNSSEC status of the requested
domain name.

The status in the reply sent to the client is implementation dependent. For example,
SERVFAIL was obser ved with a recent Bind name ser ver.

18
 Insights

Verification of signatures
In the contex t of DNSSEC, it is impor tant to remember that providing signatures (RRSIG
records) and a manner in which to verif y them (DNSKEY and DS records), only enables
caching or for warding name ser vers to per form validation. Validation does not occur
by default.

In practice, the administrator of a caching or for warding name ser ver must explicitly
conf igure it to validate signatures and conf igure the root zone’s public par t of the KSK.

Despite the availabilit y of verif iable signatures, an unconf igured caching or for ward -
ing name ser ver will still accept any answers from any where, possibly leading to DNS
cache - poisoning at tacks. Fur thermore, given that cache - poisoning at tacks can only
be successful in the time during which a name ser ver waits for an answer af ter having
sent a request, and knowing that signed responses need more CPU cycles and more
time to be transmit ted, there is a paradox in the fact that the availabilit y of the DNSSEC
protocol means that the window of oppor tunit y for a successful cache - poisoning at tack
increases if the responses are not validated.

Therefore conf iguration changes on both sides of the DNS, ser ver (root and TLD) and
consumer (caching and for warding name ser vers, resolvers in end devices, etc.), are
required to achieve enhanced DNS securit y through DNSSEC.

19
Learn more
For a status summar y of the implementation of DNSSEC across all 283 active TLDs,
as of October 2010, please refer to the .eu Insights repor t, “Over view of DNSSEC
deployment worldwide”.

The latest statistic s on .eu per formance and other .eu Insights repor ts are available at:
ht tp://link.eurid.eu/insights.

About EURid
EURid is the not-for- prof it organisation appointed by the European Commission to
operate the .eu top - level domain. Set up in 20 03, EURid star ted general registration of
.eu domain names in April 20 0 6. More than 3 million domain names have been regis-
tered to date. To f ind out more about .eu and EURid, please go to w w w.eurid.eu. You can
contact us directly in any of f icial EU language by email to [email protected].

Credits
This repor t was prepared by EURid.

EURid, 150 Woluwelaan, 1831 Diegem, Belgium

Website: w w w.eur id.eu, Email: info@eur id.eu, Tel: +32 (0)2 401 27 50
© 2010 EURid. A ll r ights reser ved.