DNSsec theoretical and practical aspects

Document Sample
DNSsec theoretical and practical aspects Powered By Docstoc
					     DNSsec: theoretical and practical aspects
                         Bertrand Leonard, AFNIC
                     IDsA project: http://www.idsa.prd.fr
                                     version 1.4

The Domain Name System [1]&[2] constitutes one of the fundamental elements that
makes the Internet not only work, but become fully usable by human beings: the map-
pings between domain names and IP addresses the DNS provides are used in preamble
of nearly any human Internet activity.
Moreover, the DNS robustness and scalability have contributed to the dramatic growth
of internet connected devices. But as critical as it is, this service was not yet secured
and thus was a potential target to various attacks quite simple but highly damaging.
Therefore, a solution to secure the DNS tree has been designed, and is still being dis-
cussed at the IETF: DNSsec [5] is a protocol extension of DNS based on cryptographic
tools (basically keys and signatures) that aims to protect DNS data and transactions
accordingly to DNS specific needs for security. DNSsec takes full advantage of the
hierarchical structure of the DNS: the zones are secured locally, but they can also be-
come part of a more global scheme, where chains of trust are build to allow a zone to
authenticate the keys of its children zones, as well as to have its keys authenticated by
its parent zone.
The goal of this document is to provide a full description of the DNSsec protocol and
infrastructure requirements, as well as views on operational aspects and its deployment
using BIND software[37].
Therefore, we will begin by recalling the fundamentals of DNS and its weaknesses in
section 1; then we will enter DNSsec protocol and its evolutions in section 2; and we
will finish with more operational issues in section 3, including an HowTo dedicated to
the implementation of DNSsec using BIND.

1 Overview of DNS: general features and security considerations                               4
  1.1 DNS Basics . . . . . . . . . . . . . . . . . . . . . . . . . .      .   .   .   .   .   4
      1.1.1 Critical nature of the DNS application . . . . . . . .        .   .   .   .   .   4
      1.1.2 General design of the DNS . . . . . . . . . . . . . .         .   .   .   .   .   5
      1.1.3 Domains and zones . . . . . . . . . . . . . . . . . .         .   .   .   .   .   6
      1.1.4 DNS infrastructure . . . . . . . . . . . . . . . . . .        .   .   .   .   .   7

         1.1.5 DNS data . . . . . . . . . . . . . . . . . . . . .                        .   .   .   .   .   .   .    9
         1.1.6 Name resolution: how it works . . . . . . . . . .                         .   .   .   .   .   .   .   11
   1.2   Security threats and expectations . . . . . . . . . . . . .                     .   .   .   .   .   .   .   12
         1.2.1 Networks security fundamentals . . . . . . . . .                          .   .   .   .   .   .   .   12
         1.2.2 DNS specific need for security . . . . . . . . . .                         .   .   .   .   .   .   .   13
         1.2.3 Well-known attacks on DNS and consequences .                              .   .   .   .   .   .   .   13
   1.3   Security requirements beyond the scope of this document                         .   .   .   .   .   .   .   16
         1.3.1 Security threats non DNS specific . . . . . . . .                          .   .   .   .   .   .   .   16
         1.3.2 Adequate server configuration . . . . . . . . . .                          .   .   .   .   .   .   .   16

2 DNSsec principles                                                                                                  17
  2.1 Selected solutions for security . . . . . . . . . . . . . .                        .   .   .   .   .   .   .   17
  2.2 Services provided by DNSsec . . . . . . . . . . . . . . .                          .   .   .   .   .   .   .   18
      2.2.1 Data origin authentication and Data integrity . .                            .   .   .   .   .   .   .   18
      2.2.2 Transaction security . . . . . . . . . . . . . . .                           .   .   .   .   .   .   .   19
      2.2.3 Key distribution . . . . . . . . . . . . . . . . . .                         .   .   .   .   .   .   .   20
  2.3 Cryptographic features . . . . . . . . . . . . . . . . . .                         .   .   .   .   .   .   .   21
  2.4 The new RRs in detail . . . . . . . . . . . . . . . . . . .                        .   .   .   .   .   .   .   22
      2.4.1 The KEY RR . . . . . . . . . . . . . . . . . . .                             .   .   .   .   .   .   .   22
      2.4.2 The SIG RR . . . . . . . . . . . . . . . . . . . .                           .   .   .   .   .   .   .   24
      2.4.3 The NXT RR . . . . . . . . . . . . . . . . . . .                             .   .   .   .   .   .   .   26
      2.4.4 The DS RR . . . . . . . . . . . . . . . . . . . .                            .   .   .   .   .   .   .   29
  2.5 DNSsec design . . . . . . . . . . . . . . . . . . . . . .                          .   .   .   .   .   .   .   30
      2.5.1 Zone signing/Becoming locally secured . . . . .                              .   .   .   .   .   .   .   30
      2.5.2 Zone transfer . . . . . . . . . . . . . . . . . . .                          .   .   .   .   .   .   .   31
      2.5.3 Building chains of trust . . . . . . . . . . . . . .                         .   .   .   .   .   .   .   33
      2.5.4 Key Rollover . . . . . . . . . . . . . . . . . . .                           .   .   .   .   .   .   .   36
  2.6 Data retrieving/ New requirements for DNS components                               .   .   .   .   .   .   .   37

3 Operational aspects                                                                                                40
  3.1 DNSsec: New operational challenges         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   40
  3.2 How to sign a zone . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   42
      3.2.1 Generating Keys . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   43
      3.2.2 Signing the zone . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   45
  3.3 Building the chain of trust . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   49
  3.4 Rollovers and associated procedures .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   50
      3.4.1 ZSKs . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   51
      3.4.2 KSKs . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   51
      3.4.3 emergency rollovers . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   52
  3.5 Useful tools . . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   53
      3.5.1 The dig tool . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   53
      3.5.2 Configuring a local verifier . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   54
      3.5.3 DNSsec toolkit . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   56
      3.5.4 DNSsec resolver (resolv.pl) . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   56

4 References and Copyright                                                                                           57

List of Figures
  1    DNS tree . . . . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .    5
  2    zones and domains . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
  3    idsa.prd.fr zone file . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   10
  4    DNS requests . . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
  5    DNS weaknesses . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   14
  6    man in the middle attack . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   15
  7    "birthday attack" . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   15
  8    public key crypto used for digital signatures    .   .   .   .   .   .   .   .   .   .   .   .   .   .   22
  9    KEY RDATA format . . . . . . . . . . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   23
  10   KEY RR example . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   24
  11   SIG RDATA format . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
  12   SIG RR example . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
  13   NXT RDATA format . . . . . . . . . . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   27
  14   NXT RR example . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   28
  15   DS RDATA format . . . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   29
  16   DS RR example . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   30
  17   partly secured DNS tree using DS . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   33
  18   chains of trust using DS . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   35
  19   DNSsec scenarios . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   40

1 Overview of DNS: general features and security con-
1.1 DNS Basics
Obviously, one should have prior good knowledge of DNS (Domain Name System)
technology (specifications and implementation) before going through DNS security
and DNSsec technology explanation.
Therefore, this part briefly describes the fundamental concepts of DNS, especially
highlighting the basics we need to know to later enter DNSsec considerations. For
further information on DNS, please refer to specific DNS tutorials ([25] & [26] for in-
stance) or official papers [1] & [2].

1.1.1 Critical nature of the DNS application

The Domain Name System was developed when the number of machines connected to
the Internet started growing fast. Since human beings are unable to memorize a large
number of IP adresses, the DNS was created to map domain names with IP addresses
and other related resources (mail relays, name servers).
The same idea can be found in several other technological fields like the phonebook of
your mobile phone: the phone number is used by the network to reach your correspon-
dents, but for you it is easier to select them using their name.
So there is a need for translating the user-friendly representation of a host (its name)
into the computer-friendly representation (its IP address) which is used in reality for
locating it, and routing information to it. Thus we create an association between names
and IP addresses called name-to-address mapping.
ex:www.nic.fr is converted into

When you have a small number of computers to manage, a simple translation table can
do the job, (ex: the host.txt file used at the beginning of Internet), but when you have
millions of devices connected to the Internet with changes happening on an irregular
basis, a more complex and scalable system must be implemented to handle it: that is
the role of the DNS.

A need for high reliability:
We then understand the stakes behind the DNS: users designate computers with a name
representation that does not make sense in the Internet world. The DNS, as invisible as
it seems to be, is used as a preamble of any Internet communication (mail, web pages
Should the DNS crash, the Internet activity would be in jeopardy, because it would cut
the link between users and computers worlds: the names you know are meaningless on
the Internet if they are not properly translated into routable addresses.
In a technical sense, the Internet would still work with the DNS down, but it would
be nearly unusable with a human point of view: you would have to remember the IP
address of each machine you want to communicate with.

In its current use, one drawback of the DNS is that you can not really be sure if the host
you are reaching is the one corresponding to the name you entered: you have to trust
DNS name-to-address translation.
In fact, wrong or hacked information in the association between name and address can
lead to terrible consequences (you try to access your bank website by typing its name,
but if there is a malicious association between this name and a wrong IP address in the
DNS, you will be redirected to a fake site without noticing it). That is one of the most
classical attacks, see section 1.2.3 for more details on that issue.

As it deals with crucial information, we need a high level of reliability in both DNS
design and DNS data. That is the goal of DNSsec extensions we will enter upon in part

1.1.2 General design of the DNS

The DNS as we know it today was designed in 1984 by Paul Mockapetris and standard-
ized at the IETF by RFCs 1034 [1] and 1035 [2]: basically it follows a client/server
scheme, where the resolver (client) asks information about name-to-address mapping
to a name server (server).
The DNS name-to-address mapping is usually described as a hierarchical, distributed,
redundant database. Let’s have a further look on these three features

                                        "."(DNS root)

                    nl            fr              com            org

                    prd          com       gouv

                    idsa          numerobis              telecom

                                   Figure 1: DNS tree


        DNS database is a hierarchical structure like the inverted tree of a UNIX filesys-
        tem. It is called the domain name space, starting from the root (denoted as a dot:
        "."), which is father of the TLDs (Top Level Domains) and so on. Ex: fr and nl
        are ccTLDs (country code TLDs) and org and com are gTLDs (general TLDs).
        Each node of the tree corresponds to a domain associated to its label; the domain
        name of a specific node is obtained by going up in the tree, starting from this

       node, separating each label encountered by a dot.
       ex: the name of the idsa domain is "idsa . prd . fr ." (the last ".", corresponding
       to the root can be omited). see fig. 1
       This hierarchical structure guarantees the absence of name collision because the
       only constraint is, like in a UNIX filesystem, that two children of the same parent
       have different label. Ex: fr.com and com can coexist.


       The DNS is a distributed database: The tree structure described just before facil-
       itates the distribution of the database. In fact, any subtree, starting from a given
       node and going down the tree (a domain) can be delegated to a local administra-
       tion. This avoids the heaviness of a fully centralized administration, specifically
       to make domain updating easier. If there are changes occurring in a specific
       domain, the DNS updates are performed by the administrators in charge of that
       domain, fastening the process. However this local administration does not bother
       the global avaibility of the data, as we will see later on.
       One other advantage, is to minimize the risk of a full DNS breakdown: if a sub-
       domain has technical problems, that will not affect the rest of the tree. Of course,
       if the top of the tree (ie. the root) is down, nearly nothing is going to work. But
       it is not likely to happen.


       The redundancy of the data obviously brings an increase in robustness and per-
       formance: several servers store the same data, increasing and geographically
       spreading data availability and protecting service in case of the crash of one
       ex: there are 13 root servers containing the same data (TLDs name servers infor-
       As a matter of fact, the redundancy introduced must be totally consistent with
       the original data; and all efforts must be made to guarantee this consistency.

1.1.3 Domains and zones

A domain, as we introduced it in 1.1.2, is a subtree of the domain name space. A do-
main can be included in another one: we call that a subdomain. Except for the whole
Internet domain (starting from the root), every domain is a subdomain of another do-
Ex: the fr domain contains all the domains finishing by .fr (cnrs.fr domain; inria.fr
domain...). you can sometimes go further, the gouv.fr domain is divided into many
subdomains like telecom.gouv.fr, finances.gouv.fr, etc.

The concept of zone comes from the administration decentralization described in 1.1.2:
to facilitate things, a domain can delegate the responsibility of a subdomain to a local
administration. It is not compulsory, a domain can delegate some of his subdomains
and keep the responsibility for the others, it is a question of local policy: delegating
facilitates subdomain administration, but diminishes control over it.
A zone is administrated by its name servers which are said authoritative for the zone.
They contain all the information related to the zone in a zone file (name-to-address

mappings, mail servers, and other information). These authoritative servers are re-
sponsible for all the zone data (NB: they can be authoritative for several zones), and
they also include references to the subdomains (children zones) delegated: information
on the children zones name servers.
A zone that delegates authority to a subzone is called parent zone of its children zones.

          fr domain                                    fr
          fr zone
          idsa.prd.fr domain
          idsa.prd.fr zone

                           inria          prd               gouv            cnrs

                                   idsa                                      telecom

                   ftp     www        afnic     enst         ftrd   irisa

                                 Figure 2: zones and domains

Authoritative servers have entire responsibility over the zone information, that’s why
they must be carefully configured, and the zone data have to be kept up to date. Thus,
delegation must be cautiously considered, because you give responsibility for these
crucial DNS data to other name servers.

A zone is then a responsible island, that has exclusive control on its own data, but at the
same time, a zone is part of the DNS delegation chain looking after its children zones
as well as being looked after by its parent zone (except for the root). This design will
be efficiently used by DNSsec, as we will see in part 2.

1.1.4 DNS infrastructure

        Resolvers (client part of the client/server scheme): basically they send requests
        on the behalf of a program to a name server. Then they give back the appropriate
        information to the program (browser, mail client,...). That is what a stub resolver
        (the most frequent ones) can handle. Some of them are smarter, building a cache
        and performing security verifications, but they are quite rare.
        Usually on a LAN, each host has its stub resolver configured to query a specific
        recursive name server located on the network. This server will do all the DNS
        data retrieving job and will send back the appropriate information to the resolver.


    Name Servers: there are two main categories of name servers.
    -Authoritative name servers: they have authority on one or several zones. Usu-
    ally, for each zone, there are several authoritative name servers. Among them,
    one is called the master or sometimes primary, because it contains the original
    zone file related to this zone. This is also referred to as the Start Of Authority
    (SOA) for the zone. The other name servers (slaves) get a copy of the zone file
    from the master every time it had been updated (zone transfer procedure).
    The authoritative servers (master or slave) must answer all the queries regarding
    data contained in their zone file, usually they are questionned on a round robin
    basis to enhance performances.
    So, from the query point of view, a slave server should be as trustworthy as
    a master, because they have the exact same role: they all deliver authoritative
    answers. Secondaries should then be considered with caution, because even if
    your master is safe enough, a problem (attack or misconfiguration) during zone
    transfer can be highly damageable: from the querier point of view, authoritative
    answers have the exact same value, should they come from a master or a slave.
    These zone transfer are among the most critical phases of DNS operation.

    -Recursive name server (sometimes called caching name server): usually a re-
    cursive name server is not authoritative for any zone, but in certain cases it can
    happen (even though it shoud be avoided as far as possible). Basically, they are
    configured on every network to be queried by local resolvers (as seen before).
    They have a traditionnal cache composed of data already queried associated with
    a TTL (time to live) which has been transmited along with the data by the au-
    thoritative server. The data will disappear from the cache at the end of the TTL.
    When queried, a recursive name server tries to find the desired data in the cache,
    if it’s not there, it looks for the data by retrieving the corresponding authoritative
    server and querying it (cf 1.1.6). Classically, the caching scheme avoids inap-
    propriate load of the network, inappropriate load of the authoritative servers by
    knowledge sharing and permits the fastening of the whole process.
    There are also subcategories of recursive servers whether they forward the queries
    first to another recursive name server or not.
    One specific feature of the recursive servers that makes them potential security
    holes is that they nearly do not have any control over the content of their cache:
    it depends on the resolvers queries, and the authoritative servers answers. This
    is all the more delicate that usually they are trusted by many hosts’ resolvers.
    Wrong and cached information is harmful for the duration of the TTL.
    Polluting a cache with wrong information is the goal of a famous attack called
    cache poisoning (cf 1.2.3).


    There are two modes of name resolution: recursive and iterative. Basically, a
    name server in the recursive mode will carry out the whole name resolution pro-
    cess by asking all the name servers needed and returning the answer. In iterative
    mode, a name server will return information only if it is authoritative for; other-
    wise it will just give the adress of the closest authoritative name server it knows
    regarding the question. At least, all the name servers have the list of the root
    Ex: the authoritative name server of fr, ns1.nic.fr being asked for the address of
    wwww.iana.org will return the list of the authoritative servers of .org.

        Usually, and preferably, an authoritative server is designed iterative to avoid in-
        appropriate recursive processing time. On the other hand, a recursive server,
        especially if queried by resolvers has to be recursive to provide a complete re-
        sponse for each query. (cf scheme)

1.1.5 DNS data

DNS data is built on the use of RRs (resource records) which are the smallest pieces of
DNS information. These RRs can be gathered in different ways to meet the needs of
the different parts of the DNS architecture (zone files, DNS queries/responses, cached
data). A zone file (fig. 3) is composed of all the data related to a zone. These data are
divided into several slices corresponding to various features of the zone. Each of them
is called a resource record, basically a RR associates a certain type of information to a
name belonging to the zone. We call RRset several RRs with the same name, type and
class (see below).
There are predefined resource records: the first one which is always present is the SOA
(Start Of Authority) of the zone, containing many technical parameters of the zone
(the version of the zone file: the serial, the master server, various information related to
zone transfers between authoritative servers, etc.). Here are the other main RRs (before
DNSsec era):


        NS: gives the name of the name servers of the zone.
        It is also used in a parent zone to advertise name servers of a child zone: that is
        called a delegation point. In that case, you normally do not put the IP address of
        the child name servers, but if these name servers are included in the child zone,
        this would lead nowhere: in this specific case, you need to specify the address
        with an A (or AAAA) RR. This is called the glue process.


        A:this is the mapping we were talking about in 1.1.1, it gives the association be-
        tween a name included in the zone and its IPv4 address (we currently use AAAA
        for IPv6). On fig.3, we see that the address of hello.idsa.prd.fr is


        MX: the mail exchanger which you have to send mail to for the zone or specific
        hosts of the zone.


        PTR: this is the reverse mapping which associates a name to an IP address


        CNAME: an alias for a name.


        All these RRs, when requested by a query are associated with a TTL (global for
        the zone or specific for the RR) which will define the maximum time the RR will
        stay in a cache. This value starts decreasing as soon as it is stored in a cache, but
        will always keep its original value in the zone file.


        As you can see on fig. 3, the owner name of a RRset can be a ’*’ which is called
        a wildcard. This means that the record is associated to any name of the zone that
        hasn’t a record of the same type already specified.
        ex: on fig. 3, the wildcard means that the MX of any name of the idsa.prd.fr
        zone is relay4.nic.fr, except for hello.idsa.prd.fr (relay3.nic.fr). For instance
        +.idsa.prd.fr may cover test.idsa.prd.fr or test2.hello.idsa.prd.fr.

               $ORIGIN idsa.prd.fr.

               $TTL       172800 ; 2 days
 zone apex      @                        IN    SOA     ns1.afnic.idsa.prd.fr. hostmaster.nic.fr. (
                                                       2002121004      ; serial
                                                       6H              ; refresh
                                                       1H              ; retry
                                                       3600000         ; expiry
                                                       1D )            ; minimum

   NS RRset                              IN    NS      ns1.afnic
                                         IN    NS      ns2.irisa
   RR Class
 Owner Name    hello                     IN    A                   RR type
                                         IN    MX      relay3.nic.fr
   Wildcard     *                      IN     MX      relay4.nic.fr                Rdata
 Delegation    enst                      IN    NS      ns1.enst
               ns1.enst                  IN    A
                                         IN    AAAA    2001:660:282:1:206:5bff:fe8d:1caa

                                 Figure 3: idsa.prd.fr zone file

All these RRs have the same top level format composed of 6 fields:
-the name of the domain the RR is related to (RR owner name).
-the type of the RR, as described above, it’s one of the different categories (A, SOA,
-the class: IN (Internet) for normal DNS operation.
-the TTL (on fig.3, the TTL is common for all the data of the zone: 17800s).
-RDLENGTH: lenght of the RDATA field.
-RDATA: description of the resource (ex: an IP address in the case of an A RR).

The format of all DNS messages is the same, whether they are queries or answers. A
DNS message is carried in a single UDP packet (except when it is impossible: if the
message exceeds 512 bytes, or for zone transfers, the use of TCP is possible) and ad-
dressed to port 53. It is composed of 5 sections:
-the header contains a certain number of fields; among these, the most important are the
ID of the query, several flags (recursiveness of the query, authoritative answer or not,
etc..), the RCODE that gives the status of the answer (no error, name error or other).
-the question section is meant to carry the question, and is composed of QNAME,
QTYPE, QCLASS that correspond to name, type and class described above (here
QTYPE can also be AXFR which refers to a zone transfer).
-the answer section is composed of a variable number of RRsets that answer the ques-
-the authority section carries RRs related to the authoritative servers regarding the zone.
-the additional section may carry some extra RRs usually related to the query and that
should avoid future extra query , but the queried server can put here whatever RR it
likes, which can be a problem as we will see later on.

The dig tool (see section 3.5) initiates DNS transactions, and displays the DNS re-
sponse to the query made. The nice thing is that the response displayed is really alike
the DNS message itself, and the header and its different fields, as well as the different
sections are easily recognizable.

DNS messages have been designed to be very simple, with the same preformated struc-
ture for queries and answers that should fit in a single UDP paquet. This increases ef-
ficiency in DNS exchanges (strongly formatted, unfragmented messages are processed
faster by name servers), but that also means that it is quite simple to forge fake packets
and hack the system as we will see in section 1.2.3.

1.1.6 Name resolution: how it works

                                  Caching Server                            Authoritative
                                  (ISP, LAN, ...)                              Servers
        =iterative request
        =recursive request                                                    Root server
                                      Cache           fr(NS)=nsi.nic.fr          (".")
                                               s     www.idsa.prd.fr(A)?
 Client             (1)         (2)            o                               fr server
            www.idsa.prd.fr(A)?            (4) l       idsa.prd.fr(NS)=      ex:ns1.nic.fr
 Resolver                                      v        nsi.idsa.prd.fr
      (5)              r      www.idsa.prd.fr(A)?

                                 Figure 4: DNS requests

Let us consider the case of a computer on a LAN which wants to get the address of
Classically, its resolver is configured to send all its queries to the recursive name server
located on the network. So the resolver is going to send a recursive query for the IP ad-
dress (RR A) of www.idsa.prd.fr to this recursive name server (1): he wants the server
to do all the retrieving job and send back the answer at the end.
The recursive name server looks up first in its cache (2) to check if this query could
benefit of some previously cached information that would ease the work (ex: the NS
of idsa.prd.fr or even the NS of fr which is better than nothing). Here we consider that
the cache does not contain any helpful information.
Then the full retrieving process begins (3): each and every server has the list of the root
servers preconfigured, in order to have a known entry point on the DNS tree.
The resolver of the recursive server asks one of the root server for "www.idsa.prd.fr,
RR=A". The root server is only aware of the delegations to the TLDs zones, he doesn’t
know about idsa.prd.fr, so, as it is configured non-recursive (like every authoritative
server should be), it will answer with the only information it is aware of: the NS RRset
of the TLD fr.
But, as some of the NS of fr (ns1,2,3.nic.fr) are part of the fr zone, it is useless for

the resolver, unless it also gets the glue (IP address associated to the NS in the parent
Then it can ask for example ns1.nic.fr for www.idsa.prd.fr, it will get back the NS of
the zone idsa.prd.fr and the glue associated (please note that it is a special situation
because ns1.nic.fr is both authoritative for fr and prd.fr, thus it can directly return the
NS of idsa.prd.fr. However it is still an iterative process).
The recursive name server sends a query to one NS of idsa.prd.fr, that will send back
an authoritative answer (flag aa in the header of the DNS message) with the IP address
of www.idsa.prd.fr:
At the end, the recursive name server has the answer for www.idsa.prd.fr, RR=A. Then
, it will put this in its cache (4), along with the intermediate answers it got (the NS of
fr and idsa.prd.fr), all of them associated with their TTLs.
Finally the recursive name server sends the answer back to the resolver of the computer
that needed it (5).

If in the future, if a new query is submitted to the recursive name server, the data pre-
viously cached is going to be used efficiently to increase performances.
ex: if www.inria.fr is queried, then the NS record set of fr will be used. If ftp.idsa.prd.fr
is queried, the NS record set of idsa.prd.fr will be used.
The data cached can be used until their TTL expire, at this moment they are cleaned
out of the cache.

1.2 Security threats and expectations
1.2.1 Networks security fundamentals

All networks have this in common, that all the deployed infrastructure has no other
goal than bringing resources (people, goods, information..) from places to other places
with the highest level of safety. Theorically, cost, speed and efficiency considerations
come afterward. Security is then the center of attention of networks models.
In telecommunication networks, the resource is information, which is by nature impal-
pable but that can have high intellectual or commercial value. Then information has
to be carefully protected against threats, should they be accidental or intentional. The
targets of these threats can either be:
-the infrastructure: weaknesses in links and hosts reliability and availability.
-the information itself: sender’s identity deception, eavesdropping, information modi-
fication, etc.

In order to secure information exchanges, four fundamental services based on crypto-
graphic tools have been defined:
-messages confidentiality.
-data integrity.
-identification of the participants.
-authentication by a trusted authority.

These services can be applied at one or several layers of the OSI model depending on
the need:

end-user to end-user or host to host, flow selectivity, application selectivity or noselec-
ex:IPsec is a layer 3 non end-to-end, flow selective service
SSL is a layer 6 end-to-end, application selective service.

1.2.2 DNS specific need for security

The goal of DNS is to provide various answers to questions such as name-to-address
translation. Like in every client/server scheme, this is all about getting the real answer
to the real question.
So we need to know who sent back an answer to a question with no doubt (is he the
one we think he is), and we have to be sure that the answer sent is exactly the same as
the one received.
Besides, the DNS design philosophy is based on the fact that all DNS data should be
public and that everybody may have equal access to these data. We don’t have to worry
about eavesdropping on DNS communications: the confidentiality of these communi-
cations has never been a priority, and should not become one with DNSsec.

We also have to take into account the technical design of DNS (see 1.1.2):
the fact that it is hierarchical facilitates the installation of trusted authorities, because a
child zone already trusts its parent zone, and so on, this is what we will call the chain
of trust in section 2.
the fact that it is distributed makes impossible the use of symmetric cryptography, be-
cause of the huge number of parties a name-server has to communicate with.
The fact that it is redundant creates a new specific need: securing these highly criti-
cal communications between two authoritative servers for the same zone (master-slave
zone transfer). Here we can use symmetric cryptography, because a master and a slave
know one another.

And finally, considering security extensions to be added to DNS, like in every protocol
upgrade, we have to provide backward-compatibility with the DNS original design, es-
pecially by keeping the DNS message structure unchanged.
Indeed, securing the whole DNS tree will not be achieved at once; that means that
at some point, DNSsec-compliant entities will still have to communicate with non-
DNSsec-compliant entities.

1.2.3 Well-known attacks on DNS and consequences

The goal of a person who is trying to attack the DNS system is usually one of the fol-
-disturbing or slowing down DNS operation (usually with DoS which is not a DNS-
specific attack).
-preventing people from accessing specific hosts for political or economical reasons,
or simply for the sake of it.
-redirecting people to malicious hosts, facilitating further damage.

                Zone data                                              Traffic
              falsification                                           corruption


                                         Slave(s)                      corruption/
                                                                     Cache pollution
                                Zone transfer

                              Figure 5: DNS weaknesses

Here we will have a look on DNS-specific well-known attacks which mainly corre-
spond on fig.5 to traffic corruption and cache pollution. A report currently under draft
status at the IETF analyses the threats against which DNSsec is designed to protect
One of the generic term usually used is DNS spoofing, where the attacker answers to
a query in place of the real server queried. This can be done in different ways and can
lead to various consequences:

-Man-in-the-middle: this is the classical attack, where the attacker has the ability to
sniff communications on a given network. When he detects a query addressed to a
name server, he will answer faster than the name server using the same DNS ID than
the query in a forged response, thus providing whatever information he wants to the
inquirer; for instance a wrong address redirecting the inquirer to a fake website the
attacker has control on.
This is all the easier, as a DNS query or answer is usually contained in a single, un-
signed, unencrypted UDP packet. The main limitation, though, is that the attacker must
be on the same local network.
NB: note that the attacker may just want to do denial-of-domain by sending an answer
indicating that the domain requested does not exist. Specific protection will be de-
ployed in DNSsec, because it is much more difficult to authenticate the non-existence
of something than its existence. We will talk about that in section 2.

-ID/query guessing: another way of answering in the place of the real server is to use
a mix of guessing and knowledge of the query (and the ID associated) made by the
In this case, the attacker cannot sniff the network for queries, it is then much more dif-
ficult, because in order to cause any harm, he has to have knowledge of the query made
by the victim and the ID of the query. The attacker has then to push the victim to ask a

                             www.example.com(A)? ID=13
                              www.example.com:               server
                    ID=13    sniff


                            Figure 6: man in the middle attack

specific question (for example if the victim is a recursive server, the attacker asks him
a question that will result in a known query by the recursive server to an authoritative
Then the attacker will forge an answer to this probable query, and answer back before
the real authoritative server. In order to use the correct ID, he will use implementation
flaws (sometimes queries IDs are just sequential).
But there is a much heavier method:
DNS ID is coded on 16 bits, as well as the client port, that gives us 2ˆ32 possibilities
(sometimes only 2ˆ16 when the same port is always used by the client). That seems to
be huge, but with a method called "birthday attack", based on the birthday paradox,
you can have pretty good results.
Here you send to the victim n times the same query (www.example.com, A) instead of
one (1). The victim, trying to do its recursive server’s job, will then send n identical
queries to the adequate authoritative name server (ns1.example.com) , using different
IDs (2).
The attacker then sends n times its answer (www.example.com= using differ-
ent IDs and/or ports, while at the same time flooding the real name server with bogus
queries to slow down the real answer(3).
The probability that a fake answer’s ID matches one of the queries’ ID is dramatically
increased (about 100 times more efficient...), this is called the birthday paradox.

                 server for


                    server                          (3)

                               Figure 7: "birthday attack"

-Cache poisoning: As useful as a cache may be, it is also a very interesting target for

malicious attackers, because a single attack can lead to many dysfunctions. In fact if
somebody happens to introduce wrong data in a cache, it will stay there for the duration
of the TTL; many people can then be deceived for a long period of time.
Using one of the two previous methods, it is really easy to poison a cache with fake
data. It is even easier if the attacker possesses a name server that could be queried for
a valid zone he has control on, then the attacker can add fake information about other
zones in the additional section. Fortunately, it is now recommended that a cache should
not trust additional information with no relation with the query.

-Betrayal by a trusted server: Sometimes, the recursive server trusted by a resolver de-
liberately or accidentally gives away wrong answers. It is a matter of confidence and
mistrust toward the recursive name server you told your resolver to query. It is up to
the users to carefully choose the recursive name server they want to trust.
It has already happened that in some countries, ISPs caches have voluntarily been
spoofed by the government to prevent people from accessing "forbidden websites":
the DNS entries were redirecting people to other websites. In that particular case, DNS
spoofing is used for political means.

1.3 Security requirements beyond the scope of this document
As we will see in part 2, DNSsec extensions have been designed to answer DNS spe-
cific needs for security (see 1.2.2). But DNS components may be potential targets to
more classical attacks just as every node on the Internet.
It is obvious that before considering to deploy DNSsec, one should first respect general
security requirements regarding its DNS components and design.

1.3.1 Security threats non DNS specific

The most famous one is the DoS (Denial of Service) or the more efficient DDoS (Dis-
tributed Denial of Service) that can be targeted against any server of the Internet. The
name servers are then also potential victims.
In fall 2002, such an attack was directed toward 7 of the 13 root servers, resulting in
a global slow down of DNS operations, but no interruption of service was reported.
It is difficult to say if DDoS could seriously harm DNS, and for how long. Anyway,
security solutions to such attacks have nothing to do with the specific nature of DNS
servers, it is a more general server problem.

1.3.2 Adequate server configuration

Please refer to best practices articles and tutorials (for instance [25],[28] or [29]) on
how to configure a name server and how to design an adequate DNS infrastucture on
your local network in a secure manner.
We consider in the next part that all these classical requirements have been met.

2 DNSsec principles

2.1 Selected solutions for security
It has become obvious that such a critical and vulnerable actor of the Internet, as DNS
is, had to be secured. DNSsec (DNS security extensions, RFC 2535)[5], which is a
protocol extension of DNS, proposes a set of solutions to secure DNS. We recall here
that these solutions have been designed to be DNS-specific and to strictly fulfill DNS
need for security.

Note that these extensions are still being discussed at IETF even if first specifications
have already been released (RFC 2535).
A set of papers that are still under draft status will be used to write a new version of
DNSsec that will probably obsolete the RFC2535 implementation in the near future
(please refer to [17], [19] and [23] among others).
The main upgrade brought by these drafts is DS (Delegation Signer, described in [21])
that applies on a very specific field of DNSsec: the trust relationship between a parent
and a child zone. Apart from DS, there will be slight evolutions but no revolutions.

Basically, DNSsec uses cryptographic signatures to authenticate DNS information. But
that had to be done in a certain manner, as introduced in 1.2.2:


       Because there was a need for data integrity, and not data confidentiality, a signature-
       based solution rather than an encryption-based solution was preferred (better per-
       formances): the public nature of DNS data will remain with DNSsec.


       Because of the large number of parties a DNS component (resolver or server)
       has to communicate with, it was obviously a public cryptography solution that
       had to be chosen (no pre-shared secret).


       As a protocol extension, DNSsec had to stick to DNS existing features, espe-
       cially regarding DNS messages format. The necessity to provide backward com-
       patibility with DNS definitely restricts the choices in terms of possible security
       solutions (keys and signed items).


       In fact,the question was: what had to be signed and by who? it could have been
       the whole DNS message, but with what key, provided that a DNS message can
       carry various pieces of information from different zones. In fact, the RR struc-
       ture of DNS information and its classification into zones facilitated things for
       two reasons:

       -In the same DNS message, each RR could be signed separately, for instance
       with different keys if they belonged to different zones, and that gives us a very
       precise authentication, and facilitates authenticated information storage.
       -The key used and the signature generated could be formatted in a RR style,

        which permits to keep the whole DNS RR philosophy. In that way, DNSsec does
        not add any new objects, just new RR types. And then keys and signatures are
        stored in zone files and cached like any other RRs.


        The hierachical structure of the DNS tree allows a scalable deployment of DNSsec,
        because each zone has its own keys to secure itself. But, at the same time, this
        local security can also acknowledge childrens’ zone security or be acknowledged
        by a secure parent zone. This is what is called the chain of trust, we will discuss
        that later on.

2.2 Services provided by DNSsec
DNSsec defines 3 security services that are added to the DNS protocol [19]:

-Data origin authentication and Data integrity, designed to protect data queried.
-Transaction security, to protect DNS "administrative" procedures.
-Key distribution, to make the previous two services work.

2.2.1 Data origin authentication and Data integrity

The goal of this first service is to ensure that DNS data queried by a resolver or a
recursive name server comes from the server that has authority over the data (origin
authentication), and that this data has not been corrupted on its way from the source to
the destination (integrity check). As it was mentionned before (section 1.3.2), DNSsec
cannot ensure the correctness of the data if it was misconfigured on the authoritative
name server.
The starting point of DNSsec is that each zone is going to generate at least one key pair
(public and private parts). The important thing here is that keys are associated with
zones, not servers.
In fact, RRsets are signed in their zone by the private part of the zone key. We then
introduce two new RRs, the KEY RR which will store the public part of the zone key,
and which can be queried like any other RR, and the SIG RR, which corresponds to
the signature of a specific RRset of a zone by the zone key (there may be several zone
keys). More details on these new RRs will be given in section 2.3.
This signature makes it possible to check the integrity and the origin of the RR it is
associated with. Once a resolver gets the KEY RRset of a zone, it is able to verify
the integrity of any RR of the zone, by running classical public cryptography integrity
check described in section 2.3.

Thus, the only constraint is to get the key of a zone in a secure manner. This is a critical
part of the DNSsec mechanism.
There are several ways to do that:
-statically configure the public key in the resolver.
-discover the key by DNS resolution, but in that case the key has to be authenticated
itself by another key the resolver trusts.

-obtain the key off-the-band.

The limitation is that each zone has its own key(s), so it is impossible to configure a
resolver with that many keys. Then we have to rely on the hierarchical structure of the
DNS tree, by building chains of trust:
Basically, a resolver has to trust at least one key from the begining. This key will enable
authentication of any other keys signed by it. Each time a new key has been authenti-
cated by a previously trusted one, it can itself authenticate other keys, and so on.
In the case of DNS, the tree structure contributes to facilitate things:
a zone key can authenticate its children zones keys, and so on down the DNS tree, a
process often referred to as "chains of trust".
When a resolver trusts a key from a certain zone (secure entry point on the tree), it can
get the keys of its descendants in an authenticated manner, going down the tree. When
the whole DNS tree is signed, the secure entry point will be the root, and as it is the top
of the tree, its key can authenticate any other zone of the DNS tree thanks to the chains
of trust

This key authentication chain process is being worked on at IETF[21], as a new draft
updates the original RFC 2535. This new proposal has been designed to facilitate op-
erational things, but the philosophy remain the same.
We’ll discuss that in details in section 2.5.3.
-in the RFC 2535, a parent zone key signs its children zone key
-in the draft-DS, a new RR has been introduced, DS (delegation signer), placed in the
parent zone, it authenticates the child zone key, avoiding the heavy process of child-key
parental signing.

The specific case of denial of existence:
we’ve just talked about authenticating RRs, but sometimes an answer does not contain
any RR in the case of a negative answer (RCODE=name error), ex: the name queried
does not exist, or a RR queried for a name doesn’t exist.
In that case there would be nothing to sign (no RR in answer), so this non-existence
cannot be proven in the way mentioned before.
To provide the same level of authentication and integrity as for the positive DNS an-
swers, a new RR has been created, the NXT RR. NXT RRs are inserted in the zone file
between consecutive names. A negative answer (for a name or RR type non-existence)
will be then composed of a NXT RR, that is signed and then authenticated. We will
explain this in details in section 2.4.3.

2.2.2 Transaction security

Along with RRs origin authentication and data integrity, there are specific cases where
a whole DNS message authentication is needed (we want to secure the whole DNS
message including the header at once).
These transactions are mainly related to the "administrative" part of DNS, like zone
transfers between authoritative servers and dynamic updates [12] (when a zone file lo-
cated on a server is remotely updated from an authorized client).
Zone transfers must provide a perfect copy of the master zone to slaves and we saw in

section 1.1.4 such a critical phase it was; it is not the authenticity of each and every
RRset which is important here but the integrity of the zone as an entity. Here the au-
thentication must be made with a key that is specific to name servers and not zones as
before, because this is the whole transaction that has to be signed. One of the solutions
proposed is based on symmetric cryptography because the master and slaves servers
that will use it know each other. A secret key is generated and has to be shared by the
two servers.
A new and peculiar RR called TSIG (transaction signature, RFC 2845[9]) has been
created, which is a meta RR because it must never been stored in the zone file; it is dy-
namically computed by applying the name server private key on the DNS message, and
then it is added in the additional section of the message. More details will be provided
in section 2.5.2.

The main idea here is that the two entities which want to communicate in a secure
manner know one another, so it is possible to use private cryptography. That is why it
is also possible to use this method for dynamic updates: the name server knows which
remote clients are allowed to perform updates on its zone files.
There is another interesting field of application for this method: the link between a stub
resolver and its preconfigured recursive server.
The recursive server does all the retrieving job, plus it will also do the verification of
the data thanks to DNSSec; the stub resolver will then get back information it can trust,
because it knows that the recursive server did validate the data.
But there is still a weakness in that kind of model: we may want to secure the link
between the stub resolver and its recursive name server as well. There are various pos-
sibilities to do that, including non-DNS specific method, like IPsec. However, it is still
possible to use TSIG because the resolver and the cache know one another. The only
limitation is that the cache may have numerous resolvers using it, resulting in a large
number of secret keys to handle. We will talk about that in section 2.6.

2.2.3 Key distribution

DNSsec has been designed in a way where, a KEY record is, in its classical use, as-
sociated with a name, not a name-server, keeping the spirit of RRs. Then DNS has
the ability to distribute zone public keys (the KEY RDATA has fields corresponding to
the zone associated and a personal identifier), making easier the key retrieving process
required when building a chain of trust.
In addition to that, and in order to avoid a dramatic increase in DNS queries load, KEYs
RRs can be added in the additional section of an answer.

It was first suggested than the KEYs records could also be used to store certificates[?]
or public keys used in other applications/protocols (TLS, IPSEC, ...), giving to the DNS
a kind of PKI status. However, concerning the keys, this has for the moment been post-
poned [16], because as DNSsec has been designed to exactly fit DNS security matters,
and considering the diversity of keys that can be used in other protocols, it is not very
clever to use the same specific KEY RR for that many different purposes. Even the
concept of APPKEY, which was a RR later proposed to store non-DNSSec specific
keys in the DNS was recently abandonned, and we may eventually reach a situation

where a different RR type would be created for any different type of key usage.
The hierarchical architecture of DNS associated to the security brought by DNSsec
make it look quite similar to a PKI (for the technical aspects at least), but this proto-
col doesn’t meet more general features that such an infrastructure would require: for
instance the CRLs (Certificat Revocation Lists) and the heavy administrative aspects
of a PKI. DNSsec may then just be considered as a simplified PKI, that could help
other applications in need for security, as long as a good solution is found to store the
associated non-DNSsec keys.

2.3 Cryptographic features
DNSsec relies on cryptographical tools to ensure security. It is mainly based on asym-
metric cryptography used to handle digital signatures (the exception is TSIG which
uses symmetric cryptography).

Public (or asymmetric) cryptography has this advantage over private (symmetric) key
crypto, that there is no need for the entities which want to communicate in a secure
way to share a secret beforehand.
The main idea is that you are going to generate a key pair (private/public).The private
part has to remain secret and shall never be disclosed to anyone, whereas the public
part has to be advertised to anybody who wants to communicate with you. The speci-
ficity of this key pair is that one part can decrypt what the other part has encrypted. For
instance, if you want to send a message to somebody, and that nobody else should be
able to read it, you will encrypt the message with the public part of your called party’s
key; then he will be the only one who will manage to decrypt it because he is the only
one who knows the private part of his key. The only limitation is that I have to be sure
that the public key I am using really belongs to this person.
The example above described the use of public keys to ensure a confidentiality service.

Let us now recall here general concepts of digital signatures: they are used to authenti-
cate the origin of some data and to protect their integrity during their transmission over
some medium.
DNSsec is going to use digital signatures based on public key cryptography to protect
DNS data (we don’t need confidentiality). The process is based on the same concepts
but used in a different way than in the example above: here the signer signs with the
private part of the key, and anybody can decrypt it, should they have the correct public
Usually, and this is the case here, we do not sign the whole message we want to secure,
but a digest of it: it is a sum-up of the message obtained with a one-way hash function,
meaning that it is impossible to get the original message back from the hash (see fig. 8).

There are two parts in the process: the signing part and the verifying part. Should there
be changes, either malicious or due to medium problem, that corrupt the original mes-
sage or its associated signature during its transmission over the network for instance,
then the checking process would detect that the integrity of the message has been lost
and the message would consequently be discarded.

                                                                       file              Hash

                             file      Network        file
           Hash                                                                               same?
private                       sig                     sig              key


          SIGNING                   TRANSMITTING                          VERIFYING

                   Figure 8: public key crypto used for digital signatures

2.4 The new RRs in detail
2.4.1 The KEY RR

As we introduded it before, the KEY record (initially described in [5], then updated by
[20]) is used to store the public part of a key pair. The key is associated with a unique
name. In 2.3, we reviewed public key cryptography and the necessity for people who
want to decrypt digital signatures to have access to the associated public key. KEY RR
will be queried for, using normal DNS retrieving mechanism, anytime somebody has
to verify information that was signed by the private part.
There are two main types of KEY:
The zone keys which are used to sign authoritative data for a zone, their owner’s name
is therefore the apex of the zone. They are the most common keys.
Other keys are used for other DNSsec related operations like SIG(0)[11]. The owner’s
name is in this case the name of the host that is using it (see 2.5.2).

NB: A zone can use as many zone keys as desired (for instance using different algo-
rithms); among these keys, several of them are used to sign the zone’s RRsets, they are
called zone signing keys (ZSK). Usually, one of the zone keys can be allocated to be
specifically the link in the chain of trust: it only signs the KEY RRset and is the only
key authenticated by the parent zone, it is called the Key Signing Key (KSK).
KSKs and ZSKs have the exact same structure except than one of the flags has been
devoted [24] to differenciate them (currently, flag number 15 set to 1 means KSK). But
they don’t have the same role at all: KSKs are only used to link parents and children in
the chain of trust, whereas ZSKs are used locally in a zone to authenticate data (a ZSK
can be changed without reference to the parent zone, but a KSK obviously cannot be).

The KEY RR has the same global structure as any RR (see section 1.1.5), where the
name field is the name of the zone in the case of a zone key. The RDATA field is obvi-
ously specific to the nature of KEY:

-the flags: they specify a certain number of features of the key, or are reserved for future

                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    |              Flags            |    Protocol   |   Algorithm   |
    /                                                               /
    /                            Public Key                         /
    /                                                               /

                            Figure 9: KEY RDATA format

use. For instance, the two first flags set to 1 means that there is no key (NULL-KEY)
and that the zone is known insecure (the concept of NULL-KEY is related to RFC 2535
and was used in a parent zone to designate a child zone as known insecure, but it’s not
used any longer in draft-DS, and therefore these two bits must be set to zero.
There are currently two bits that are used in the flags: bit 7 is the zone key flag, mean-
ing that if it is set to one, then the key’s owner name must be the name of a zone. If it
is set to 0, then the key record contain a public key used for SIG(0) [11] for instance.
The bit 15 is the KSK bit [24], meaning that if it is set to one, the key is a KSK (note
that if it set to 0, it just doesn’t mean anything special for backward compatibility rea-
Then the usual values of flags are:
256: the key is a zone key, KSK or ZSK.
257: the key is a KSK.
0:the key is used by SIG(0).
-the protocol: as we explained it just before, it was proposed that KEY could store
public keys of various protocols with no direct relation with DNSsec (IPSEC, SSL);
however this possibility has been recently frozen [16], and this field must be set to the
value of 3 (DNSsec)
-the algorithm: several algorithms can be used, among them RSA/SHA1, DSA, Diffie
-the public key field: public key is encoded in base 64. The ID of the key is calculated
by applying a specific algorithm on the public key field: the resulting ID is a 2 byte

NB: zone KEYs are needed anytime somebody wants to perform RR integrity check,
so in order to increase efficiency, the KEY RRset should be included with their SIGs
in the additional section of a DNS message along with the RRs of the answer section
(as long as there is space left in the message. if the KEYs and SIGs cannot fit all, the
message is sent anyway and is not considered truncated, because the problem regards
the aditionnal section).

  idsa.prd.fr.     172800    IN   KEY     256 3 5 (
 owner’s name                             ZVgvQMA6bBxilxciVBu26kugAIEUJLCiUfVY
                  Public part             sWzcm0V32zQxa4uUT1rZ
                  of zone key             ) ; key id = 54272

                                               just a comment
                                         (key id is calculated from
                                           the pub key material)

                             Figure 10: KEY RR example

2.4.2 The SIG RR

The SIG record (initially described in [5], then updated by [20]) stores the signature of
a specific RRset by a specific private key. It is important to notice that with DNSsec
we sign RRsets and not RRs. Each RRset will come with as many signatures as ac-
tive ZSKs present in the zone. Moreover, the KEY RRset is signed by both ZSKs and
Besides, SIG records are only generated to authenticate RRsets that really belong to
the zone.
ex: delegation points and glue that are to be found in a parent zone file must not be
signed in that zone, because that would lead to some confusion: these RRsets are
already signed in the child zone, with a child zone key. We only sign authoritative
information for a zone.

explanation of the different fields:

-Type covered: the type of the RRset signed (1=A, 2=NS, etc..). This bit set to 0 means
that this SIG refers to a transaction signature, like SIG(0).
-Algorithm: the algorithm used to create the signature. It must be the same as the one
of the key associated.
-Labels: number that must be inferior or equal to the number of labels of the signed
RR owner’s name.
www.idsa.prd.fr has a label field value of 4, the wildcard *.idsa.prd.fr has a label field
value of 3, which will not conflict even if this wilcard name is expanded as it is usually
the case (exp.and.idsa.prd.fr is composed of 5 labels which is superior to 3).
-Original TTL: the original value of TTL of the RRset associated. A signature is gen-
erated with the TTL field of the associated RR set to its original value. However, a
resolver may obtain the signed RR after it has spent some time in a cache, meaning
that the TTL value has decreased; in that case, the RR has changed, and the conformity
to the signature would not be respected any longer. Therefore, when checking the va-
lidity of a RR, the verifier must replace the current TTL value of the RR by the original
value found in the original TTL field of the SIG.
-Signature expiration.
-Signature inception.
these two dates define a validity period oustide of which the signature must be consid-
ered as non-valid.

                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    |        Type Covered           | Algorithm     |     Labels    |
    |                         Original TTL                          |
    |                      Signature Expiration                     |
    |                      Signature Inception                      |
    |            Key Tag            |                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer’s Name         /
    /                                                               /
    /                                                               /
    /                            Signature                          /
    /                                                               /

                            Figure 11: SIG RDATA format

-Key tag: the ID number of the KEY used.
-Signer’s name: the name of the KEY RR; associated with the key tag, it represents the
full identity of a key. But it is important to notice that two keys could have the same
owner’s name as well as the same ID; it is a very rare situation (the key tag is coded on
2 bytes), but it would not be a problem.
-Signature field: the cryptographic signature.

                                                                       Algo     expiration
idsa.prd.fr.      172800    IN      NS       ns1.afnic.idsa.prd.fr.
                                    NS       ns2.irisa.idsa.prd.fr.

                 172800     IN      SIG      NS 5 3 172800 20030425140309 (
                                             20030410140309 15230 idsa.prd.fr.
                       sig                   5jNnJqoRhbW9HR0J4vol8BoAhKI7w9vIZY7l
                    inception                qa9Mly6EiWnmS+lcmgRW4vDBOsg= )

                                                              Key ID                   name

                             Figure 12: SIG RR example

A SIG must always be associated to the corresponding RRset in a DNS response. If
there is not enough space in the message to include the SIG (because of the 512 byte
limit for instance),the packet must be considered truncated (TC flag set to 1) and pro-
cessed consequently: the data carried is not secure. The only exception takes place in
the additional section where a RRset can be sent without its SIG if there is not enough

room, but the message will not be considered truncated (we recall that .
When you receive a RRset and its SIG associated, you have to check a certain number
of parameters before beginning the verification procedure (fig. 8). First you will have
to get the correct KEY (the one whose private part generated the SIG). The SIG and
the potential correct associated KEY must fulfill several requirements:
-The signer’s name of the signature must be the name of the KEY.
-Algorithms fields must be equal.
-Key tag field must be equal to the ID of the KEY.
-As we saw just before, there still may be several candidate KEYs, as scarce as it may
be (same name, algorithm and ID). In this case, we will try all these keys in the SIG
verification process. At most, one of them will match.
-SIG must be valid: inside the validity time interval.

NB: We have to consider the interactions of the signature validity with the TTLs of the
signed RRs especially for caching considerations. Caching a data with a TTL value
that does not run after the signature validity is not a problem: the data will be valid
(inside the signature validity intervall) troughout its stay in the cache. But if a cache
query a RR close to its signature expiration time, the TTL may run after this validity
end, and we could have data cached for a period of time where the signature is not valid
any longer. Therefore, the cache should, when needed, trim the TTL value to respect
this validity limit.
An operational possibility (we will see this in section 3) to avoid this situation is to
resign a zone at least ’TTL value of the zone RRs’ before the expiration time.

2.4.3 The NXT RR

NXT record (initially described in [5], then updated by [20]) is a concept that has been
introduced to prove the non-existence of a name or of certain RR types associated to a
name. It has been created to provide something to sign when there is nothing to answer:
If you ask for null.idsa.prd.fr (which does not exist), and there is no wilcard over the
zone, the answer would be an empty packet in terms of RRs located in the answer
section of the DNS message: how would you sign vacuum to authenticate this void
The main idea is to insert NXT records in a zone file between names belonging to the
zone (except for the glues, once again). The owner of a NXT record is a name that does
exist in the zone.
A NXT record lists the RR types that are associated to its owner name, along with the
next name, thus proving there is no other name between the owner name of the NXT
and the next name.

ex:idsa.prd.fr          IN           NXT            afnic.idsa.prd.fr             SOA MX NS NXT SIG

This means that idsa.prd.fr has and only has SOA, MX, NS, NXT and SIG records, and
that there are no other name between idsa.prd.fr and afnic.idsa.prd.fr. This NXT record
would be returned in the authority section for the following queries (for instance):
a query about any RR related to abc.idsa.prd.fr.
a query about an A or AAAA RR for idsa.prd.fr.

The notion of "next name" supposes that names in the zone have been previously
sorted in a label per label canonical order (idsa.prd.fr comes before afnic.idsa.prd.fr).And
to fulfill the loop, the last NXT record announces the first name (the zone apex name),
considering the zone file as circular.
Canonical order example:


Like any other RRs, the NXT records are signed by the zone key, and sent along with
their SIG in answers where needed, in a way that provides the desired non-existence
It is important to notice the specificity of each NXT RR, related to its owner name:
The solution of a single catch-all RR, devoted to express name non-existence, even if
signed by the zone key, would suffer from replays attacks: the attacker first sniffs this
RR authenticating non existence, and can replay it to answer any query targeted to that
For obvious reasons, there is one requiremnt over NXT TTL: it should not exceed the
minimum TTL of the zone.

                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    /                      Next Domain Name                         /
    /                        Type Bit Map                           /

                            Figure 13: NXT RDATA format

the NXT RDATA is made of two fields:
-next domain name: contains the next authoritative owner name in the zone. This is
used to authenticate name non-existence.
-type bit map: 32 bits that identify the RRset types that belong to the NXT owner name
(not the next name!). This is used to authenticate RR non existence, even if the name
queried exists. That gives us a more precise granularity in proving non-existence, not
only names, but also RRs.
This is done on a bit per bit method: bit 1 set to 1 means that RRset of type 1 (A) is
present, bit 2 refers to RR type 2 (NS) and so on...

We also have to take into account the possible existence of wildcard RRs (see section
1.1.5) that can complicate the problem a bit, because names that do not exist in the
zone in terms of NXT records, may just be matching wilcard expansions.

afnic.idsa.prd.fr.       172800   IN SOA   ns1.afnic.idsa.prd.fr. hostmaster.nic.fr. (
                                           2003040102 ; serial
                                           21600      ; refresh (6 hours)
                                           3600       ; retry (1 hour)
                                           3600000    ; expire (5 weeks 6 days 16 hours)
                                           86400      ; minimum (1 day)
                         172800   SIG      SOA 5 4 172800 20030416130318 (
                                           [..]iJj8OF0i5Tuv+MvwybtiGOjgiZE= )
                         172800   NS       ns1.afnic.idsa.prd.fr.
                         172800   NS       ns2.enst.idsa.prd.fr.
                         172800   SIG      NS 5 4 172800 20030416130318 (
                                           [..]HnG0b1Gw9LzgPIoQCox4KpwVkfM= )
                         172800   KEY      256 3 5 (
                         172800   SIG      KEY 5 4 172800 20030416130318 (
                                           [..]S6BO85ONF3uqP1raXg== )
                         172800   NXT      ns1.afnic.idsa.prd.fr. NS SOA SIG KEY NXT
                         172800   SIG      NXT 5 4 172800 20030416130318 (
                                           [..]p8rdaqI0sAy68ChcvK74lOvPl4= )
ns1.afnic.idsa.prd.fr.   172800   IN A
                         172800   SIG      A 5 5 172800 20030416130318 (
                                           [..]u7HsHw1LxC6w4i6uQH7Yux7+cfw= )
                         172800   AAAA     2001:660:3003:1d5a::1:1
                         172800   SIG      AAAA 5 5 172800 20030416130318 (
                                           [..]+EYrpIykwXxk41OT1dDFmoW+4Es= )
                         172800   NXT      ns2.afnic.idsa.prd.fr. A SIG AAAA NXT
                         172800   SIG      NXT 5 5 172800 20030416130318 (
                                           [..]3CDl/htcHEhbjOf1ouTkWvIH8j4= )
ns2.afnic.idsa.prd.fr.   172800   IN A
                         172800   SIG      A 5 5 172800 20030416130318 (
                         172800   NXT      afnic.idsa.prd.fr. A SIG NXT
                         172800   SIG      NXT 5 4 172800 20030416130318 (

                             Figure 14: NXT RR example

-If the name queried exists, but the RR type does not, there are no wilcard matters, and
the appropriate NXT record will be appended to the authority section (see above).
-If the name queried does not exist, but a wildcard matches the specified RR, the
RCODE is NOERR, and then a NXT would not be needed. However, it is impor-
tant to also prove that the name queried really did not exist and that the positive answer
is really a wildcard expansion. In this case, along with the answer given, the NXT
record proving that the name does not literally exist in the zone has to be added in the
authority section.
-If the name queried does not exist and no wildcard matches, you have to prove that
there really are no wildcard covering this name. In the canonical order used for NXT
purposes, the * character comes first. For instance if there was a wildcard record in
the idsa.prd.fr covering every name starting from the 4th label level (*.idsa.prd.fr), it
would be located in the zone zone file just after idsa.prd.fr (see the canonical order
example above).
Consequently, if there is a query on bfnic.idsa.prd.fr, the server has to send two NXT
records in the authority section of its response: the NXT record of afnic.idsa.prd.fr to
prove that bfnic does not exist, as well as the NXT record of idsa.prd.fr to prove that
an appropriate wilcard RR (*.idsa.prd.fr) does not exist either.

NB: One drawback of the NXT method, which is usually criticized, is that the presence
of NXT records in the zone permits a zone walk, and then, learning the whole zone file
content becomes possible, which was not before.
The method is easy: you start from the zone apex, asking for its NXT record, thus
getting the second name present in the zone, as well as all the RRsets associated to the
zone apex. Then you ask for the NXT record of the second name and so on.

It is true that NXT records, as useful as they are, diminish confidentiality of the zone
content, but, as that was mentioned in 1.2.2, DNS is a public database and confiden-
tiality of the information should has never been a worry.
Anyway there are other ways of protecting privacy of network internal DNS informa-
tion, using views for instance.

2.4.4 The DS RR

This is a new RR which was not specified in the original DNSsec design (RFC 2535).
This RR is still under the "work in progress" status [21] at the IETF, but it is likely to
definitively become part of the protocol because it brings true enhancements especially
in the building and maintenance of the chain of trust.

The specificity of this RR is that it is located in the parent zone file, and signed by the
parent key, whereas it is part of the child zone. This specific design creates a link be-
tween zones, which is very useful to acknowledge the reliability of the authentication
of the child by the parent.
The authentication chain becomes

                              parent       child

Let us analyse this secure link between parent and child:
the zone key of the parent authenticates the DS of the child which authenticates one
KEY of the child (usually a KSK which may authenticate other keys if there are in the
child zone). Finally the RRsets of the child zone are authenticated by the zone key.

The DS is a pointer to the next key in the chain of trust. In that way, the parent does
not have to sign its children keys. This has also been designed to be compact: this is
not the key but a digest of the key (one-way hash) that is signed in the parent zone.

                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    |           Key Tag             | Algorithm     | Digest Type |
    /                                                               /
    /                            Digest                             /
    /                                                               /

                             Figure 15: DS RDATA format

-The key tag: the ID of the key which is authenticated by the DS (this is the next key
in the chain of trust)

-The algorithm: the algorithm number of the key
-The digest type: the algorithm used to produce the digest of the key (using a hash
function). For the moment, the value is 1, meaning that SHA1 is used.
-The digest: the result of the hash of the key by the algorithm. This field is currently
limited to 24 bytes.

The existence or not of a DS record in a parent zone will be sufficient to tell if the child
zone is secure or not. In the RFC 2535 model, we had to use the NULL KEY RR put
in the parent zone, to indicate that a child zone was verifiable insecure.
In DS model, the non-existence of a DS record in the parent zone, proven by the pres-
ence of the appropriate NXT RR, means that the child zone has not been secured. The
main advantage of the use of DS is that it suppress the two-way communication be-
tween parent and child that had to be done in RFC 2535 to build the secure link. Here,
a child just sends its key to its parent that will generate the DS, that is all: just a one-
way exchange.
By using DS, a parent zone delegates signing authority to its child zone.
We will talk about that in detail in section 2.5.2

                    child’s key algo
                      child’s key ID
                                                         Hash algo
afnic.idsa.prd.fr.          172800    DS      26750 5 1 (
                                              C4B9 )

                               Figure 16: DS RR example

2.5 DNSsec design
2.5.1 Zone signing/Becoming locally secured

A DNSsec zone is similar to a DNS zone. The only difference is that there are more
RRs in it: the security RRs we introduced in section 2.4.
The different steps to obtain the DNSsec zone from the DNS zone are the following:
-adding the key RRset of the zone in the apex of the zone (this RRset may be composed
of several keys, which will not necessarily sign the zone. Among these keys some of
them are used to sign the authoritative RRsets for the zone (ZSK), one may be used to
sign the KEY RRset and thus be the link in the chain of trust (KSK), and the rest of the
keys may be just stored in the zone with no interaction. These latter are usually used
for DNSsec related operations like SIG(0): they don’t sign any RRset in the zone file,
but they are signed as part of the zone’s RRs.
-increasing the SOA of the zone.
-sorting names in a canonical order, as described in 2.4.3, the apex of the zone will then
keep its first place.
-adding the NXT RRs between the names (except for the glues).
-signing all the RRsets (not the RRs) the zone is authoritative for with the private
part(s) of the ZSK(s). Note that all precautions must be taken to avoid the disclosure

of this(these) private part(s).
NB:Delegations and glues are not signed (the parent zone is not authoritative for them).
-if there is a KSK, it will be used to sign exclusively the KEY RRset. As a matter of
fact, this KSK becomes the secure entity to trust for this zone. Indeed, data of the zone
is authenticated by the ZSKs, which are authenticated by the KSK.
-reloading the zone in the name server.
So if a resolver has configured a KSK as a trusted key, it will be able to trust all the
data of the zone: KSK- ZSK- zone RRs (- means authenticates)

NB: it is possible to only use ZSKs to authenticate a zone, but in that case, the key to
be trusted by resolvers for that zone will be one or all the ZSKs.
The advantage of using KSK/ZSKs, is that a zone can change its ZSKs whenever it
wants to, whithout having to inform all resolvers of that change: the new ZSKs just
have to be signed by the KSK which will remain the trusted key for that zone. This
method will be all the more efficient, when building a chain of trust down the DNS tree
as we will see in section 2.5.3.

From now on, we will consider that all the zones we will talk about follow the KSK/ZSK
structure. If a zone has only one key, then this key will play both KSK and ZSK roles.

2.5.2 Zone transfer

For this critical part of DNS operation, an additional procedure has been imagined.
In fact, a zone transfer with the sole DNSsec is equivalent to the transfer of all the
RRsets (the signed ones, the delegations and glues). For the RRs the zone is author-
itative for, they are transferred in a secure way, because they can be checked by the
slave server, using the zone key. Moreover, the presence of NXT records gives the
slave server the ability to check if some records are missing. However, it is important
to note here that a slave server is not obliged to perform security checks through signa-
ture checking of each and every RRset, it can keep on acting like in the old DNS style
AXFR, treating security oriented RRsets (SIG, KEY, NXT, DS) just like all the other
RRsets. But should the slave decide to perform security control, and find a corrupted
RRset, it will have to reject the complete zone, not just the bad RRset.
As for the delegations and glues, it is much more problematic because they are not
signed. The delegations do have a NXT record, the glues do not. So it would be possi-
ble to modify delegations (not to erase them), and modify or erase glues in a transparent
However, such an attack would be quite difficult because the zone transfer procedure
includes exchanges of zone files versions (the SOA which is signed) between the mas-
ter and the slaves. Impersonating the master server during this exchange is then difficult
but not impossible. Though, when you talk about security, this is something that is not
The last thing that is not protected using DNSSec, is the DNS message itself: for in-
stance, a query message does not contain any RR, and is thus not protected; even in
an answer, the header section is not protected. This can also cause dangerous situa-
tions. We need here a real transaction authentication, not just a sum of RRsets integrity

This is why, a new method, based on server authentication, and full DNS message in-
tegrity check is to be used. The most common one is based on a new RR called TSIG
(Transaction Signature, described in[9] and extended in [22]) which we introduced in
section 2.2.2. Basically, it requires that the two servers which want to communicate
using it have to share (off-the-band) a secret key (symmetric cryptography) which will
be used to sign DNS messages (note that this key has nothing to do with zone keys).
TSIG is a meta-RR (we still keep the RR philosophy for compliance matters). It is
composed of the traditional RR fields (see 1.1.5), but its specificity is that it is never
stored or cached in the DNS (TTL =0, this is why we call it meta-RR), but computed
on demand when the zone transfer is required. Like all RRs, its RDATA structure is
The complete DNS message (including the header) to be sent is digested (hash), signed
with the secret key, and this signature is added in the appropriate TSIG RDATA field,
along with other fields like:
-the algorithm used (currently HMAC-MD5 is the only mandatory algorithm in use).
-the time signed: the current time when the messsage was sent (in seconds since 1970-
-the fudge: the time difference tolerated.
-errors-related fields: they may report errors about sig or keys problems; one field is
specifically used to report time-related problem (when the value of the time signed field
added to the value of the fudge is superior to the current time at the receiver). This kind
of timestamp prevents transactions from being the target of replay attacks. But this
is also means that a real synchronization must exist between a master and its slaves,
otherwise the transactions will be refused. The use of NTP servers is recommended to
ensure this synchronization.
The TSIG RR generated is then appended to the additional section of the DNS mes-
sage, and the ARCOUNT (a field of the DNS message header equal to the number of
RRs in the additional section) is incremented. The server receiving the message has to
check the additional section, looking for a TSIG record, then get it out of the message,
decrement the ARCOUNT and finally check the TSIG validity using the secret key.
The use of TSIG totally prevents attacks on zone transfer, as long as there is no com-
promission of the secret key. The TKEY RR [10] provides several methods to safely
manage exchanges related to secret key handling. These secret keys can then be used
by TSIG: there are different methods defined with TKEY to establish or delete such
secret keys, based for instance on Diffie-Hellman exchanges or on the more recent
GSS-API method described in [22].

Another way to secure these zone transfers is the use of SIG(0) [11], which is a tra-
ditional DNSsec signature (SIG RR) with a 0 type covered field and a short lifetime
(replay attacks protection). It is generated using public crypto: the private part of the
key is stored at the zone signer’s computer, the public part is stored in a KEY RR as-
sociated to the host name that uses it, with the zone key flag set to zero (see section
2.3.1). This has quite the same goal as TSIG, the difference is that it is based on public
key crypto:
-advantage: no need to share a secret (all the classical advantages)
-problem: more processing time to generate the SIG and the necessity to retrieve the
associated public KEY to do the verification.

2.5.3 Building chains of trust

The main limitation of DNSsec is that it introduces as many keys as the number of
zones (even more). If there were no links between zones, a resolver should trust at
least one key per zone it wants to get information from. This is impossible, because of
the high number of zones a resolver will come across.
It is time to explain in details what makes DNSsec not only work but especially work in
an efficient manner: the chain of trust. The idea is to create authenticated links between
zones that are already locally secured, as explained in 2.5.1. The goal is to decrease
the number of keys a resolver has to trust. Ultimately and ideally, the only key that a
resolver would have to trust would be the root key [OTDR project], and by going down
the tree, using authenticated paths, a resolver should be able to retrieve any data in an
authenticated manner, by the use of the so-called chains of trust.
We are far from that ultimate point, right now, the goal is to have some parts of the
DNS tree that are secured, each one starting from a specific point, called a secure entry
point: this is a zone whose key is trusted by the resolver.

                         "."   secure entry point

                      DS                                   No
                                  DS            DS         DS
       nl                fr               com              org      insecure
                no                 DS
        prd           com        test      secure entry point
      DS            DS                          DS
       idsa              numerobis                   sec

                     Figure 17: partly secured DNS tree using DS

Let’s have a sharp look on how this chain of trust works:
As we mentioned it before, there are two ways of building the chain of trust:
-the "old" way, following RFC 2535 specifications.
-the "new" way, in conformance to Draft-DS (currently version 13).

In the RFC 2535 way, it’s all about signatures:
-the RRsets of a zone are signed by the private part of the ZSK of the zone.
-the public part of the ZSK is signed by the private part of the KSK.
-the public part of this KSK is signed by the privto himate part of the ZSK of the parent
-the public part of the ZSK of the parent zone is signed by the private part of the KSK
of this same zone.

-the public part of the KSK is signed by the private part of the ZSK of the grang-parent
-and so on.

The main limitation that we can observe here is that a child zone needs to send its KSK
KEY record to its parent to have it signed and sent back. This two way transaction is
heavy, especially in rollover processes as we will see in section 2.5.4. That is why an
improved model using DS records has been designed, in this case, the building process
of chains of trust works as explained after (we are still in a case with KSK/ZSK): see
-the RRsets of a zone are signed by the private part of the ZSK of the zone.
-the public part of the ZSK is signed by the private part of the KSK.
-the public part of this KSK is authenticated in the parent by placing a DS record in the
parent zone.
-this DS is signed like any other RRset by the private part of the ZSK of the parent
-the public part of the ZSK of the parent zone is signed by the private part of the KSK
of this same zone.
-the public part of the KSK of the parent zone is authenticated in the grand parent zone
by the corresponding DS.
-and so on.

With the use of DS, a child zone just transfers his KSK to its parent that will generate
the appropriate DS, and sign it with its own zone keys. There is nothing more to do for
the child, even if the parent zone decides to change its zone keys.
We add several steps, in comparison to the signing model described in 2.4.1.:
-before the signing procedure begins, all the children zones which want to be authenti-
cated as verifiable secure by their parent zone must send him a keyset containing their
-the parent zone generates all the DS records corresponding to the children zones that
have sent a keyset.
-then the NXT can be inserted in the correct places in the zone file. Delegations names
in the parent zone do have a NXT record that acknowledge the presence or not of a DS
for the delegation, meaning that the zone is known secure or insecure.
-the end of the procedure is similar to the one described in 2.4.1.

Chains of trust reliability mainly depends on the way the link between child and parent
zone has been secured: If the parent zone is secured and the child zone is also secured,
extreme care must be considered to connect these two secured islands. With either DS
or RFC 2535, the child zone’s key must be transmitted to the parent (in RFC 2535, the
signed key must even come back to the child).
If there is a problem during this transmission part, the whole concept of chain of trust
falls down. That is why the child’s key transmission to the parent must be done in a
very reliable way, maybe off-the-band. This topic will be reviewed in the following

Chains of trust allow us to classify retrieved data in 3 groups[13]:
(i)data that are verifiable secure:

                                                                  Trusted key
                                                                     for fr
    fr   IN   KEY    svoLL8R1o[..]8G0w1R45cBt (52132)     KSK
         IN   KEY    ducAS/zNW[..]EUYcnG4tPQ+ (10902)     ZSK
         IN   SIG KEY ... 52132 fr ...
         IN   SIG KEY ... 10902 fr ...

    idsa.prd.fr IN DS 33202 ..uKYJ2R/xUG[..]
                IN SIG DS ... 10902 fr ...

                fr zone                                 idsa.prd.fr IN KEY     9A7eXrjW8[..]iUFz9YDSKLg (33202)   KSK
          (secure entry point)                                      IN KEY     NWEUYcnG4[..]tPQ+Sa5T71u (7203)    ZSK
                                                                      SIG KEY ... 33202 idsa.prd.fr ...
                                                                      SIG KEY ... 7203 idsa.prd.fr ...

                                                        afnic.idsa.prd.fr IN DS 21200 ...8/8/jv6Ab[..]
                                                                          IN SIG DS ... 7203 idsa.prd.fr

                                                                               idsa.prd.fr zone

    afnic.idsa.prd.fr IN KEY MrVmA8[..]kHLcmJYQh (21200)                   KSK
                      IN KEY scnduv[..]3yq+ZBs22 (43896)                   ZSK
                          IN SIG KEY ... 21200 afnic.idsa.prd.fr ..
                          IN SIG KEY ... 43896 afnic.idsa.prd.fr ..
data.afnic.idsa.prd.fr IN A
                       IN SIG A ... 43896 afnic.idsa.prd.fr ...
                    afnic.idsa.prd.fr zone

                                Figure 18: chains of trust using DS

-the RRset is in a zone that has been signed by a key the resolver trusts, and the signa-
ture checking is ok.
-the RRset is in a zone which has a valid DS in the parent zone, and we can build a
chain of trust up in the DNS tree leading to a secure entry point. Besides, the RRset is
signed and the signature is OK.

(ii)data that are verifiable insecure:

-the parent zone does not have any DS record for the child zone containing the RRset
to be verified. A NXT RR with valid signature must be present in the parent zone to
prove that the DS does not exist.
In this case, if there are signatures in the child zone, they mustn’t be taken into ac-
count. It is however possible that the resolver directly trusts the child zone key, it then
becomes a secure entry point that can be trusted on its own.
It’s important to notice that the notions of verifiable insecure and secure entry point
are resolver-dependent: on fig.17, there is no DS for test.fr in fr zone, so a resolver
configured with only the root key will consider the test.fr zone and all its descendants
as verifiable insecure even if they are signed (ex: sec.test.fr). But a resolver with the
test.fr configured as a trusted key as well will consider sec.test.fr as verifiable secure
because there is a DS leading to a secure entry point (test.fr).

(iii)data that are wrong

-the SIG does not validate the RRset (either the RRset or the SIG is corrupted).

-the SIG has expired.
-the DS in the parent zone does not acknowledge the child’s KSK.
-the chain of trust leading to a secure entry point contains a broken link or a link for
which the verification failed.

2.5.4 Key Rollover

The key rollover procedure refers to the suite of operations that has to be run to allow
a zone to change its key(s). There are implications for the zone itself, but also for the
"adjacent" zones (children and parent), and that is why this can be a very complex
operation to manage.
In fact this is the one of the main reason why the KSK/ZSK system has been adopted:
in order to decouple the operations local to a zone and the operations that involve the
secure link with the parent or the children zones .
-The ZSK just exists in the zone, it is used to sign the zone’s RRsets, and is meaning-
less outside of the zone.
-The KSK is pointed to by the DS in the parent zone, then it has an existence outside of
the zone. In this case, changing a KSK involves the zone itself, and also the parent zone.

(i)Why do we rollover keys?
The security brought by the cryptographical tools used in DNSsec depends on one
thing: the private keys must be kept secret. If anybody but the signer of the zone has
knowledge of the private key, then the key is compromised, and the zone should not be
trusted any longer. This can happen by disclosure of the key, or by private key recon-
The second method (private key reconstruction) is extremly difficult though, and de-
pends on the size of the key and the algorithm used to build the key. The longer the key,
the more difficult its reconstruction, but it is important to keep in mind that a longer
key will result in a greater processing time (signing and verifying).
This is another good point of the use of KSK/ZSK as we are going to see.

(ii)Scheduled rollover:
ZSKs are used very often for zone signing and data verifying. So they should not be
too long, because of the cost in term of processing time. Fortunately, these keys, as we
mentionned above are strictly used in the zone: changing them has no implication in
any other zones (parent or children), so rolling over ZSKs is not a problem at all, it is
just a question of resigning the zone RRsets with the new key. So ideally, we should
have short ZSKs and frequent ZSKs rollovers.
NB: like any other RRs in a zone, when coming to zone modification, one should be
careful to TTLs matters, because when you change the KEY, a certain number of caches
will keep the old KEY for a duration that could be as long as the TTL.

KSKs involve the zone (they sign KEY RRsets) and the parent zone (they are pointed
to by DS), so their rollover may be a little more tricky. As they are less used than the
ZSKs, we could consider using longer keys and then diminishing rollovers frequency.
The classical procedure is the following:
-the zone generates a new KSK.

-the zone is resigned, including the new KSK in the keyset, and signing the keyset with
the two KSKs (but this is still the old one that is part of the chain of trust.
-then the zone sends the corresponding keyset signed by both the old and the new KSK
to the parent zone.
-the parent zone, which trusts the old KSK, will as a matter of fact trust the signed
-the parent resigns its zone, updating the DS with respect to the new child’s keyset.
-the child can get rid of its old KSK, and resign its zone.
NB: the old KSK may have been configured in several resolvers as a trusted-key. Be-
fore getting rid of this old KSK, you have to be sure that all these resolvers have been
notified of the change. Unfortunately, outside of your network, you cannot know ex-
actly who has configured this KSK as a trusted-key. The best you can do is to advertise
this change as widely as possible. -the parent zone then erase the old DS.

This KSK rollover procedure can be done in total safecty, but it requires effort from the
parent zone, and child-parent synchronisation. Therefore, with the KSK/ZSK model,
we try to perform it as little as possible (using long KSK keys).
We will talk more about operational considerations in section 3 (especially TTLs mat-
NB: We can see here why the one-key model (no KSK) is really not a good idea be-
cause you have to choose between keys performances and rollover frequency.

Unscheduled rollover:
This is an emergency procedure which happens when a key has been compromised
(stolen or broken).
Once again, when it happens to a ZSK, the situation can be quickly brought back to
normal: the zone just has to change its ZSK, and resign itself. The only problem is
once again the TTLs and the fact that the compromised key may stay in recursive name
servers caches for some time. We recall here that there is no key revocation list in

When it happens to the KSK, the secure link with the parent zone is broken, so the
scheduled rollover procedure cannot be applied, because the old key is compromised.
Then various procedures, in concordance to best practice should be run (there will be
some off-the-band communication to transmit new KSK to the parent).

Once again we saw here that the model based on Draft DS, with use of KSK/ZSK is
way more performant than RFC 2535 based model (even more if there is no KSK).

2.6 Data retrieving/ New requirements for DNS components
In section 2.1, we insisted on the fact that DNSsec has been designed in full confor-
mance with the DNS original design: this security solution is totally DNS specific, all
the new objects needed to allow security fit to the RR format, and the DNS message
format itself is unchanged.
All that makes possible the backward compatibility with non DNSsec-aware compo-

nents. However, a certain number of procedures, defined in majority by the use of new
flags in the DNS message have been created to handle the new challenges inducted by
-Allow longer DNS messages than the 512 byte UDP limitation.
-Distinguish between DNSsec-aware and non-aware components (resolvers and servers)
and indicate DNSsec support.
-Normalize DNS entities’ behaviour toward signed and unsigned data.
-Handle requests, responses, signature checking location (end user, recursive server).

We saw in section 1.1.5 that DNS message size is limited by the size of the UDP packet
it is included in: 512 bytes (this was the maximum size allowed by most hosts for UDP
datagram reassembly). In DNS use prior to DNSsec, this limitation was not really a
problem as most of the DNS queries/responses seldom exceeded the authorized size. In
the case of longer messages (it is usually the case in zone transfers), the use of TCP was
allowed. In fact when a message exceeded 512 bytes, it was truncated and a specific
flag in the header was set to 1. The message could then be retransmitted, if desired,
using TCP.
Several remarks must be made here [15]:
-The use of TCP dramatically decreases performances because it is connection oriented
and thus includes connection setup and tear down (5 packets instead of 2 are exchanged
for one query/response) and connection monitoring (which can get relly heavy know-
ing that a name server may process up to thousands queries per second). The only
benefit of TCP for DNS is the increased packet size authorized.
-With DNSsec, messages average size will obviously be significantly longer, because
it includes cryptographic material (keys and sigs). The classical size of a key is 128
bytes, the 512 byte limit would consequently be frequently reached.
-The old 512 byte UDP limitation is quite obsolete as most of the hosts can reassemble
larger datagrams.

Considering this, and other facts, like the shortage of header flags and RCODES, an
OPT pseudo RR has been designed in RFC 2671 (EDNS0: extensions mechanisms for
DNS)[8]. It is a RR that is added in the additional section of a message and that gives
various information like for instance the sender’s UDP payload size that can be used
( 512 bytes), or various extra flags. It has the format of a RR (see 1.1.3), but the clas-

sical fields are replaced by other pieces of informations. It is also important to notice
that name servers and resolvers that are DNSsec-aware must implement EDNS0 with
a minimum UDP payload size of 1220 octets (4000 octets being considered as a more
comfortable value).

Another challenge that is to be faced in DNSsec early ages is the communication be-
tween DNSsec aware and non-aware entities: a resolver that is not DNSsec aware does
not need to receive security RRs (SIG, KEY, NXT, DS) when querying for information
from a secure zone. Moreover, the inclusion of such RRs where not needed may lead
to truncation of the message if it is too large and retransmission using TCP (see above)
which is an expensive price to pay for undesired and not understood RRs. The recep-
tion of such RRs by a resolver that does not understand them may even lead to resolver
To avoid all these side effects, indicating the DNSsec-awareness of the resolver in the

query seemed to be the best solution. This will be done with the DO flag (DNSsec OK)
[14] which is part of the extended set of flags located in the OPT pseudo RRs. Three
fundamental rules come along with the use of DO:
-A DNSsec-aware name server must not include DNS security RRs unless the DO bit
is set to one in the query or unless the query is specifically asking for one of these
security RRs.
-A recursive DNSsec-aware server must set the DO bit to one whatever was its value
in the query made by the resolver. But if it gets security RRs in the response by an
authoritative server, it must cache them, but remove them when responding to the end-
user resolver.
-When it is the server that does not understand the DO bit or the EDNS0 OPT RR, it
will reply with a failure RCODE (SERVFAIL, FORMERR, NOTIMPL), the resolver
should then retry its query without EDNS0. It is extremely likely that this server does
not handle DNSsec but maybe it is just a temporary unavaibility.

Two flags located in the DNS message header may be used to specify the behaviour of
DNS components toward DNSsec data:
The CD (checking disabled) bit is set to 1 by resolvers to indicate to the name server
that they want to perform security check on their own, and that the server does not have
to do it. But the server may have been configured to check all the data it comes across;
in that case the server is allowed to perform authentication of the data and discard it, if
it is wrong.
The AD (authenticated data) bit is set to 1 by servers if all the data of the response
(answer and authority sections) has been authenticated. The resolver is free to also
perform authentication on its own. One important thing to remember is that the AD bit
has absolutely no value if the resolver does not explicitly trust the server that has set
the AD bit to 1 or if the link between the resolver and the server has not been properly
secured. This is why it is sometimes proposed to use TSIG (or SIG(0)) to secure this
last link between a stub resolver and its recursive name server. In this way, the resolver
can receive DNS data that has been checked by the recursive name server (AD=1),
inside a message that is signed using TSIG. After having checked the validity of the
TSIG signature, the resolver can securely use the DNS data carried.
It is important to notice that these two flags have just been designed to help DNSsec
operations, but it is up to local security policies to set the proper behaviour DNS com-
ponents should follow when coming across these flags.

On fig.19, we describe several scenarios depending on the awareness of the DNS com-
ponents. In each case, the resolver sends a query related to a zone that is secured and
managed by the authoritative server on the left. They all have a recursive name server
(cache) that takes care of their queries.
-In case 1, the stub resolver does not handle DNSsec, its recursive server will do the
retrieving job, and signature check before forwarding to him the valid data using TSIG.
-In case 2, neither of the resolver and the recursive server are DNSSec-aware, though
they can still communicate with this secure zone just as if it was a non-signed zone.
-In case 3, the resolver is more ’intelligent’ and want to do the verification on its own.
-We have already introduced (see above) the case when it is the server that is not
DNSsec-aware, whereas the resolver is: in that case the server will answer with an
error code to a request with the DO bit. The resolver will then try a query without
EDNS0, and choose to trust or not the response (depending on the local policy).

                                           Cache server
                                           DNSsec aware
                           EDNS0+DO=1, CD=1            No EDNS0, TSIG           Stub resolver
                           EDNS0+DO=1, CD=1
                                                                               not DNSsec aware
                                                     No EDNS0,AD=1,TSIG
                           (sec RRs included)           (no sec RRs)

                                       Cache server
                                     not DNSsec aware
                                No EDNS0               No EDNS0, NO TSIG
        Authoritative                                                            Stub resolver
        server for a                                                           not DNSsec aware
        secured zone           No EDNS0               No EDNS0, NO TSIG
                               (no sec RRs)           (no sec RRs)

                                           Cache server
                                           DNSsec aware
                            EDNS0+DO=1, CD=1       EDNS0+DO=1, CD=1, No TSIG
                                                                                 DNSsec aware
                          EDNS0+DO=1, CD=1         EDNS0+DO=1, CD=1, No TSIG       resolver
                          (sec RRs included)            (sec RRs included)

                             Figure 19: DNSsec scenarios

3 Operational aspects
In this section of the document, we will enter the specific operational considerations
that arise from the use of DNSsec. This is an application part of section 2, meaning
that a good knowledge of DNSsec theorical aspects is required.
-Subsection 3.1 covers new operational challenges induced by DNSsec [7], as well as
tools and servers configuration required.
-Subsections 3.2 and 3.3 are built in a HowTo way, explaining step by step the differ-
ent stages for securing a zone, including it in a chain of trust, and various operational
features (another document of the same kind is[27]). We will use in these sections the
example of a simplified idsa.prd.fr zone.
-Susection 3.4 introduces different useful tools that may facilitate implementation and

3.1 DNSsec: New operational challenges
As told in section 1.3.2, DNSsec deployment has to be considered once your DNS
infrastrusture (network, nameservers) meet an appropriate and intrinsic non-DNS spe-
cific level of security as described in best practice articles (see[28] or [29]). Indeed
DNSsec provides full security over DNS exchanges, but cannot do anything regard-
ing nameserver misconfiguration or security holes. For instance, if some unauthorized
people have access to your authoritative nameserver, and do some harm on your DNS
data, DNSsec will just authenticate and protect the integrity of these already-corrupted
So please be aware that the most important thing remains the security of your name-
servers, because DNSsec takes for granted the fact that data stored in authoritative

name servers is to be trusted. DNSsec role comes just afterward, providing a secure
way to guarantee that data reaching the end user is the same as data stored on the au-
thoritative name servers.

DNSsec obviously implies new operational stakes in comparison to DNS:


       The use of cryptographic keys requires special care, because DNSsec is based on
       these fundamental objects, and the security offered by DNSsec requires that they
       must not be compromised. This means that nobody except the signer may have
       knowledge of the private part of the key pair: if a private key is disclosed, you
       can forget about DNSsec efficiency. Thus, we have to prevent two things from
       -the key must not be stolen, meaning that it has to be stored in a safe place.
       -the key must not be broken by crypto-analysis, meaning that its size and its life-
       time use (rollover frequency) must be carefully set.
       See sections 2.4.4 and 3.2 for more information about that.
       Of course, one of these two unfortunate events may happen, so we have to react
       in the most appropriate way to limit the consequent harm. See section 2.4.4 and
       3.3 for more details on that point.


       For the zone administrator’s point of view, using DNSsec requires a little more
       management and organisation than handling simple DNS. But nearly everything
       can be automated (except for emergency rollovers that may happen anytime). It
       is a question of local policy regarding all the typical operations brought by the
       use of DNSsec.
       DNS maintenance mainly consisted in updating your zone file content when
       needed, with special care regarding TTLs matters. In DNSsec, you will have
       to also manage regular zone (re)signing, key (re)generation, possible emergency
       rollovers; all of these operations having to be done in tight cooperation with your
       close relatives in the DNS tree (parent and children zones).
       Therefore you will need:
       -good organisation on your server.
       -efficient automated procedures.
       -full cooperation and synchronisation with your parent and children zones.


       Finally, several points about software and hardware:
       -Cryptographic signatures imply processing time when they are generated: this
       means that signing huge zones may take some time depending on the size of the
       keys. Latest processors are fast enough to handle the signing procedure of such
       zones in a reasonable amount of time, however, this obviously will not be the
       case with older processors.
       -Zone files, because of cryptographic material and new RRs become significantly
       bigger once they are signed (4 to 8 times larger). Once again, for huge zones,
       it is important to have enough RAM to handle the loaded zone files when the
       server is up.
       -The following sections will assume that you are running a BIND name server
       software [29] because this is by far the most widely used. As we said in section

      2, DNSsec protocol is still evolving: even though the use of DS is still under
      draft status at the IETF, we will assume that it is likely to become the DNSsec
      standard in place of RFC 2535. Therefore, all the operations described below are
      based on the use of DS. BIND implements DS in its 9.3 snapshots (starting with
      9.3.0s20020722, latest snapshot currently being 9.3.0s20021217). You should
      have BIND 9.3.0s20021217 installed to implement DNSsec in full concordance
      with what follows.
      (Slight differences might be observed when using previous snapshots).
      You can find the latest BIND snapshots here: ftp://ftp.bind.com/pub/bind9/snapshots.

3.2 How to sign a zone
Converting a traditionnal DNS zone into a secured one can be done using the tools
provided by BIND software.
BIND software comes with two DNSsec tools covering the two main steps of the sign-
ing procedure:
-dnssec-keygen is used to generate key pairs.
-dnssec-signzone is used to sign the zone.
Let us have a closer look at these tools and their options: we will illustrate the different
procedures by using these tools on a simplified version of the idsa.prd.fr zone file.

$ORIGIN idsa.prd.fr.
$TTL     172800 ; 2 days
@                       IN SOA                ns1.afnic.idsa.prd.fr. hostmaster.nic.fr. (
                                                      2002121004      ; serial
                                                      6H              ; refresh
                                                      1H              ; retry
                                                      3600000         ; expiry
                                                      1D )            ; minimum

                                  IN          NS         ns1.afnic.idsa.prd.fr.
                                  IN          NS         ns2.afnic.idsa.prd.fr.
                                  IN          NS         ns2.irisa.idsa.prd.fr.

afnic                             IN          NS         ns1.afnic
                                  IN          NS         ns2.afnic
ns1.afnic                         IN          A
                                  IN          AAAA       2001:660:3003:1d5a::1:1
ns2.afnic                         IN          A
                                  IN          AAAA       2001:660:3003:1d5a::1:2

irisa                             IN          NS         ns1.irisa
                                  IN          NS         ns2.irisa
ns1.irisa                         IN          A
                                  IN          AAAA       2001:688:1f98:1d5a:2c0:4fff:fece:e8f2
ns2.irisa                         IN          A
                                  IN          AAAA       2001:688:1f98:1d5a:2c0:4fff:fea9:816d

www.idsa.prd.fr.                  IN          CNAME      idsa.irisa.fr.
ftp.idsa.prd.fr.                  IN          CNAME      ftp.irisa.fr.

3.2.1 Generating Keys

dnssec-keygen command comes with a number of options which are disclosed by
the help screen:

# dnssec-keygen -h
    dnssec-keygen -a alg -b bits -n type [options] name

Required options:
    -a algorithm: RSA | RSAMD5 | DH | DSA | RSASHA1 | HMAC-MD5
    -b key size, in bits:
        RSAMD5:         [512..4096]
        RSASHA1:        [512..4096]
        DH:             [128..4096]
        DSA:            [512..1024] and divisible by 64
        HMAC-MD5:       [1..512]
    -n nametype: ZONE | HOST | ENTITY | USER
    name: owner of the key
Other options:
    -c <class> (default: IN)
    -e use large exponent (RSAMD5/RSASHA1 only)
    -g <generator> use specified generator (DH only)
    -p <protocol>: default: 3 [dnssec]
    -s <strength> strength value this key signs DNS records with (default: 0)
    -r <randomdev>: a file containing random data
    -v <verbose level>
     K<name>+<alg>+<id>.key, K<name>+<alg>+<id>.private

The -a option is followed by the algorithm of the key: it is currently strongly recom-
mended to use the RSASHA1 algorithm (this is the only algorithm that is mandatory
in DNSSec).

The -b option is followed by the size of the key in bits. It is a question of tradeoff:
choosing a long size for a key will make it strong against compromission: it will be
harder to break it.
choosing a short size for a key will decrease the processing time necessary to generate
the signatures of each and every RRset of a zone (which can take much time for large
zones like the TLDs’ zones) and also speed up the signatures checking performed by
the users when they validate queried data.
It is a discussion that we have had in section 2.5.4.: we encourage once again the use
of (at least) two key pairs (KSK and ZSK). The ZSK is frequently used in signing and
data integrity checking procedures, so we will use a shorter lenght associated with a
frequent rollover. On the other hand, we will use a longer size for the KSK to increase
its strenght against crypto attacks, because we want to roll it over as little as possible.
We currentleasingy recommend a lenght of 1024 for the ZSKs (512 bit keys can be
broken quite fast), and a lenght of 2048 for the KSKs.

The -n option acts on the KEY zone flag (see section 2.4.1): here we want to generate
a zone key, so we will use "-n ZONE". For instance, for TSIG keys, you have to use
"-n HOST".

The name required option must be the name of the zone that will use the keys.

Usually we do not use the other options, except maybe "-r" to increase the entropy
("randomness") of the random generator used for key generation, which is sometimes
necessary on certain kind of OS (example: FreeBSD).

Now we want to generate the keys for the idsa.prd.fr zone:

# dnssec-keygen -a RSASHA1 -b 1024                      -r /dev/urandom -n ZONE idsa.prd.fr

this will return:

Kidsa.prd.fr+005+15230.key (the public part)
Kidsa.prd.fr+005+15230.private (the private part)

(The generic name of a key generated by dnssec-keygen is K zonename + algo + keytag .key


and K zonename + algo + keytag .private)


The public part of the key is automatically formatted in a RR style (see section 2.4.1)
which will be very useful when we will include it in the zone file:

# cat Kidsa.prd.fr+005+15230.key
idsa.prd.fr. IN KEY 256 3 5 AQPGxDZ1dLI5[...]vmDJfVfpgVRY3PqP7bsfmGE6 akNGqw==

Now we generate the KSK:

# dnssec-keygen -a RSASHA1 -b 2048                      -r /dev/urandom -n ZONE idsa.prd.fr

it returns once again:


Now that we have our keys, key files permissions must be treated with special care:
the public parts can be read by everyone, but obviously must not be modified, so a 444
mode seems to be the most appropriate.
As for the private parts, they must be kept secret, and the zone administrator is the only
one who has to be able to read it (in order to sign the RRs), so we will use a 400 mode.

Finally, these keys must be stored in a safe directory of your computer (especially be-
cause of the private part).
Ideally, the keys and the signing operations that we will describe in the following sec-
tion should be located on a dedicated machine that would not be connected to the
network, and that would just provide the signed zone to the master when needed.

3.2.2 Signing the zone

For this procedure (described in section 2.5.1), we use the BIND tool dnssec-signzone.
Before using this tool, we have to add the KEY RRset to the unsigned zone. We recall
here that a signed zone must have at least one KEY RR at the apex of the zone.
In our example, we append the two keys’ public parts to the apex of the zone (idsa.prd.fr.).
It is quite easy, because as we said earlier, the public keys we generated are already RR
Two methods are possible:

# cat Kidsa.prd.fr+005+54272.key >>idsa.prd.fr
# cat Kidsa.prd.fr+005+15230.key >>idsa.prd.fr

(idsa.prd.fr is the name of the idsa.prd.fr zone file)

or it is possible to use the $include command inside the zone file:
we add these two lines at the end of the idsa.prd.fr zone file.

$include Kidsa.prd.fr+005+54272.key
$include Kidsa.prd.fr+005+15230.key

Then we have to increase the serial number of the SOA of the zone (like after any zone
file update). It is very important, otherwise the modification of the zone will not be
notified to the slave name servers of the zone.

Now it is time to sign the zone using the dnssec-signzone tool:
At least, we have to be in a directory where there is the zone to sign; along with the
private parts of the keys we want to use.
Let us have a look at the different options of this command.

# dnssec-signzone -h
        dnssec-signzone [options] zonefile [keys]

Options: (default value in parenthesis)
        -c class (IN)
        -d directory
                directory to find keyset files (.)
        -s YYYYMMDDHHMMSS|+offset:
                SIG start time - absolute|offset (now)
        -e YYYYMMDDHHMMSS|+offset|"now"+offset]:
                SIG end time - absolute|from start|from now (now + 30 days)
        -i interval:
                cycle interval - resign if < interval from end ( (end-start)/4 )
        -v debuglevel (0)
        -o origin:
                zone origin (name of zonefile)
        -f outfile:
                file the signed zone is written in (zonefile + .signed)
        -r randomdev:
                a file containing random data
        -a:     verify generated signatures
        -p:     use pseudorandom data (faster but less secure)
        -t:     print statistics
        -n ncpus (number of cpus present)
        -k key_signing_key

Signing Keys: (default: all zone keys that have private keys)
        keyfile (Kname+alg+tag)

The validity of the signatures generated by this command are specified by -s and -e
options (signature inception and expiration, see section 2.4.2).
Usually the signature validity begins at once (it is the default value for -s).
The -e option is usually followed by a date of expiration in the format specified above
or by an offset in seconds preceded by the "plus" sign. (the default value is 30 days).

The -o option selects the name of the zone file (which can be different of the name of
the zone).
The -f option selects the name of the signed file output (usually we use the default
value zonefile .signed).


The -a option is used to perform a validity check of the signatures generated: it may
take time to use this option for large zones, but it offers the guarantee that the signed
zone you are going to put online is correct.

The -k option is followed by the name of the KSK: it is used to distinguish the KSK
among all our zone keys. With the current implementation of dnssec-signzone, it is not
possible to use more than one KSK at the same time.

We will talk about the -d option when considering delegations to secure zones (sec-
tion 3.3). Right now we are just providing a local security level, thus this option is not

Then we launch the following command to sign the idsa.prd.fr zone:

# dnssec-signzone -r /dev/urandom
-o idsa.prd.fr
-f idsa.prd.fr.signed
-e +1296000
-k Kidsa.prd.fr+005+54272.private
idsa.prd.fr Kidsa.prd.fr+005+15230.private

This will return: idsa.prd.fr.signed.
This is the name of the signed version of the idsa.prd.fr zone (we reproduce hereafter
the idsa.prd.fr.signed file, with cuts in SIGs and KEYs base64 material for
enhanced readability). The signatures present in the zone are valid for 1296000 sec (15
days), starting from the signing time. At this point, we suppose that the two children of
the zone (afnic.idsa.prd.fr and irisa.idsa.prd.fr) are not signed (no DS in the idsa.prd.fr

 ; File written on Wed Apr 23 17:28:05 2003
; dnssec_signzone version 9.3.0s20021217
idsa.prd.fr.            172800 IN SOA ns1.afnic.idsa.prd.fr. hostmaster.nic.fr. (
                                        2003042302 ; serial
                                        21600      ; refresh (6 hours)
                                        3600       ; retry (1 hour)
                                        3600000    ; expire (5 weeks 6 days 16 hours)
                                        86400      ; minimum (1 day)
                        172800 SIG      SOA 5 3 172800 20030508152805 (
                                        20030423152805 15230 idsa.prd.fr.[...]
                        172800 NS       ns1.afnic.idsa.prd.fr.
                        172800 NS       ns2.afnic.idsa.prd.fr.
                        172800 NS       ns2.irisa.idsa.prd.fr.
                        172800 SIG      NS 5 3 172800 20030508152805 (
                                        20030423152805 15230 idsa.prd.fr.[...]
                        172800 KEY      256 3 5 [...] ; key id = 54272
                        172800 KEY      256 3 5 [...] ; key id = 15230
                        172800 SIG      KEY 5 3 172800 20030508152805 (
                                        20030423152805 15230 idsa.prd.fr.[...]
                        172800 SIG      KEY 5 3 172800 20030508152805 (
                                        20030423152805 54272 idsa.prd.fr.[...]
                        172800 NXT      afnic.idsa.prd.fr. NS SOA SIG KEY NXT
                        172800 SIG      NXT 5 3 172800 20030508152805 (
                                        20030423152805 15230 idsa.prd.fr.[...]

afnic.idsa.prd.fr.           172800    IN NS     ns1.afnic.idsa.prd.fr.
                             172800    IN NS     ns2.afnic.idsa.prd.fr.
                             172800    NXT       ftp.idsa.prd.fr. NS SIG NXT
                             172800    SIG       NXT 5 4 172800 20030508152805 (
                                                 20030423152805 15230 idsa.prd.fr.[...]

ns1.afnic.idsa.prd.fr.       172800    IN A
                             172800    AAAA      2001:660:3003:1d5a::1:1
ns2.afnic.idsa.prd.fr.       172800    IN A
                             172800    AAAA      2001:660:3003:1d5a::1:2

ftp.idsa.prd.fr.             172800    IN CNAME ftp.irisa.fr.
                             172800    SIG     CNAME 5 4 172800 20030508152805 (
                                               20030423152805 15230 idsa.prd.fr.[...]
                             172800    NXT     irisa.idsa.prd.fr. CNAME SIG NXT
                             172800    SIG     NXT 5 4 172800 20030508152805 (
                                               20030423152805 15230 idsa.prd.fr.[...]

irisa.idsa.prd.fr.           172800    IN NS     ns1.irisa.idsa.prd.fr.
                             172800    IN NS     ns2.irisa.idsa.prd.fr.
                             172800    NXT       www.idsa.prd.fr. NS SIG NXT
                             172800    SIG       NXT 5 4 172800 20030508152805 (
                                                 20030423152805 15230 idsa.prd.fr.[...]

ns1.irisa.idsa.prd.fr.       172800    IN A
                             172800    AAAA      2001:688:1f98:1d5a:2c0:4fff:fece:e8f2
ns2.irisa.idsa.prd.fr.       172800    IN A
                             172800    AAAA      2001:688:1f98:1d5a:2c0:4fff:fea9:816d

www.idsa.prd.fr.             172800 IN CNAME idsa.irisa.fr.
                             172800 48      CNAME 5 4 172800 20030508152805 (
                                            20030423152805 15230 idsa.prd.fr.[...]
                             172800 NXT     idsa.prd.fr. CNAME SIG NXT
                             172800 SIG     NXT 5 4 172800 20030508152805 (
                                            20030423152805 15230 idsa.prd.fr.[...]

dnssec-signzone has performed all the remaining operations described in section
-sorting the zone in canonical order.
-inserting the NXT RRs in the appropriate spaces.
-signing the KEY RRset with the KSK specified with the -k option.
-signing all the RRset, including the KEY RRset with the ZSKs.

The last step is to load the signed zone idsa.prd.fr.signed in the BIND server

Signing a zone must be performed on a regular basis: the signatures generated have a
period of validity outside of which the RRs associated are considered as not reliable.
It is obvious that the validity chosen has to be greater than the resigning intervall. But
it should even be greater than the resigning intervall added to the greatest TTL of the
zone (see the end of section 2.4.2).
As far as you respect this condition, the resigning intervall and the validity depend on
the frequency of changes occuring in your zone, and the reactivity you want to have
toward these changes. For instance, if you sign your zone everyday, and the greatest
TTL of your zone is 2 days, you should set the validity of your SIGs to 3 days at least.

3.3 Building the chain of trust
As we discussed it troughout section 2, and especially in section 2.5.3, DNSsec has to
take advantage of the hierarchical structure of the DNS: the local security described in
the previous section is only a first step: A zone that is locally secure will take benefit
of DNSsec only if the resolvers configure the KSK of the zone as a trusted key (secure
entry point). This can be done at a small scale, for instance on the same network, but
for a global level of security, we have to build chains of trust down the DNS tree, with
secure entry points as high in the tree as possible. This is what will be explained in this

Let us consider the idsa.prd.fr zone that we previously signed.
If we want to insert it in a chain of trust, we have to have a DS generated by our parent
zone, pointing to our KSK, as well as we have to generate DS RRs for all the delega-
tions to our signed children.
This is done quite easily with the dnssec-signzone tool: in fact, to generate a DS for a
child zone, the parent zone has to get the keyset of the child zone. A keyset contains a
certain number of KEYs RRs corresponding to the child keys that will be authenticated
by the parent (if the child zone is using KSKs, it(they) will be the key(s) contained in
the keyset) . Then the parent puts all its children’s keysets in a specific directory, and
launches the dnssec-signzone with the option -d pointing to this directory.
Moreover, when signing a zone, dnssec-signzone will generate the appropriate
keyset for the current zone. A keyset generated by dnssec-signzone will have the
following generic name: keyset- zone (with the final dot at the end of the zone



In conclusion, the steps to be done are the following:
-We wait for our children zones to sign themselves (for instance afnic.idsa.prd.fr). They

will use the procedure described in the previous section. Then they will have their key-
set automatically generated by dnssec-signzone, containing their KSK.
-We get these keysets and put them in a specific directory.
-We launch the dnssec-signzone command (dnssec/keyset is the keyset direc-

# dnssec-signzone -r /dev/urandom
-o idsa.prd.fr
-f idsa.prd.fr.signed
-d dnssec/keysets
-k Kidsa.prd.fr+005+54272.private
idsa.prd.fr Kidsa.prd.fr+005+15230.private

-Along with the operations performed in the previous section, dnssec-keygen will cre-
ate DS RRs for each delegation that corresponds to a keyset located in the dnssec/keysets
-dnssec-signzone will generate a keyset for idsa.prd.fr (keyset-idsa.prd.fr.) and will put
it in the same keyset directory:
-we can transmit the keyset of idsa.prd.fr to our parent zone: fr.

afnic.idsa.prd.fr.                   172800      IN NS        ns1.afnic.idsa.prd.fr.
                                     172800      IN NS        ns2.afnic.idsa.prd.fr.
                                     172800      NXT          ftp.idsa.prd.fr. NS SIG NXT DS
                                     172800      SIG          NXT 5 4 172800 20030508152805 (
                                                              20030423152805 15230 idsa.prd.fr.
                                     172800      DS           26750 5 1 (
                                                              C4B9 )
                                     172800      SIG          DS 5 4 172800 20030508152805 (
                                                              20030423152805 15230 idsa.prd.fr.

We recall here that the presence of a signed DS record for a specific delegation in a
parent zone proves that a child is supposed to be known-secure, in opposition to the
known-insecure status if there is no DS. That is why a parent must not take into ac-
count a child keyset if the child has not signed its zone yet.

3.4 Rollovers and associated procedures
We are going here to describe some operational procedures to handle keys rollover. A
good knowledge of theorical aspects on that topic (section 2.5.4) as well as operational
aspects described in sections 3.2 and 3.3 is required to go through this part.

3.4.1 ZSKs

As mentionned in 2.5.4, the first case to consider is the ZSK rollover which does not
require a very complicated procedure. Basically you just have to generate a new key
following section 3.2.1 explanation, and resign your zone with this new ZSK following
section 3.2.2 explanation. That is all, even though your zone is part of a delegation
chain, because the ZSK has no impact on your parent or children zones.
However, we have to recall here that DNSsec must not make you forget about your
good DNS habits: changing or adding key(s) to your zone is exactly the same opera-
tion as an update on a DNS zone file RR: you must consider TTLs matters, and the fact
that caches may keep the old KEY RRset for as long as its TTL value. Consequently,
the new KEY must be added to the KEY RRset at least ’TTL value’ before using it to
sign the zone.
For instance if you sign your zone everyday, and the TTL value is equal to 2 days, we
saw before that the SIG validity must be at least 3 days. If you want to rollover your
ZSK every week, then you will have to act as follows:
From day 1 to day 5, you sign with ZSK1. Just before signing on day 6, you add ZSK2
to your KEY RRset. On day 6 and 7, you sign with ZSK1. Just before signing on day
8, you can remove ZSK1 from your KEY RRset. On day 8, you sign with ZSK2. And
so on. Some caches might still have both ZSKs in their cache until day 10, but it is not
a problem as long as they have the new one at least.

3.4.2 KSKs

We now consider the rollover of a KSK.
We have described the different steps of this procedure in section 2.5.4. It is important
to notice that there are definitely several ways to manage the rollover of a KSK. The
one we will describe here take into account the operational constraints induced by the
use of BIND in its current release.
Several remarks we make here:
-Rolling over a KSK involves both the zone and its parent zone.
-It is way more difficult than the rolling over of a ZSK, because the required synergy
between the zone and its parent is based on the parameters of both zones (TTLs, SIGs
validity, resigning interval) and their interactions.
-We must never break the chain of trust during the whole procedure.
-The old KSK may be configured as a trusted key in many resolvers without you being
aware of it. They should somehow be warned of this change.
-In its current release, BIND does not allow a zone to use several KSKs at the same
time (the "-k" option is followed by only one key). We will have to act accordingly.

KSK rollover step by step: -The first step is to include the new KSK in the KEY RRset
of the zone, and resign the zone (still using the old keys). The stakes are exactly the
same as in the ZSK rollover: after you resign your zone, some caches may still have
your old KEY RRset for a maximum of the TTL duration. So this first step must be
done at least ’KEY RRset TTL value’ before you use the new KSK for signing issues.
-Then you have to send your keyset composed of the old and the new KSK to your
parent zone in a safe manner. This can be done off-the-band, or more simply, you can
sign the keyset with the old KSK: the parent zone can thus check the validity of the

keyset by normal DNSsec operation (as long as the old KSK is still valid, and still part
of the chain of trust, which is normally the case in a scheduled rollover).
-Next time your parent zone will sign its zone, it will include two DS corresponding to
your zone (1 DS RRset). One of these DS is pointing to your old KSK (which is still
the current link in the chain of trust), and the other is pointing to the future KSK which
is not part of the chain of trust yet.
-Once again, for TTL matters, we must wait for a ’parent zone DS TTL duration’ be-
fore we use the new KSK in our zone. Indeed, during this DS TTL, some caches may
still only have the DS of the old KSK, it would consequently be a bad idea to use the
new KSK before (we recall here that we base our scenario on the possibilities offered
by BIND: we can only use one KSK at a time).
-After the appropriate amount of time, with respect to the previous step, we can use the
new KSK in our zone to sign the keyset, and get rid of the old one. We are not breaking
the chain of trust, because the DS covering this new KSK already exists in the parent
-The last step is to be done by the parent zone which has to resign its zone including
only the DS corresponding to the new KSK.
-At some point, you must communicate on your future new KSK, so that the resolvers
that have had it configured take their dispositions to change it on time. Remember that
you do not necessarily know all these resolvers. The higher the zone is located in the
DNS tree, the more resolvers might have your KSK configured as a trusted key.

We see that in order to perform these operations properly, a zone and its parent must
have a good knowledge of at least each other TTLs and resigning moments.
Automation of this whole procedure can be done, and will highly depend on all these
parameters: the zone and its parent must agree beforehand on the schedule of the dif-
fernt steps.
The way a zone transmits its keyset to its parent, and the way the zone will annouce its
new KSK are to be defined by local policies.

3.4.3 emergency rollovers

The tricky question of emergency rollovers must be approached here, but there really
are no miracle solutions. They happen when a key has been compromised and you
have noticed it, which often means that bad things have already happened.

In such cases, a rollover must be considered in emergency, and it seems that all the
caution regarding TTL and other things should be forgotten:


        for the ZSKs, we change the key and resign at once. Some problems may occur
        for a TTL duration (the time the new key needs to propagate in the caches). Be
        aware that your children zones may be affected too, because their DS are signed
        by your ZSK.


        for the KSKs, the main idea is to be prepared in advance to such situation: there
        are no outstanding solutions, but at least you can limitate damages. You must

      have set a policy on the following topics:
      -How to transmit your new KSK to your parent zone (you cannot rely any longer
      on the old one). This will be similar to the initial key transmission you had with
      your parent, and it will surely be an off-the-band solution.
      -How to warn resolvers that have your KSK configured as a trusted key.
      -How to find the appropriate balance in your severity of action: if you change
      your key immediately, you will not be vulnerable to attacks, but verification over
      your zone information (and your children’s) will fail for some time: all the ser-
      vices you provide may not be available (using DNS) by some people depending
      on their cache behaviour and local policies toward "bad" data. On the other
      hand, if you follow a procedure similar to the scheduled rollover in this case,
      you will be vulnerable to attacks for the duration of the procedure.
      Several levels of dangers associated to appropriate behaviours may be consid-
      ered here.
      -How to avoid this from happening again: safety of the key, frequency of sched-
      uled rollovers are topics you will not under estimate any longer.

3.5 Useful tools
3.5.1 The dig tool

dig (domain information groper): the classical and useful tool. It is chipped in with
BIND software, be sure to have the latest version. You should check the man page of
dig for more details on how to use it. Basically, a dig works as follow:
dig @server Qname Qtype [options...]. Among the interesting options,
+dnssec sets EDNS0, +cdflag corresponds to the CD flag which is very useful to
bypass a verification failure.
There is just after a screenshot of a use of the dig command: we queried a cache server
configured with the trusted key of fr (this is a local verifier as we describe one in the
next section), and we indicated DNSsec support (+dnssec). The result of the dig
command decomposes the DNS packet, facilitating the analysis of the results:
-we see the header with the OPCODE, the RCODE (here, NOERR), the DNS query
ID, the flags (here the AD flag is on, meaning that the cache has validated the data:
SIGs and chain of trust), the COUNTS of the different sections (see section 1.1.5).
-then there is the OPT pseudo RR (section 2.6), indicating DNS support by the way of
the DO flag, as well as larger UDP packet support (4096 octets).
-right after we have the four sections of the message: question, answer, authority and

#dig @nscache.afnic.idsa.prd.fr ns1.afnic.idsa.prd.fr aaaa +dnssec

; <<>> DiG 9.3.0s20021217 <<>> @nscache.afnic.idsa.prd.fr ns1.afnic.idsa.prd.fr aaaa +dnsse
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47560
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 9

; EDNS: version: 0, flags: do; udp: 4096
;ns1.afnic.idsa.prd.fr.         IN      AAAA

ns1.afnic.idsa.prd.fr.           172582     IN    AAAA       2001:660:3003:1d5a::1:1
ns1.afnic.idsa.prd.fr.           172582     IN    SIG        AAAA 5 5 172800 20030525021728 20030510021728
                                                             16169 afnic.idsa.prd.fr. [...]

afnic.idsa.prd.fr.               172582     IN    NS         ns1.afnic.idsa.prd.fr.
afnic.idsa.prd.fr.               172582     IN    NS         ns2.enst.idsa.prd.fr.
afnic.idsa.prd.fr.               172582     IN    NS         ns2.afnic.idsa.prd.fr.
afnic.idsa.prd.fr.               172582     IN    SIG        NS 5 4 172800 20030525021728 20030510021728
                                                             16169 afnic.idsa.prd.fr. [...]

ns2.enst.idsa.prd.fr.            258982     IN    A
ns2.enst.idsa.prd.fr.            258982     IN    AAAA       2001:660:282:1:206:5bff:fe3b:bc1f
ns2.enst.idsa.prd.fr.            258982     IN    SIG        A 5 5 259200 20030518075348 20030418075348
                                                             45164 enst.idsa.prd.fr. [...]
ns2.enst.idsa.prd.fr.            258982     IN    SIG        AAAA 5 5 259200 20030518075348 20030418075348
                                                             45164 enst.idsa.prd.fr. [...]

afnic.idsa.prd.fr.               172582     IN    KEY        256 3    5 [...]
afnic.idsa.prd.fr.               172582     IN    KEY        256 3    5 [...]
afnic.idsa.prd.fr.               172582     IN    SIG        KEY 5    4 172800 20030525021728 20030510021728
                                                             16169    afnic.idsa.prd.fr.[...]

afnic.idsa.prd.fr.               172582     IN    SIG        KEY 5 4 172800 20030525021728 20030510021728
                                                             26750 afnic.idsa.prd.fr. [...]

;;   Query time: 56 msec
;;   SERVER: 2001:660:3003:1d5a::1:4#53(nscache.afnic.idsa.prd.fr)
;;   WHEN: Tue May 13 15:33:10 2003
;;   MSG SIZE rcvd: 1785

3.5.2 Configuring a local verifier

It can be very useful to setup a recursive name server in order to test and troubleshoot
your signed zone (and other signed zones). With BIND, you will just need an IP ad-
dress for this recursive server to bind on (you can configure this new server on the
same machine your authoritative name server is located, as long as you have available
IP addresses).

Two features are really interesting:
-you can set trusted keys, for the zone you want to be your secure entry points (you
should at least put there the KSK of your highest signed ancestor in the DNS tree).
-you can log the DNSsec activity on this recursive server using the specific channel
dedicated to DNSsec operations (you should be familiar with BIND logging [29]).
With a severity debug greater than 3, you will be able to analyze the verification chain
from your secure entry point down to the queried data, allowing you to detect where a
verification failure happened.
We recommand to use dig to question this recursive server, it will help a lot in trou-
bleshooting times.
We give hereafter an example of a minimal named.conf file for this local verifier
(including DNSsec logging, as well as use of trusted keys):

logging {
channel dnssec_file {
                file "/yourlogpath/dnssec" versions 3 size 1m;
                severity debug 3;
                print-category yes;
                print-severity yes;
                print-time yes;
category dnssec { dnssec_file; };

include "/yourpath/trusted-keys";

options {
recursion yes;
listen-on { IPv4address;};
listen-on-v6 { IPv6address;};

zone "." {
        type hint;
        file "/yourpath/named.root";

the trusted-keys file must look like:

trusted-keys {
fr. 256 3 5
nl. 256 3 3

3.5.3 DNSsec toolkit

It is a set of primitive C functions which allow you to build any kind of DNSsec tool
or resolver. For instance a sigchase option can be added to dig to check the valid-
ity of DNS data throughout a chain of trust starting from a secure entry point. This
tool was written by Olivier Courtay from the IDsA project. It is freely available at

3.5.4 DNSsec resolver (resolv.pl)

It is a DNSsec aware resolver that does the DNSsec signatures checking and enhance
the possible options in the /etc/resolv.conf file (trusted keys configuration, DNSsec full
or simple mode). This tool was written by Olivier Peningault from the IDsA project,
and is based on a DNSsec resolver written by Miek Gieben from nlnetlabs [35]. It is
freely available at ftp://ftp.irisa.fr/local/idsa/code/verification-tool.

4 References and Copyright

     RFCs and Drafts
 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034,
     November 1987.
 [2] Mockapetris, P., "Domain names - implementation and specification", STD 13,
     RFC 1035, November 1987.
 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP
     14, RFC 2119, March 1997.
 [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July
 [5] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March
 [6] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name
     System (DNS)", RFC 2538, March 1999.
 [7] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March
 [8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
 [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Trans-
     action Authentication for DNS (TSIG)", RFC 2845, May 2000.
[10] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930,
     September 2000.
[11] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931,
     September 2000.
[12] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC
     3007, November 2000.
[13] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090,
     March 2001.
[14] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December
[15] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size
     requirements", RFC 3226, December 2001.
[16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record
     (RR)", RFC 3445, December 2002.
[17] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext-dnssec-
     roadmap-06 (work in progress), November 2001.

[18] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System",
     draft-ietf-dnsext-dns-threats-02 (work in progress), November 2002.
[19] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNS Secu-
     rity Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-05 (work in
     progress), February 2003.
[20] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Resource Records
     for DNS Security Extensions", draft-ietf-dnsext-dnssec-records-04 (work in
     progress), February 2003.
[21] Gudmundsson, O., "Delegation Signer Resource Record", draft-ietf-dnsext-
     delegation-signer-13 (work in progress), December 2002.
[22] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., R. Hall, "GSS Algorithm
     for TSIG (GSS-TSIG)", draft-ietf-dnsext-gss-tsig-06.txt (work in progress),
     February 2003
[23] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Protocol Modi-
     fications for the DNS Security Extensions", draft-ietf-dnsext-dnssec-protocol-00
     (work in progress), Februari 2003.
[24] Kolkman, O. and J. Schlyter, "KEY RR Key Signing Key (KSK) Flag", draft-
     ietf-dnsext-keyrr-key-signing-flag-05 (work in progress), December 2002.3

     Books and documents
[25] Albitz, P and Liu, C. DNS and BIND, 4th edition, April 2001.
[26] AFNIC.        Formation-DNS         (slides      in        French),         2001.
[27] Kolkman, O. DNSsec Operational HOWTO, revision 1.3, September 2002.
[28] Liu,        C.      Securing       an        Internet       Name        Server.
     http://www.linuxsecurity.com/resource files/server security/securing an internet name server.pdf
[29] ISC. BIND 9 Administrator Reference Manual, 2001

     Web resources
[30] IETF (Internet Engineering Task Force). http://www.ietf.org
[31] DNSEXT wg (DNS Extensions working group)                        at    the   IETF.
[32] DNSOP wg (DNS Operations working group)                        at     the   IETF.
[33] RIPE (Reseaux IP Europeens). http://www.ripe.net

[34] IDsA Project, (Infrastructure DNSsec et Applications). DNSsec test plat-
     form deployment, DNSsec tools development, and DNSsec related appli-
     cations (IPv6 mobility, DNSsec-IPsec interactions). http://www.idsa.prd.fr &
[35] NLnet Labs. Several projects             in   progress   related   to   DNSsec.
[36] DNSsec, securing the domain name system. Collection of resources about
     DNSsec available on the net. http://www.dnssec.net
[37] BIND by ISC (Internet Software Consortium). http://www.isc.org

Copyright (C) IDsA (Infrastructure DNS sec et applications,
http://www.telecom.gouv.fr/rnrt/projets/res 02 22.htm) Project partners.
Use of this document must be preceded by an explicit agreement of the following IDsA

- France Telecom R&D
- ENST-Bretagne (Rennes)

Any commercial use of this document is reserved.


Shared By: