+++ /dev/null
-
-
-Network Working Group D. Atkins
-draft-ietf-dnsext-dns-threats-06.txt IHTFP Consulting
- R. Austein
- ISC
- February 2004
-
-
- Threat Analysis of the Domain Name System
-
-
-Status of this document
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>
-
- The list of Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>
-
- Distribution of this document is unlimited. Please send comments to
- the Namedroppers mailing list <namedroppers@ops.ietf.org>.
-
-Abstract
-
- Although the DNS Security Extensions (DNSSEC) have been under
- development for most of the last decade, the IETF has never written
- down the specific set of threats against which DNSSEC is designed to
- protect. Among other drawbacks, this cart-before-the-horse situation
- has made it difficult to determine whether DNSSEC meets its design
- goals, since its design goals are not well specified. This note
- attempts to document some of the known threats to the DNS, and, in
- doing so, attempts to measure to what extent (if any) DNSSEC is a
- useful tool in defending against these threats.
-
-
-
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 1]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
-1. Introduction
-
- The earliest organized work on DNSSEC within the IETF was an open
- design team meeting organized by members of the DNS working group in
- November 1993 at the 28th IETF meeting in Houston. The broad
- outlines of DNSSEC as we know it today are already clear in Jim
- Galvin's summary of the results of that meeting [Galvin93]:
-
- - While some participants in the meeting were interested in
- protecting against disclosure of DNS data to unauthorized parties,
- the design team made an explicit decision that "DNS data is
- `public'", and ruled all threats of data disclosure explicitly out
- of scope for DNSSEC.
-
- - While some participants in the meeting were interested in
- authentication of DNS clients and servers as a basis for access
- control, this work was also ruled out of scope for DNSSEC per se.
-
- - Backwards compatibility and co-existence with "insecure DNS" was
- listed as an explicit requirement.
-
- - The resulting list of desired security services was
- 1) data integrity, and
- 2) data origin authentication.
-
- - The design team noted that a digital signature mechanism would
- support the desired services.
-
- While a number of detail decisions were yet to be made (and in some
- cases remade after implementation experience) over the subsequent
- decade, the basic model and design goals have remained fixed.
-
- Nowhere, however, does any of the DNSSEC work attempt to specify in
- any detail the sorts of attacks against which DNSSEC is intended to
- protect, or the reasons behind the list of desired security services
- that came out of the Houston meeting. For that, we have to go back
- to a paper originally written by Steve Bellovin in 1990 but not
- published until 1995, for reasons that Bellovin explained in the
- paper's epilogue [Bellovin95].
-
- While it may seem a bit strange to publish the threat analysis a
- decade after starting work on the protocol designed to defend against
- it, that is nevertheless what this note attempts to do. Better late
- than never.
-
- This note assumes that the reader is familiar with both the DNS and
- with DNSSEC, and does not attempt to provide a tutorial on either.
- The DNS documents most relevant to the subject of this note are:
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 2]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
- [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
-
- For purposes of discussion, this note uses the term "DNSSEC" to refer
- to the core hierarchical public key and signature mechanism specified
- in the DNSSEC documents, and refers to TKEY and TSIG as separate
- mechanisms, even though channel security mechanisms such as TKEY and
- TSIG are also part of the larger problem of "securing DNS" and thus
- are often considered part of the overall set of "DNS security
- extensions". This is an arbitrary distinction that in part reflects
- the way in which the protocol has evolved (introduction of a
- putatively simpler channel security model for certain operations such
- as zone transfers and dynamic update requests), and perhaps should be
- changed in a future revision of this note.
-
-2. Known Threats
-
- There are several distinct classes of threats to the DNS, most of
- which are DNS-related instances of more general problems, but a few
- of which are specific to peculiarities of the DNS protocol.
-
-2.1. Packet Interception
-
- Some of the simplest threats against DNS are various forms of packet
- interception: monkey-in-the-middle attacks, eavesdropping on requests
- combined with spoofed responses that beat the real response back to
- the resolver, and so forth. In any of these scenarios, the attacker
- can simply tell either party (usually the resolver) whatever it wants
- that party to believe. While packet interception attacks are far
- from unique to DNS, DNS's usual behavior of sending an entire query
- or response in a single unsigned, unencrypted UDP packet makes these
- attacks particularly easy for any bad guy with the ability to
- intercept packets on a shared or transit network.
-
- To further complicate things, the DNS query the attacker intercepts
- may just be a means to an end for the attacker: the attacker might
- even choose to return the correct result in the answer section of a
- reply message while using other parts of the message to set the stage
- for something more complicated, for example, a name-based attack (see
- below).
-
- While it certainly would be possible to sign DNS messages using a
- channel security mechanism such as TSIG or IPsec, or even to encrypt
- them using IPsec, this would not be a very good solution. First,
- this approach would impose a fairly high processing cost per DNS
- message, as well as a very high cost associated with establishing and
- maintaining bilateral trust relationships between all the parties
- that might be involved in resolving any particular query. For
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 3]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- heavily used name servers (such as the servers for the root zone),
- this cost would almost certainly be prohibitively high. Even more
- important, however, is that the underlying trust model in such a
- design would be wrong, since at best it would only provide a hop-by-
- hop integrity check on DNS messages and would not provide any sort of
- end-to-end integrity check between the producer of DNS data (the zone
- administrator) and the consumer of DNS data (the application that
- triggered the query).
-
- By contrast, DNSSEC (when used properly) does provide an end-to-end
- data integrity check, and is thus a much better solution for this
- class of problems during basic DNS lookup operations.
-
- TSIG does have its place in corners of the DNS protocol where there's
- a specific trust relationship between a particular client and a
- particular server, such as zone transfer, dynamic update, or a
- resolver (stub or otherwise) that is not going to check all the
- DNSSEC signatures itself.
-
- Note that DNSSEC does not provide any protection against modification
- of the DNS message header, so any properly paranoid resolver must:
-
- - Perform all of the DNSSEC signature checking on its own,
-
- - Use TSIG (or some equivalent mechanism) to ensure the integrity of
- its communication with whatever name servers it chooses to trust,
- or
-
- - Resign itself to the possibility of being attacked via packet
- interception (and via other techniques discussed below).
-
-2.2. ID Guessing and Query Prediction
-
- Since DNS is for the most part used over UDP/IP, it is relatively
- easy for an attacker to generate packets which will match the
- transport protocol parameters. The ID field in the DNS header is
- only a 16-bit field and the server UDP port associated with DNS is a
- well-known value, so there are only 2**32 possible combinations of ID
- and client UDP port for a given client and server. This is not a
- particularly large range, and is not sufficient to protect against a
- brute force search; furthermore, in practice both the client UDP port
- and the ID can often be predicted from previous traffic, and it is
- not uncommon for the client port to be a known fixed value as well
- (due to firewalls or other restrictions), thus frequently reducing
- the search space to a range smaller than 2**16.
-
- By itself, ID guessing is not enough to allow an attacker to inject
- bogus data, but combined with knowledge (or guesses) about QNAMEs and
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 4]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- QTYPEs for which a resolver might be querying, this leaves the
- resolver only weakly defended against injection of bogus responses.
-
- Since this attack relies on predicting a resolver's behavior, it's
- most likely to be successful when the victim is in a known state,
- whether because the victim rebooted recently, or because the victim's
- behavior has been influenced by some other action by the attacker, or
- because the victim is responding (in a predictable way) to some third
- party action known to the attacker.
-
- This attack is both more and less difficult for the attacker than the
- simple interception attack described above: more difficult, because
- the attack only works when the attacker guesses correctly; less
- difficult, because the attacker doesn't need to be on a transit or
- shared network.
-
- In most other respects, this attack is similar to a packet
- interception attack. A resolver that checks DNSSEC signatures will
- be able to detect the forged response; resolvers that do not
- themselves perform DNSSEC signature checking should use TSIG or some
- equivalent mechanism to ensure the integrity of their communication
- with a recursing name server that does perform DNSSEC signature
- checking.
-
-2.3. Name Games
-
- Perhaps the most interesting class of DNS-specific threats are the
- name-based attacks. There are several variations within this class,
- sometimes called "cache poisoning" or "fake authority" attacks. What
- all of these attacks have in common is that they all involve DNS RRs
- whose RDATA portion (right hand side) includes a DNS name. Any such
- RR is, at least in principle, a hook that lets an attacker feed bad
- data into a victim's cache, thus potentially subverting subsequent
- decisions based on DNS names.
-
- The worst examples in this class of RRs are CNAME, NS, and DNAME RRs,
- because they can redirect a victim's query to a location of the
- attacker's choosing. RRs like MX and SRV are somewhat less
- dangerous, but in principle they can also be used to trigger further
- lookups at a location of the attacker's choosing.
-
- The general form of a name-based attack is something like this:
-
- - Victim issues a query, perhaps at the instigation of the attacker
- or some third party; in some cases the query itself may be
- unrelated to the name under attack (that is, the attacker is just
- using this query as a means to inject false information about some
- other name).
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 5]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- - Attacker injects response, whether via packet interception, query
- guessing, or by being a legitimate name server that's involved at
- some point in the process of answering the query that the victim
- issued.
-
- - Attacker's response includes one or more RRs with DNS names in
- their RDATA; depending on which particular form this attack takes,
- the object may be to inject false data associated with those names
- into the victim's cache via the Additional section of this
- response, or may be to redirect the next stage of the query to a
- server of the attacker's choosing (in order to inject more complex
- lies into the victim's cache than will fit easily into a single
- response, or in order to place the lies in the Authority or Answer
- section of a response where they will have a better chance of
- sneaking past a resolver's defenses).
-
- Any attacker who can insert resource records into a victim's cache
- can almost certainly do some kind of damage, so there are cache
- poisoning attacks which are not name-based attacks in the sense
- discussed here. However, in the case of name-based attacks, the
- cause and effect relationship between the initial attack and the
- eventual result may be significantly more complex than in the other
- forms of cache poisoning, so name-based attacks merit special
- attention.
-
- The common thread in all of the name-based attacks is that response
- messages allow the attacker to introduce arbitrary DNS names of the
- attacker's choosing and provide further information that the attacker
- claims is associated with those names; unless the victim has better
- knowledge of the data associated with those names, the victim is
- going to have a hard time defending against this class of attacks.
-
- This class of attack is particularly insidious given that it's quite
- easy for an attacker to provoke a victim into querying for a
- particular name of the attacker's choosing, for example, by embedding
- a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
- to the victim. If the victim's mail reading program attempts to
- follow such a link, the result will be a DNS query for a name chosen
- by the attacker.
-
- DNSSEC should provide a good defense against most (all?) variations
- on this class of attack. By checking signatures, a resolver can
- determine whether the data associated with a name really was inserted
- by the delegated authority for that portion of the DNS name space
- (more precisely, a resolver can determine whether the entity that
- injected the data had access to an allegedly secret key whose
- corresponding public key appears at an expected location in the DNS
- name space with an expected chain of parental signatures that start
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 6]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- with a public key of which the resolver has prior knowledge).
-
- DNSSEC signatures do not cover glue records, so there's still a
- possibility of a name-based attack involving glue, but with DNSSEC it
- is possible to detect the attack by temporarily accepting the glue in
- order to fetch the signed authoritative version of the same data,
- then checking the signatures on the authoritative version.
-
-2.4. Betrayal By Trusted Server
-
- Another variation on the packet interception attack is the trusted
- server that turns out not to be so trustworthy, whether by accident
- or by intent. Many client machines are only configured with stub
- resolvers, and use trusted servers to perform all of their DNS
- queries on their behalf. In many cases the trusted server is
- furnished by the user's ISP and advertised to the client via DHCP or
- PPP options. Besides accidental betrayal of this trust relationship
- (via server bugs, successful server break-ins, etc), the server
- itself may be configured to give back answers that are not what the
- user would expect (whether in an honest attempt to help the user or
- to further some other goal such as furthering a business partnership
- between the ISP and some third party).
-
- This problem is particularly acute for frequent travelers who carry
- their own equipment and expect it to work in much the same way no
- matter which network it's plugged into at any given moment (and no
- matter what brand of middle boxes a particular hotel chain might have
- installed when adding network drops in every guest room...).
-
- While the obvious solution to this problem would be for the client to
- choose a more trustworthy server, in practice this may not be an
- option for the client. In many network environments a client machine
- has only a limited set of recursive name servers from which to
- choose, and none of them may be particularly trustworthy. In extreme
- cases, port filtering or other forms of packet interception may
- prevent the client host from being able to run an iterative resolver
- even if the owner of the client machine is willing and able to do so.
- Thus, while the initial source of this problem is not a DNS protocol
- attack per se, this sort of betrayal is a threat to DNS clients, and
- simply switching to a different recursive name server is not an
- adequate defense.
-
- Viewed strictly from the DNS protocol standpoint, the only difference
- between this sort of betrayal and a packet interception attack is
- that in this case the client has voluntarily sent its request to the
- attacker. The defense against this is the same as with a packet
- interception attack: the resolver must either check DNSSEC signatures
- itself or use TSIG (or equivalent) to authenticate the server that it
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 7]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- has chosen to trust. Note that use of TSIG does not by itself
- guarantee that a name server is at all trustworthy: all TSIG can do
- is help a resolver protect its communication with a name server that
- it has already decided to trust for other reasons. Protecting a
- resolver's communication with a server that's giving out bogus
- answers is not particularly useful.
-
- Also note that if the stub resolver does not trust the name server
- that is doing work on its behalf and wants to check the DNSSEC
- signatures itself, the resolver really does need to have independent
- knowledge of the DNSSEC public key(s) it needs in order to perform
- the check (usually the public key for the root zone, but in some
- cases knowledge of additional keys may also be appropriate).
-
- It is difficult to escape the conclusion that a properly paranoid
- resolver must always perform its own signature checking, and that
- this rule even applies to stub resolvers.
-
-2.5. Denial of Service
-
- As with any network service (or, indeed, almost any service of any
- kind in any domain of discourse), DNS is vulnerable to denial of
- service attacks. DNSSEC does not help this, and may in fact make the
- problem worse for resolvers that check signatures, since checking
- signatures both increases the processing cost per DNS message and in
- some cases can also increase the number of messages needed to answer
- a query. TSIG (and similar mechanisms) have equivalent problems.
-
- DNS servers are also at risk of being used as denial of service
- amplifiers, since DNS response packets tend to be significantly
- longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help
- here either.
-
-2.6. Authenticated Denial of Domain Names
-
- Much discussion has taken place over the question of authenticated
- denial of domain names. The particular question is whether there is
- a requirement for authenticating the non-existence of a name. The
- issue is whether the resolver should be able to detect when an
- attacker removes RRs from a response.
-
- General paranoia aside, the existence of RR types whose absence
- causes an action other than immediate failure (such as missing MX and
- SRV RRs, which fail over to A RRs) constitutes a real threat.
- Arguably, in some cases, even the immediate failure of a missing RR
- might be considered a problem. The question remains: how serious is
- this threat? Clearly the threat does exist; general paranoia says
- that some day it'll be on the front page of some major newspaper,
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 8]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- even if we cannot conceive of a plausible scenario involving this
- attack today. This implies that some mitigation of this risk is
- required.
-
- Note that it's necessary to prove the non-existence of applicable
- wildcard RRs as part of the authenticated denial mechanism, and that,
- in a zone that is more than one label deep, such a proof may require
- proving the non-existence of multiple discrete sets of wildcard RRs.
-
- DNSSEC does include mechanisms which make it possible to determine
- which authoritative names exist in a zone, and which authoritative
- resource record types exist at those names. The DNSSEC protections
- do not cover non-authoritative data such as glue records.
-
-2.7. Wildcards
-
- Much discussion has taken place over whether and how to provide data
- integrity and data origin authentication for "wildcard" DNS names.
- Conceptually, RRs with wildcard names are patterns for synthesizing
- RRs on the fly according to the matching rules described in section
- 4.3.2 of RFC 1034. While the rules that control the behavior of
- wildcard names have a few quirks that can make them a trap for the
- unwary zone administrator, it's clear that a number of sites make
- heavy use of wildcard RRs, particularly wildcard MX RRs.
-
- In order to provide the desired services for wildcard RRs, we need to
- do two things:
-
- - We need a way to attest to the existence of the wildcard RR itself
- (that is, we need to show that the synthesis rule exists), and
-
- - We need a way to attest to the non-existence of any RRs which, if
- they existed, would make the wildcard RR irrelevant according to
- the synthesis rules that govern the way in which wildcard RRs are
- used (that is, we need to show that the synthesis rule is
- applicable).
-
- Note that this makes the wildcard mechanisms dependent upon the
- authenticated denial mechanism described in the previous section.
-
- DNSSEC includes mechanisms along the lines described above, which
- make it possible for a resolver to verify that a name server applied
- the wildcard expansion rules correctly when generating an answer.
-
-3. Weaknesses of DNSSEC
-
- DNSSEC has some problems of its own:
-
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 9]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- - DNSSEC is complex to implement, and includes some nasty edge cases
- at the zone cuts that require very careful coding. Testbed
- experience to date suggests that trivial zone configuration errors
- or expired keys can cause serious problems for a DNSSEC-aware
- resolver, and that the current protocol's error reporting
- capabilities may leave something to be desired.
-
- - DNSSEC significantly increases the size of DNS response packets;
- among other issues, this makes DNSSEC-aware DNS servers even more
- effective as denial of service amplifiers.
-
- - DNSSEC answer validation increases the resolver's work load, since
- a DNSSEC-aware resolver will need to perform signature validation
- and in some cases will also need to issue further queries. This
- increased workload will also increase the time it takes to get an
- answer back to the original DNS client, which is likely to trigger
- both timeouts and re-queries in some cases. (Arguably, many
- current DNS clients are already too impatient even before taking
- the further delays that DNSSEC will impose into account, but that's
- a separate topic for another document....)
-
- - Like DNS itself, DNSSEC's trust model is almost totally
- hierarchical. While DNSSEC does allow resolvers to have special
- additional knowledge of public keys beyond those for the root, in
- the general case the root key is the one that matters. Thus any
- compromise in any of the zones between the root and a particular
- target name can damage DNSSEC's ability to protect the integrity of
- data owned by that target name. This is not a change, since
- insecure DNS has the same model.
-
- - Key rollover at the root is really hard. Work to date has not even
- come close to adequately specifying how the root key rolls over, or
- even how it's configured in the first place.
-
- - DNSSEC creates a requirement of loose time synchronization between
- the validating resolver and the entity creating the DNSSEC
- signatures. Prior to DNSSEC, all time-related actions in DNS could
- be performed by a machine that only knew about "elapsed" or
- "relative" time. Because the validity period of a DNSSEC signature
- is based on "absolute" time, a validating resolver must have the
- same concept of absolute time as the zone signer in order to
- determine whether the signature is within its validity period or
- has expired. An attacker that can change a resolver's opinion of
- the current absolute time can fool the resolver using expired
- signatures. An attacker that can change the zone signer's opinion
- of the current absolute time can fool the zone signer into
- generating signatures whose validity period does not match what the
- signer intended.
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 10]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- - The possible existence of wildcard RRs in a zone complicates the
- authenticated denial mechanism considerably. For most of the
- decade that DNSSEC has been under development these issues were
- poorly understood. At various times there have been questions as
- to whether the authenticated denial mechanism is completely
- airtight and whether it would be worthwhile to optimize the
- authenticated denial mechanism for the common case in which
- wildcards are not present in a zone, but the main problem is just
- the inherent complexity of the wildcard mechanism itself. This
- complexity probably makes the code for generating and checking
- authenticated denial attestations somewhat fragile, but since the
- alternative of giving up wildcards entirely is not practical due to
- widespread use, we are going to have to live with wildcards, and
- the question just becomes one of whether or not the proposed
- optimizations would make DNSSEC's mechanisms more or less fragile.
-
- - Even with DNSSEC, the class of attacks discussed in section 2.4 is
- not easy to defeat. In order for DNSSEC to be effective in this
- case, it must be possible to configure the resolver to expect
- certain categories of DNS records to be signed, which may require
- manual configuration of the resolver, especially during the initial
- DNSSEC rollout period when the resolver cannot reasonably expect
- the root and TLD zones to be signed.
-
-
-4. Topics for Future Work
-
- This section lists a few subjects not covered above which probably
- need additional study, additional mechanisms, or both.
-
-4.1. Interactions With Other Protocols
-
- The above discussion has concentrated exclusively on attacks within
- the boundaries of the DNS protocol itself, since those are the
- problems against (some of) which DNSSEC was intended to protect.
- There are, however, other potential problems at the boundaries where
- DNS interacts with other protocols.
-
-4.2. Securing DNS Dynamic Update
-
- DNS dynamic update opens a number of potential problems when combined
- with DNSSEC. Dynamic update of a non-secure zone can use TSIG to
- authenticate the updating client to the server. While TSIG does not
- scale very well (it requires manual configuration of shared keys
- between the DNS name server and each TSIG client), it works well in a
- limited or closed environment such as a DHCP server updating a local
- DNS name server.
-
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 11]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- Major issues arise when trying to use dynamic update on a secure
- zone. TSIG can similarly be used in a limited fashion to
- authenticate the client to the server, but TSIG only protects DNS
- transactions, not the actual data, and the TSIG is not inserted into
- the DNS zone, so resolvers cannot use the TSIG as a way of verifying
- the changes to the zone. This means that either:
-
- a) The updating client must have access to a zone-signing key in
- order to sign the update before sending it to the server, or
-
- b) The DNS name server must have access to an online zone-signing key
- in order to sign the update.
-
- In either case, a zone-signing key must be available to create signed
- RRsets to place in the updated zone. The fact that this key must be
- online (or at least available) is a potential security risk.
-
- Dynamic update also requires an update to the SERIAL field of the
- zone's SOA RR. In theory, this could also be handled via either of
- the above options, but in practice (a) would almost certainly be
- extremely fragile, so (b) is the only workable mechanism.
-
- There are other threats in terms of describing the policy of who can
- make what changes to which RRsets in the zone. The current access
- control scheme in Secure Dynamic Update is fairly limited. There is
- no way to give fine-grained access to updating DNS zone information
- to multiple entities, each of whom may require different kinds of
- access. For example, Alice may need to be able to add new nodes to
- the zone or change existing nodes, but not remove them; Bob may need
- to be able to remove zones but not add them; Carol may need to be
- able to add, remove, or modify nodes, but only A records.
-
- Scaling properties of the key management problem here are a
- particular concern that needs more study.
-
-4.3. Securing DNS Zone Replication
-
- As discussed in previous sections, DNSSEC per se attempts to provide
- data integrity and data origin authentication services on top of the
- normal DNS query protocol. Using the terminology discussed in
- [RFC3552], DNSSEC provides "object security" for the normal DNS query
- protocol. For purposes of replicating entire DNS zones, however,
- DNSSEC does not provide object security, because zones include
- unsigned NS RRs and glue at delegation points. Use of TSIG to
- protect zone transfer (AXFR or IXFR) operations provides "channel
- security", but still does not provide object security for complete
- zones, so the trust relationships involved in zone transfer are still
- very much a hop-by-hop matter of name server operators trusting other
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 12]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- name server operators, rather than an end-to-end matter of name
- server operators trusting zone administrators.
-
- Zone object security was not an explicit design goal of DNSSEC, so
- failure to provide this service should not be a surprise.
- Nevertheless, there are some zone replication scenarios for which
- this would be a very useful additional service, so this seems like a
- useful area for future work. In theory it should not be difficult to
- zone object security as a backwards compatible enhancement to the
- existing DNSSEC model, but the DNSEXT WG has not yet discussed either
- the desirability of or the requirements for such an enhancement.
-
-5. Conclusion
-
- Based on the above analysis, the DNSSEC extensions do appear to solve
- a set of problems that do need to be solved, and are worth deploying.
-
-Security Considerations
-
- This entire document is about security considerations of the DNS.
- The authors believe that deploying DNSSEC will help to address some,
- but not all, of the known threats to the DNS.
-
-IANA Considerations
-
- None.
-
-Acknowledgments
-
- This note is based both previous published works by others and on a
- number of discussions both public and private over a period of many
- years, but particular thanks go to Jaap Akkerhuis, Steve Bellovin,
- Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ
- Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten
- Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other
- members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose
- names and contributions the authors have forgotten, none of whom are
- responsible for what the authors did with their ideas.
-
- As with any work of this nature, the authors of this note acknowledge
- that we are standing on the toes of those who have gone before us.
- Readers interested in this subject may also wish to read
- [Bellovin95], [Schuba93], and [Vixie95].
-
-Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- RFC 1034, November 1987.
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 13]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", RFC 1035, November 1987.
-
- [RFC1123] Braden, R., Editor, "Requirements for Internet Hosts -
- Application and Support", RFC 1123, October 1989.
-
- [RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS
- Specification" RFC 2181, July 1997.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)"
- RFC 2308, March 1998.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)" RFC 2845, May 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)"
- RFC 2930, September 2000.
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update" RFC 3007, November 2000.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
-Informative References
-
- [RFC3552] Rescorla, E., Korver, B., and the Internet Architecture
- Board, "Guidelines for Writing RFC Text on Security
- Considerations", RFC 3552, July 2003.
-
- [Bellovin95] Bellovin, S., "Using the Domain Name System for System
- Break-Ins", Proceedings of the Fifth Usenix Unix Security
- Symposium, June 1995.
-
- [Galvin93] Design team meeting summary message posted to dns-
- security@tis.com mailing list by Jim Galvin on 19 November 1993.
-
- [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name
- System Protocol", Master's thesis, Purdue University Department
- of Computer Sciences, August 1993.
-
- [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
- the Fifth Usenix Unix Security Symposium, June 1995.
-
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 14]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
-Authors' addresses:
-
- Derek Atkins
- IHTFP Consulting, Inc.
- 6 Farragut Ave
- Somerville, MA 02144
- USA
-
- Email: derek@ihtfp.com
-
- Rob Austein
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- Email: sra@isc.org
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 15]
-\f
-draft-ietf-dnsext-dns-threats-06.txt February 2004
-
-
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Atkins & Austein Expires 21 August 2004 [Page 16]
-
+++ /dev/null
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 16, 2004 R. Austein
- ISC
- M. Larson
- VeriSign
- D. Massey
- USC/ISI
- S. Rose
- NIST
- February 16, 2004
-
-
- DNS Security Introduction and Requirements
- draft-ietf-dnsext-dnssec-intro-09
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 16, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- The Domain Name System Security Extensions (DNSSEC) add data origin
- authentication and data integrity to the Domain Name System. This
- document introduces these extensions, and describes their
- capabilities and limitations. This document also discusses the
- services that the DNS security extensions do and do not provide.
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 1]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
- Last, this document describes the interrelationships between the
- group of documents that collectively describe DNSSEC.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
- 3. Services Provided by DNS Security . . . . . . . . . . . . . . 7
- 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 7
- 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 8
- 4. Services Not Provided by DNS Security . . . . . . . . . . . . 10
- 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 11
- 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 12
- 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 13
- 7.1 TTL values vs. RRSIG validity period . . . . . . . . . . . . . 13
- 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13
- 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14
- 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
- 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
- 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
- Normative References . . . . . . . . . . . . . . . . . . . . . 20
- Informative References . . . . . . . . . . . . . . . . . . . . 21
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
- Intellectual Property and Copyright Statements . . . . . . . . 24
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 2]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-1. Introduction
-
- This document introduces the Domain Name System Security Extensions
- (DNSSEC). This document and its two companion documents
- ([I-D.ietf-dnsext-dnssec-records] and
- [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
- security extensions defined in RFC 2535 [RFC2535] and its
- predecessors. These security extensions consist of a set of new
- resource record types and modifications to the existing DNS protocol
- [RFC1035]. The new records and protocol modifications are not fully
- described in this document, but are described in a family of
- documents outlined in Section 9. Section 3 and Section 4 describe the
- capabilities and limitations of the security extensions in greater
- detail. Section 5, Section 6, Section 7, and Section 8 discuss the
- effect that these security extensions will have on resolvers, stub
- resolvers, zones and name servers.
-
- This document and its two companions update and obsolete RFCs 2535
- [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445
- [RFC3445], as well as several works in progress: "Redefinition of the
- AD bit" [RFC3655], "Legacy Resolver Compatibility for Delegation
- Signer" [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation
- Signer Resource Record" [RFC3658]. This document set also updates,
- but does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
- [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 [RFC3597].
-
- The DNS security extensions provide origin authentication and
- integrity protection for DNS data, as well as a means of public key
- distribution. These extensions do not provide confidentiality.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 3]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-2. Definitions of Important DNSSEC Terms
-
- This section defines a number of terms used in this document set.
- Since this is intended to be useful as a reference while reading the
- rest of the document set, first-time readers may wish to skim this
- section quickly, read the rest of this document, then come back to
- this section.
-
- authentication chain: an alternating sequence of DNSKEY RRsets and DS
- RRsets forms a chain of signed data, with each link in the chain
- vouching for the next. A DNSKEY RR is used to verify the
- signature covering a DS RR and allows the DS RR to be
- authenticated. The DS RR contains a hash of another DNSKEY RR and
- this new DNSKEY RR is authenticated by matching the hash in the DS
- RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset
- and, in turn, some DNSKEY RR in this set may be used to
- authenticate another DS RR and so forth until the chain finally
- ends with a DNSKEY RR which signs the desired DNS data. For
- example, the root DNSKEY RRset can be used to authenticate the DS
- RRset for "example." The "example." DS RRset contains a hash that
- matches some "example." DNSKEY and this DNSKEY signs the
- "example." DNSKEY RRset. Private key counterparts of the
- "example." DNSKEY RRset sign data records such as "www.example."
- as well as DS RRs for delegations such as "subzone.example."
-
- authentication key: A public key which a security-aware resolver has
- verified and can therefore use to authenticate data. A
- security-aware resolver can obtain authentication keys in three
- ways. First, the resolver is generally preconfigured to know
- about at least one public key. This preconfigured data is usually
- either the public key itself or a hash of the key as found in the
- DS RR. Second, the resolver may use an authenticated public key
- to verify a DS RR and its associated DNSKEY RR. Third, the
- resolver may be able to determine that a new key has been signed
- by another key which the resolver has verified. Note that the
- resolver must always be guided by local policy when deciding
- whether to authenticate a new key, even if the local policy is
- simply to authenticate any new key for which the resolver is able
- verify the signature.
-
- delegation point: Term used to describe the name at the parental side
- of a zone cut. That is, the delegation point for "foo.example"
- would be the foo.example node in the "example" zone (as opposed to
- the zone apex of the "foo.example" zone).
-
- island of security: Term used to describe a signed, delegated zone
- that does not have an authentication chain from its delegating
- parent. That is, there is no DS RR with the island's public key
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 4]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
- in its delegating parent zone (see
- [I-D.ietf-dnsext-dnssec-records]). An island of security is served
- by a security-aware nameserver and may provide authentication
- chains to any delegated child zones. Responses from an island of
- security or its descendents can only be authenticated if its zone
- key can be authenticated by some trusted means out of band from
- the DNS protocol.
-
- key signing key: An authentication key which is used to sign one or
- more other authentication keys for a given zone. Typically, a key
- signing key will sign a zone signing key, which in turn will sign
- other zone data. Local policy may require the zone signing key to
- be changed frequently, while the key signing key may have a longer
- validity period in order to provide a more stable secure entry
- point into the zone. Designating an authentication key as a key
- signing key is purely an operational issue: DNSSEC validation does
- not distinguish between key signing keys and other DNSSEC
- authentication keys. Key signing keys are discussed in more
- detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone
- signing key.
-
- non-validating security-aware stub resolver: A security-aware stub
- resolver which trusts one or more security-aware recursive name
- servers to perform most of the tasks discussed in this document
- set on its behalf. In particular, a non-validating security-aware
- stub resolver is an entity which sends DNS queries, receives DNS
- responses, and is capable of establishing an appropriately secured
- channel to a security-aware recursive name server which will
- provide these services on behalf of the security-aware stub
- resolver. See also: security-aware stub resolver, validating
- security-aware stub resolver.
-
- non-validating stub resolver: A less tedious term for a
- non-validating security-aware stub resolver.
-
- security-aware name server: An entity acting in the role of a name
- server (defined in section 2.4 of [RFC1034]) which understands the
- DNS security extensions defined in this document set. In
- particular, a security-aware name server is an entity which
- receives DNS queries, sends DNS responses, supports the EDNS0
- [RFC2671] message size extension and the DO bit [RFC3225], and
- supports the RR types and message header bits defined in this
- document set.
-
- security-aware recursive name server: An entity which acts in both
- the security-aware name server and security-aware resolver roles.
- A more cumbersome equivalent phrase would be "a security-aware
- name server which offers recursive service".
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 5]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
- security-aware resolver: An entity acting in the role of a resolver
- (defined in section 2.4 of [RFC1034]) which understands the DNS
- security extensions defined in this document set. In particular,
- a security-aware resolver is an entity which sends DNS queries,
- receives DNS responses, supports the EDNS0 [RFC2671] message size
- extension and the DO bit [RFC3225], and is capable of using the RR
- types and message header bits defined in this document set to
- provide DNSSEC services.
-
- security-aware stub resolver: An entity acting in the role of a stub
- resolver (defined in section 5.3.1 of [RFC1034]) which has enough
- of an understanding the DNS security extensions defined in this
- document set to provide additional services not available from a
- security-oblivious stub resolver. Security-aware stub resolvers
- may be either "validating" or "non-validating" depending on
- whether the stub resolver attempts to verify DNSSEC signatures on
- its own or trusts a friendly security-aware name server to do so.
- See also: validating stub resolver, non-validating stub resolver.
-
- security-oblivious <anything>: An <anything> which is not
- "security-aware".
-
- signed zone: A zone whose RRsets are signed and which contains
- properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
- records.
-
- unsigned zone: A zone which is not signed.
-
- validating security-aware stub resolver: A security-aware resolver
- which operates sends queries in recursive mode but which performs
- signature validation on its own rather than just blindly trusting
- a friendly security-aware recursive name server. See also:
- security-aware stub resolver, non-validating security-aware stub
- resolver.
-
- validating stub resolver: A less tedious term for a validating
- security-aware stub resolver.
-
- zone signing key: An authentication key which is used to sign a zone.
- See key signing key, above. Typically a zone signing key will be
- part of the same DNSKEY RRset as the key signing key which signs
- it, but is used for a slightly different purpose and may differ
- from the key signing key in other ways, such as validity lifetime.
- Designating an authentication key as a zone signing key is purely
- an operational issue: DNSSEC validation does not distinguish
- between zone signing keys and other DNSSEC authentication keys.
- See also: key signing key.
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 6]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-3. Services Provided by DNS Security
-
- The Domain Name System (DNS) security extensions provide origin
- authentication and integrity assurance services for DNS data,
- including mechanisms for authenticated denial of existence of DNS
- data. These mechanisms are described below.
-
- These mechanisms require changes to the DNS protocol. DNSSEC adds
- four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two
- new message header bits (CD and AD). In order to support the larger
- DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
- requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support
- for the DO bit [RFC3225], so that a security-aware resolver can
- indicate in its queries that it wishes to receive DNSSEC RRs in
- response messages.
-
- These services protect against most of the threats to the Domain Name
- System described in [I-D.ietf-dnsext-dns-threats].
-
-3.1 Data Origin Authentication and Data Integrity
-
- DNSSEC provides authentication by associating cryptographically
- generated digital signatures with DNS RRsets. These digital
- signatures are stored in a new resource record, the RRSIG record.
- Typically, there will be a single private key that signs a zone's
- data, but multiple keys are possible: for example, there may be keys
- for each of several different digital signature algorithms. If a
- security-aware resolver reliably learns a zone's public key, it can
- authenticate that zone's signed data. An important DNSSEC concept is
- that the key that signs a zone's data is associated with the zone
- itself and not with the zone's authoritative name servers (public
- keys for DNS transaction authentication mechanisms may also appear in
- zones, as described in [RFC2931], but DNSSEC itself is concerned with
- object security of DNS data, not channel security of DNS
- transactions).
-
- A security-aware resolver can learn a zone's public key either by
- having the key preconfigured into the resolver or by normal DNS
- resolution. To allow the latter, public keys are stored in a new
- type of resource record, the DNSKEY RR. Note that the private keys
- used to sign zone data must be kept secure, and should be stored
- offline when practical to do so. To discover a public key reliably
- via DNS resolution, the target key itself needs to be signed by
- either a preconfigured authentication key or another key that has
- been authenticated previously. Security-aware resolvers authenticate
- zone information by forming an authentication chain from a newly
- learned public key back to a previously known authentication public
- key, which in turn either must have been preconfigured into the
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 7]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
- resolver or must have been learned and verified previously.
- Therefore, the resolver must be configured with at least one public
- key or hash of a public key: if the preconfigured key is a zone
- signing key, then it will authenticate the associated zone; if the
- preconfigured key is a key signing key, it will authenticate a zone
- signing key. If the resolver has been preconfigured with the hash of
- a key rather than the key itself, the resolver may need to obtain the
- key via a DNS query. To help security-aware resolvers establish this
- authentication chain, security-aware name servers attempt to send the
- signature(s) needed to authenticate a zone's public key in the DNS
- reply message along with the public key itself, provided there is
- space available in the message.
-
- The Delegation Signer (DS) RR type simplifies some of the
- administrative tasks involved in signing delegations across
- organizational boundaries. The DS RRset resides at a delegation
- point in a parent zone and indicates the key or keys used by the
- delegated child zone to self-sign the DNSKEY RRset at the child
- zone's apex. The child zone, in turn, uses one or more of the keys
- in this DNSKEY RRset to sign its zone data. The typical
- authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where
- "*" denotes zero or more DS->DNSKEY subchains. DNSSEC permits more
- complex authentication chains, such as additional layers of DNSKEY
- RRs signing other DNSKEY RRs within a zone.
-
- A security-aware resolver normally constructs this authentication
- chain from the root of the DNS hierarchy down to the leaf zones based
- on preconfigured knowledge of the public key for the root. Local
- policy, however, may also allow a security-aware resolver to use one
- or more preconfigured keys (or key hashes) other than the root key,
- or may not provide preconfigured knowledge of the root key, or may
- prevent the resolver from using particular keys for arbitrary reasons
- even if those keys are properly signed with verifiable signatures.
- DNSSEC provides mechanisms by which a security-aware resolver can
- determine whether an RRset's signature is "valid" within the meaning
- of DNSSEC. In the final analysis however, authenticating both DNS
- keys and data is a matter of local policy, which may extend or even
- override the protocol extensions defined in this document set.
-
-3.2 Authenticating Name and Type Non-Existence
-
- The security mechanism described in Section 3.1 only provides a way
- to sign existing RRsets in a zone. The problem of providing negative
- responses with the same level of authentication and integrity
- requires the use of another new resource record type, the NSEC
- record. The NSEC record allows a security-aware resolver to
- authenticate a negative reply for either name or type non-existence
- via the same mechanisms used to authenticate other DNS replies. Use
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 8]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
- of NSEC records requires a canonical representation and ordering for
- domain names in zones. Chains of NSEC records explicitly describe
- the gaps, or "empty space", between domain names in a zone, as well
- as listing the types of RRsets present at existing names. Each NSEC
- record is signed and authenticated using the mechanisms described in
- Section 3.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 9]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-4. Services Not Provided by DNS Security
-
- DNS was originally designed with the assumptions that the DNS will
- return the same answer to any given query regardless of who may have
- issued the query, and that all data in the DNS is thus visible.
- Accordingly, DNSSEC is not designed to provide confidentiality,
- access control lists, or other means of differentiating between
- inquirers.
-
- DNSSEC provides no protection against denial of service attacks.
- Security-aware resolvers and security-aware name servers are
- vulnerable to an additional class of denial of service attacks based
- on cryptographic operations. Please see Section 11 for details.
-
- The DNS security extensions provide data and origin authentication
- for DNS data. The mechanisms outlined above are not designed to
- protect operations such as zone transfers and dynamic update
- [RFC3007]. Message authentication schemes described in [RFC2845] and
- [RFC2931] address security operations that pertain to these
- transactions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 10]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-5. Resolver Considerations
-
- A security-aware resolver needs to be able to perform cryptographic
- functions necessary to verify digital signatures using at least the
- mandatory-to-implement algorithm(s). Security-aware resolvers must
- also be capable of forming an authentication chain from a newly
- learned zone back to an authentication key, as described above. This
- process might require additional queries to intermediate DNS zones to
- obtain necessary DNSKEY, DS and RRSIG records. A security-aware
- resolver should be configured with at least one authentication key or
- a key's DS RR hash as the starting point from which it will attempt
- to establish authentication chains.
-
- If a security-aware resolver is separated from the relevant
- authoritative name servers by a recursive name server or by any sort
- of device which acts as a proxy for DNS, and if the recursive name
- server or proxy is not security-aware, the security-aware resolver
- may not be capable of operating in a secure mode. For example, if a
- security-aware resolver's packets are routed through a network
- address translation device that includes a DNS proxy which is not
- security-aware, the security-aware resolver may find it difficult or
- impossible to obtain or validate signed DNS data.
-
- If a security-aware resolver must rely on an unsigned zone or a name
- server that is not security aware, the resolver may not be able to
- validate DNS responses, and will need a local policy on whether to
- accept unverified responses.
-
- A security-aware resolver should take a signature's validation period
- into consideration when determining the TTL of data in its cache, to
- avoid caching signed data beyond the validity period of the
- signature, but should also allow for the possibility that the
- security-aware resolver's own clock is wrong. Thus, a security-aware
- resolver which is part of a security-aware recursive name server will
- need to pay careful attention to the DNSSEC "checking disabled" (CD)
- bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid
- blocking valid signatures from getting through to other
- security-aware resolvers which are clients of this recursive name
- server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure
- recursive server handles queries with the CD bit set.
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 11]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-6. Stub Resolver Considerations
-
- Although not strictly required to do so by the protocol, most DNS
- queries originate from stub resolvers. Stub resolvers, by
- definition, are minimal DNS resolvers which use recursive query mode
- to offload most of the work of DNS resolution to a recursive name
- server. Given the widespread use of stub resolvers, the DNSSEC
- architecture has to take stub resolvers into account, but the
- security features needed in a stub resolver differ in some respects
- from those needed in a full security-aware resolver.
-
- Even an unaugmented stub resolver may get some benefit from DNSSEC if
- the recursive name servers it uses are security-aware, but for the
- stub resolver to place any real reliance on DNSSEC services, the stub
- resolver must trust both the recursive name servers in question and
- the communication channels between itself and those name servers.
- The first of these issues is a local policy issue: in essence, a
- security-oblivious stub resolver has no real choice but to place
- itself at the mercy of the recursive name servers that it uses, since
- it does not perform DNSSEC validity checks on its own. The second
- issue requires some kind of channel security mechanism; proper use of
- DNS transaction authentication mechanisms such as SIG(0) or TSIG
- would suffice, as would appropriate use of IPsec, and particular
- implementations may have other choices available, such as operating
- system specific interprocess communication mechanisms.
- Confidentiality is not needed for this channel, but data integrity
- and message authentication are.
-
- A security-aware stub resolver which does trust both its recursive
- name servers and its communication channel to them may choose to
- examine the setting of the AD bit in the message header of the
- response messages it receives. The stub resolver can use this flag
- bit as a hint to find out whether the recursive name server was able
- to validate signatures for all of the data in the Answer and
- Authority sections of the response.
-
- There is one more step which a security-aware stub resolver can take
- if, for whatever reason, it is not able to establish a useful trust
- relationship with the recursive name servers which it uses: it can
- perform its own signature validation, by setting the Checking
- Disabled (CD) bit in its query messages. A validating stub resolver
- is thus able to treat the DNSSEC signatures as a trust relationship
- between the zone administrator and the stub resolver itself.
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 12]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-7. Zone Considerations
-
- There are several differences between signed and unsigned zones. A
- signed zone will contain additional security-related records (RRSIG,
- DNSKEY, DS and NSEC records). RRSIG and NSEC records may be
- generated by a signing process prior to serving the zone. The RRSIG
- records that accompany zone data have defined inception and
- expiration times, which establish a validity period for the
- signatures and the zone data the signatures cover.
-
-7.1 TTL values vs. RRSIG validity period
-
- It is important to note the distinction between a RRset's TTL value
- and the signature validity period specified by the RRSIG RR covering
- that RRset. DNSSEC does not change the definition or function of the
- TTL value, which is intended to maintain database coherency in
- caches. A caching resolver purges RRsets from its cache no later than
- the end of the time period specified by the TTL fields of those
- RRsets, regardless of whether or not the resolver is security-aware.
-
- The inception and expiration fields in the RRSIG RR
- [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time
- period during which the signature can be used to validate the RRset
- that it covers. The signatures associated with signed zone data are
- only valid for the time period specified by these fields in the RRSIG
- RRs in question. TTL values cannot extend the validity period of
- signed RRsets in a resolver's cache, but the resolver may use the
- time remaining before expiration of the signature validity period of
- a signed RRset as an upper bound for the TTL of the signed RRset and
- its associated RRSIG RR in the resolver's cache.
-
-7.2 New Temporal Dependency Issues for Zones
-
- Information in a signed zone has a temporal dependency which did not
- exist in the original DNS protocol. A signed zone requires regular
- maintenance to ensure that each RRset in the zone has a current valid
- RRSIG RR. The signature validity period of an RRSIG RR is an
- interval during which the signature for one particular signed RRset
- can be considered valid, and the signatures of different RRsets in a
- zone may expire at different times. Re-signing one or more RRsets in
- a zone will change one or more RRSIG RRs, which in turn will require
- incrementing the zone's SOA serial number to indicate that a zone
- change has occurred and re-signing the SOA RRset itself. Thus,
- re-signing any RRset in a zone may also trigger DNS NOTIFY messages
- and zone transfers operations.
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 13]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-8. Name Server Considerations
-
- A security-aware name server should include the appropriate DNSSEC
- records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
- resolvers which have signaled their willingness to receive such
- records via use of the DO bit in the EDNS header, subject to message
- size limitations. Since inclusion of these DNSSEC RRs could easily
- cause UDP message truncation and fallback to TCP, a security-aware
- name server must also support the EDNS "sender's UDP payload"
- mechanism.
-
- If possible, the private half of each DNSSEC key pair should be kept
- offline, but this will not be possible for a zone for which DNS
- dynamic update has been enabled. In the dynamic update case, the
- primary master server for the zone will have to re-sign the zone when
- updated, so the private half of the zone signing key will have to be
- kept online. This is an example of a situation where the ability to
- separate the zone's DNSKEY RRset into zone signing key(s) and key
- signing key(s) may be useful, since the key signing key(s) in such a
- case can still be kept offline.
-
- DNSSEC, by itself, is not enough to protect the integrity of an
- entire zone during zone transfer operations, since even a signed zone
- contains some unsigned, nonauthoritative data if the zone has any
- children, so zone maintenance operations will require some additional
- mechanisms (most likely some form of channel security, such as TSIG,
- SIG(0), or IPsec).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 14]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-9. DNS Security Document Family
-
- The DNSSEC document set can be partitioned into several main groups,
- under the larger umbrella of the DNS base protocol documents.
-
- The "DNSSEC protocol document set" refers to the three documents
- which form the core of the DNS security extensions:
-
- 1. DNS Security Introduction and Requirements (this document)
-
- 2. Resource Records for DNS Security Extensions
- [I-D.ietf-dnsext-dnssec-records]
-
- 3. Protocol Modifications for the DNS Security Extensions
- [I-D.ietf-dnsext-dnssec-protocol]
-
- The "Digital Signature Algorithm Specification" document set refers
- to the group of documents that describe how specific digital
- signature algorithms should be implemented to fit the DNSSEC resource
- record format. Each of these documents deals with a specific digital
- signature algorithm.
-
- The "Transaction Authentication Protocol" document set refers to the
- group of documents that deal with DNS message authentication,
- including secret key establishment and verification. While not
- strictly part of the DNSSEC specification as defined in this set of
- documents, this group is noted to show its relationship to DNSSEC.
-
- The final document set, "New Security Uses", refers to documents that
- seek to use proposed DNS Security extensions for other security
- related purposes. DNSSEC does not provide any direct security for
- these new uses, but may be used to support them. Documents that fall
- in this category include the use of DNS in the storage and
- distribution of certificates [RFC2538].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 15]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-10. IANA Considerations
-
- This overview document introduces no new IANA considerations. Please
- see [I-D.ietf-dnsext-dnssec-records] for a complete review of the
- IANA considerations introduced by DNSSEC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 16]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-11. Security Considerations
-
- This document introduces the DNS security extensions and describes
- the document set that contains the new security records and DNS
- protocol modifications. This document discusses the capabilities and
- limitations of these extensions. The extensions provide data origin
- authentication and data integrity using digital signatures over
- resource record sets.
-
- In order for a security-aware resolver to validate a DNS response,
- all zones along the path from the trusted starting point to the zone
- containing the response zones must be signed, and all name servers
- and resolvers involved in the resolution process must be
- security-aware, as defined in this document set. A security-aware
- resolver cannot verify responses originating from an unsigned zone,
- from a zone not served by a security-aware name server, or for any
- DNS data which the resolver is only able to obtain through a
- recursive name server which is not security-aware. If there is a
- break in the authentication chain such that a security-aware resolver
- cannot obtain and validate the authentication keys it needs, then the
- security-aware resolver cannot validate the affected DNS data.
-
- This document briefly discusses other methods of adding security to a
- DNS query, such as using a channel secured by IPsec or using a DNS
- transaction authentication mechanism, but transaction security is not
- part of DNSSEC per se.
-
- A non-validating security-aware stub resolver, by definition, does
- not perform DNSSEC signature validation on its own, and thus is
- vulnerable both to attacks on (and by) the security-aware recursive
- name servers which perform these checks on its behalf and also to
- attacks on its communication with those security-aware recursive name
- servers. Non-validating security-aware stub resolvers should use some
- form of channel security to defend against the latter threat. The
- only known defense against the former threat would be for the
- security-aware stub resolver to perform its own signature validation,
- at which point, again by definition, it would no longer be a
- non-validating security-aware stub resolver.
-
- DNSSEC does not protect against denial of service attacks. DNSSEC
- makes DNS vulnerable to a new class of denial of service attacks
- based on cryptographic operations against security-aware resolvers
- and security-aware name servers, since an attacker can attempt to use
- DNSSEC mechanisms to consume a victim's resources. This class of
- attacks takes at least two forms. An attacker may be able to consume
- resources in a security-aware resolver's signature validation code by
- tampering with RRSIG RRs in response messages or by constructing
- needlessly complex signature chains. An attacker may also be able to
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 17]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
- consume resources in a security-aware name server which supports DNS
- dynamic update, by sending a stream of update messages that force the
- security-aware name server to re-sign some RRsets in the zone more
- frequently than would otherwise be necessary.
-
- DNSSEC introduces the ability for a hostile party to enumerate all
- the names in a zone by following the NSEC chain. NSEC RRs assert
- which names do not exist in a zone by linking from existing name to
- existing name along a canonical ordering of all the names within a
- zone. Thus, an attacker can query these NSEC RRs in sequence to
- obtain all the names in a zone. While not an attack on the DNS
- itself, this could allow an attacker to map network hosts or other
- resources by enumerating the contents of a zone. There are non-DNS
- protocol means of detecting and limiting this attack beyond the scope
- of this document set.
-
- DNSSEC introduces significant additional complexity to the DNS, and
- thus introduces many new opportunities for implementation bugs and
- misconfigured zones. In particular, enabling DNSSEC signature
- validation in a resolver may cause entire legitimate zones to become
- effectively unreachable due to DNSSEC configuration errors or bugs.
-
- DNSSEC does not provide confidentiality, due to a deliberate design
- choice.
-
- DNSSEC does not protect against tampering with unsigned zone data.
- Non-authoritative data at zone cuts (glue and NS RRs in the parent
- zone) are not signed. This does not pose a problem when validating
- the authentication chain, but does mean that the non-authoritative
- data itself is vulnerable to tampering during zone transfer
- operations. Thus, while DNSSEC can provide data origin
- authentication and data integrity for RRsets, it cannot do so for
- zones, and other mechanisms must be used to protect zone transfer
- operations.
-
- Please see [I-D.ietf-dnsext-dnssec-records] and
- [I-D.ietf-dnsext-dnssec-protocol] for additional security
- considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 18]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-12. Acknowledgements
-
- This document was created from the input and ideas of the members of
- the DNS Extensions Working Group. While explicitly listing everyone
- who has contributed during the decade during which DNSSEC has been
- under development would be an impossible task, the editors would
- particularly like to thank the following people for their
- contributions to and comments on this document set: Mark Andrews,
- Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney,
- Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael
- Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip
- Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf
- Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted
- Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson,
- Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik
- Rozendaal, Jakob Schlyter, Mike StJohns, Sam Weiler, and Brian
- Wellington.
-
- No doubt the above is an incomplete list. We apologize to anyone we
- left out.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 19]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
- [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
- [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
- Resource Record (RR)", RFC 3445, December 2002.
-
- [I-D.ietf-dnsext-dnssec-records]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "Resource Records for DNS Security Extensions",
- draft-ietf-dnsext-dnssec-records-07 (work in progress),
- February 2004.
-
- [I-D.ietf-dnsext-dnssec-protocol]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in
- progress), February 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 20]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-Informative References
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
- the Domain Name System (DNS)", RFC 2538, March 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
- Signing Authority", RFC 3008, November 2000.
-
- [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
- [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
- Authenticated Data (AD) bit", RFC 3655, November 2003.
-
- [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
- (RR)", RFC 3658, December 2003.
-
- [I-D.ietf-dnsext-dns-threats]
- Atkins, D. and R. Austein, "Threat Analysis Of The Domain
- Name System", draft-ietf-dnsext-dns-threats-05 (work in
- progress), November 2003.
-
- [I-D.ietf-dnsext-dnssec-2535typecode-change]
- Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 21]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
- (work in progress), December 2003.
-
- [I-D.ietf-dnsext-keyrr-key-signing-flag]
- Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
- Entry Point Flag",
- draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in
- progress), December 2003.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Rob Austein
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- EMail: sra@isc.org
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
- Dan Massey
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.edu
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 22]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-8920
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 23]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 24]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 25]
-\f
-
+++ /dev/null
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 16, 2004 M. Larson
- VeriSign
- R. Austein
- ISC
- D. Massey
- USC/ISI
- S. Rose
- NIST
- February 16, 2004
-
-
- Protocol Modifications for the DNS Security Extensions
- draft-ietf-dnsext-dnssec-protocol-05
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 16, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document is part of a family of documents which describe the DNS
- Security Extensions (DNSSEC). The DNS Security Extensions are a
- collection of new resource records and protocol modifications which
- add data origin authentication and data integrity to the DNS. This
- document describes the DNSSEC protocol modifications. This document
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 1]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- defines the concept of a signed zone, along with the requirements for
- serving and resolving using DNSSEC. These techniques allow a
- security-aware resolver to authenticate both DNS resource records and
- authoritative DNS error indications.
-
- This document obsoletes RFC 2535 and incorporates changes from all
- updates to RFC 2535.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Background and Related Documents . . . . . . . . . . . . . . 4
- 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
- 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
- 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
- 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6
- 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6
- 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7
- 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
- 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
- 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9
- 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10
- 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11
- 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11
- 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12
- 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14
- 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16
- 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17
- 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17
- 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19
- 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20
- 4.2 Signature Verification Support . . . . . . . . . . . . . . . 20
- 4.3 Determining Security Status of Data . . . . . . . . . . . . 21
- 4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 22
- 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 22
- 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22
- 4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 23
- 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24
- 4.8.1 Handling of the DO Bit . . . . . . . . . . . . . . . . . . . 24
- 4.8.2 Handling of the CD Bit . . . . . . . . . . . . . . . . . . . 24
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 2]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- 4.8.3 Handling of the AD Bit . . . . . . . . . . . . . . . . . . . 24
- 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 26
- 5.1 Special Considerations for Islands of Security . . . . . . . 27
- 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 27
- 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 28
- 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 29
- 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 30
- 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 31
- 5.3.4 Authenticating A Wildcard Expanded RRset Positive
- Response . . . . . . . . . . . . . . . . . . . . . . . . . . 32
- 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 32
- 5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 33
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 35
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
- Normative References . . . . . . . . . . . . . . . . . . . . 37
- Informative References . . . . . . . . . . . . . . . . . . . 38
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
- A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40
- B. Example Responses . . . . . . . . . . . . . . . . . . . . . 46
- B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
- B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 47
- B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 48
- B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 49
- B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 50
- B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 50
- B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 51
- B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 52
- C. Authentication Examples . . . . . . . . . . . . . . . . . . 54
- C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 54
- C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 54
- C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 55
- C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 55
- C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 55
- C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 55
- C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 56
- C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 56
- C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 56
- Intellectual Property and Copyright Statements . . . . . . . 57
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 3]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) are a collection of new resource
- records and protocol modifications which add data origin
- authentication and data integrity to the DNS. This document defines
- the DNSSEC protocol modifications. Section 2 of this document defines
- the concept of a signed zone and lists the requirements for zone
- signing. Section 3 describes the modifications to authoritative name
- server behavior necessary to handle signed zones. Section 4 describes
- the behavior of entities which include security-aware resolver
- functions. Finally, Section 5 defines how to use DNSSEC RRs to
- authenticate a response.
-
-1.1 Background and Related Documents
-
- The reader is assumed to be familiar with the basic DNS concepts
- described in RFC1034 [RFC1034] and RFC1035 [RFC1035].
-
- This document is part of a family of documents which define DNSSEC.
- An introduction to DNSSEC and definition of common terms can be found
- in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC
- resource records can be found in [I-D.ietf-dnsext-dnssec-records].
-
-1.2 Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119. [RFC2119].
-
-1.3 Editors' Notes
-
-1.3.1 Open Technical Issues
-
-1.3.2 Technical Changes or Corrections
-
- Please report technical corrections to dnssec-editors@east.isi.edu.
- To assist the editors, please indicate the text in error and point
- out the RFC that defines the correct behavior. For a technical
- change where no RFC that defines the correct behavior, or if there's
- more than one applicable RFC and the definitions conflict, please
- post the issue to namedroppers.
-
- An example correction to dnssec-editors might be: Page X says
- "DNSSEC RRs SHOULD be automatically returned in responses." This was
- true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
- DNSSEC RR types MUST NOT be included in responses unless the resolver
- indicated support for DNSSEC.
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 4]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-1.3.3 Typos and Minor Corrections
-
- Please report any typos corrections to dnssec-editors@east.isi.edu.
- To assist the editors, please provide enough context for us to find
- the incorrect text quickly.
-
- An example message to dnssec-editors might be: page X says "the
- DNSSEC standard has been in development for over 1 years". It
- should read "over 10 years".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 5]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-2. Zone Signing
-
- DNSSEC introduces the concept of signed zones. A signed zone
- includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
- the rules specified in Section 2.1, Section 2.2, Section 2.3 and
- Section 2.4, respectively. A zone that does not include these
- records according to the rules in this section is an unsigned zone.
-
- DNSSEC requires a change to the definition of the CNAME resource
- record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG
- and NSEC RRs to appear at the same owner name as a CNAME RR.
-
-2.1 Including DNSKEY RRs in a Zone
-
- To sign a zone, the zone's administrator generates one or more
- public/private key pairs and uses the private key(s) to sign
- authoritative RRsets in the zone. For each private key used to
- create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with
- the public component stored in the zone. A zone key DNSKEY RR MUST
- have the Zone Key bit of the flags RDATA field set to one -- see
- Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys
- associated with other DNS operations MAY be stored in DNSKEY RRs that
- are not marked as zone keys but MUST NOT be used to verify RRSIGs.
-
- If the zone is delegated and does not wish to act as an island of
- security, the zone MUST have at least one DNSKEY RR at the apex to
- act as a secure entry point into the zone. This DNSKEY would then be
- used to generate a DS RR at the delegating parent (see
- [I-D.ietf-dnsext-dnssec-records]).
-
- DNSKEY RRs MUST NOT appear at delegation points.
-
-2.2 Including RRSIG RRs in a Zone
-
- For each authoritative RRset in a signed zone, there MUST be at least
- one RRSIG record that meets all of the following requirements:
-
- o The RRSIG owner name is equal to the RRset owner name;
-
- o The RRSIG class is equal to the RRset class;
-
- o The RRSIG Type Covered field is equal to the RRset type;
-
- o The RRSIG Original TTL field is equal to the TTL of the RRset;
-
- o The RRSIG RR's TTL is equal to the TTL of the RRset;
-
- o The RRSIG Labels field is equal to the number of labels in the
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 6]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- RRset owner name, not counting the null root label and not
- counting the leftmost label if it is a wildcard;
-
- o The RRSIG Signer's Name field is equal to the name of the zone
- containing the RRset; and
-
- o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
- zone key DNSKEY record at the zone apex.
-
- The process for constructing the RRSIG RR for a given RRset is
- described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
- multiple RRSIG RRs associated with it.
-
- An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
- would add no value and would create an infinite loop in the signing
- process.
-
- The NS RRset that appears at the zone apex name MUST be signed, but
- the NS RRsets that appear at delegation points (that is, the NS
- RRsets in the parent zone that delegate the name to the child zone's
- name servers) MUST NOT be signed. Glue address RRsets associated with
- delegations MUST NOT be signed.
-
- There MUST be an RRSIG for each RRset using at least one DNSKEY of
- each algorithm in the parent zone's DS RRset and each additional
- algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset
- itself MUST be signed by each algorithm appearing in the DS RRset.
-
-2.3 Including NSEC RRs in a Zone
-
- Each owner name in the zone which has authoritative data or a
- delegation point NS RRset MUST have an NSEC resource record. The
- process for constructing the NSEC RR for a given name is described in
- [I-D.ietf-dnsext-dnssec-records].
-
- The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
- value field in the zone SOA RR.
-
- An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
- RRset at any particular owner name. That is, the signing process
- MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
- not the owner name of any RRset before the zone was signed.
-
- The type bitmap of every NSEC resource record in a signed zone MUST
- indicate the presence of both the NSEC record itself and its
- corresponding RRSIG record.
-
- The difference between the set of owner names that require RRSIG
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 7]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- records and the set of owner names that require NSEC records is
- subtle and worth highlighting. RRSIG records are present at the
- owner names of all authoritative RRsets. NSEC records are present at
- the owner names of all names for which the signed zone is
- authoritative and also at the owner names of delegations from the
- signed zone to its children. Neither NSEC nor RRSIG records are
- present (in the parent zone) at the owner names of glue address
- RRsets. Note, however, that this distinction is for the most part is
- only visible during the zone signing process, because NSEC RRsets are
- authoritative data, and are therefore signed, thus any owner name
- which has an NSEC RRset will have RRSIG RRs as well in the signed
- zone.
-
-2.4 Including DS RRs in a Zone
-
- The DS resource record establishes authentication chains between DNS
- zones. A DS RRset SHOULD be present at a delegation point when the
- child zone is signed. The DS RRset MAY contain multiple records,
- each referencing a public key in the child zone used to verify the
- RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS
- RRsets MUST NOT appear at a zone's apex.
-
- A DS RR SHOULD point to a DNSKEY RR which is present in the child's
- apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
- by the corresponding private key.
-
- The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
- (i.e., the NS RRset from the same zone containing the DS RRset).
-
- Construction of a DS RR requires knowledge of the corresponding
- DNSKEY RR in the child zone, which implies communication between the
- child and parent zones. This communication is an operational matter
- not covered by this document.
-
-2.5 Changes to the CNAME Resource Record.
-
- If a CNAME RRset is present at a name in a signed zone, appropriate
- RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
- name for secure dynamic update purposes is also allowed. Other types
- MUST NOT be present at that name.
-
- This is a modification to the original CNAME definition given in
- [RFC1034]. The original definition of the CNAME RR did not allow any
- other types to coexist with a CNAME record, but a signed zone
- requires NSEC and RRSIG RRs for every authoritative name. To resolve
- this conflict, this specification modifies the definition of the
- CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 8]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-2.6 Example of a Secure Zone
-
- Appendix A shows a complete example of a small signed zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 9]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-3. Serving
-
- This section describes the behavior of entities that include
- security-aware name server functions. In many cases such functions
- will be part of a security-aware recursive name server, but a
- security-aware authoritative name server has some of the same
- requirements as a security-aware recursive name server does.
- Functions specific to security-aware recursive name servers are
- described in Section 3.2; functions specific to authoritative servers
- are described in Section 3.1.
-
- The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
- are as used in [RFC1034].
-
- A security-aware name server MUST support the EDNS0 [RFC2671] message
- size extension, MUST support a message size of at least 1220 octets,
- and SHOULD support a message size of 4000 octets [RFC3226].
-
- A security-aware name server that receives a DNS query that does not
- include the EDNS OPT pseudo-RR or that has the DO bit set to zero
- MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
- RRset, and MUST NOT perform any of the additional processing
- described below. Since the DS RR type has the peculiar property of
- only existing in the parent zone at delegation points, DS RRs always
- require some special processing, as described in Section 3.1.4.1.
-
- DNSSEC allocates two new bits in the DNS message header: the CD
- (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
- is controlled by resolvers; a security-aware name server MUST copy
- the CD bit from a query into the corresponding response. The AD bit
- is controlled by name servers; a security-aware name server MUST
- ignore the setting of the AD bit in queries. See Section 3.1.6,
- Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details
- on the behavior of these bits.
-
-3.1 Authoritative Name Servers
-
- Upon receiving a relevant query that has the EDNS [RFC2671] OPT
- pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative
- name server for a signed zone MUST include additional RRSIG, NSEC,
- and DS RRs according to the following rules:
-
- o RRSIG RRs that can be used to authenticate a response MUST be
- included in the response according to the rules in Section 3.1.1;
-
- o NSEC RRs that can be used to provide authenticated denial of
- existence MUST be included in the response automatically according
- to the rules in Section 3.1.3;
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 10]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
- be included in referrals automatically according to the rules in
- Section 3.1.4.
-
- DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
- discusses zone transfer requirements.
-
-3.1.1 Including RRSIG RRs in a Response
-
- When responding to a query that has the DO bit set to one, a
- security-aware authoritative name server SHOULD attempt to send RRSIG
- RRs that a security-aware resolver can use to authenticate the RRsets
- in the response. Inclusion of RRSIG RRs in a response is subject to
- the following rules:
-
- o When placing a signed RRset in the Answer section, the name server
- MUST also place its RRSIG RRs in the Answer section. The RRSIG
- RRs have a higher priority for inclusion than any other RRsets
- that may need to be included. If space does not permit inclusion
- of these RRSIG RRs, the name server MUST set the TC bit.
-
- o When placing a signed RRset in the Authority section, the name
- server MUST also place its RRSIG RRs in the Authority section.
- The RRSIG RRs have a higher priority for inclusion than any other
- RRsets that may need to be included. If space does not permit
- inclusion of these RRSIG RRs, the name server MUST set the TC bit.
-
- o When placing a signed RRset in the Additional section, the name
- server MUST also place its RRSIG RRs in the Additional section.
- If space does not permit inclusion of both the RRset and its
- associated RRSIG RRs, the name server MUST NOT set the TC bit
- solely because these RRSIG RRs didn't fit.
-
-
-3.1.2 Including DNSKEY RRs In a Response
-
- When responding to a query that has the DO bit set to one and that
- requests the SOA or NS RRs at the apex of a signed zone, a
- security-aware authoritative name server for that zone MAY return the
- zone apex DNSKEY RRset in the Additional section. In this situation,
- the DNSKEY RRset and associated RRSIG RRs have lower priority than
- any other information that would be placed in the additional section.
- The name server SHOULD NOT include the DNSKEY RRset unless there is
- enough space in the response message for both the DNSKEY RRset and
- its associated RRSIG RR(s). If there is not enough space to include
- these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
- NOT set the TC bit solely because these RRs didn't fit (see Section
- 3.1.1).
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 11]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-3.1.3 Including NSEC RRs In a Response
-
- When responding to a query that has the DO bit set to one, a
- security-aware authoritative name server for a signed zone MUST
- include NSEC RRs in each of the following cases:
-
- No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
- but does not contain any RRsets that exactly match <SNAME, SCLASS,
- STYPE>.
-
- Name Error: The zone does not contain any RRsets that match <SNAME,
- SCLASS> either exactly or via wildcard name expansion.
-
- Wildcard Answer: The zone does not contain any RRsets that exactly
- match <SNAME, SCLASS> but does contain an RRset that matches
- <SNAME, SCLASS, STYPE> via wildcard name expansion.
-
- Wildcard No Data: The zone does not contain any RRsets that exactly
- match <SNAME, SCLASS>, does contain one or more RRsets that match
- <SNAME, SCLASS> via wildcard name expansion, but does not contain
- any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
- expansion.
-
- In each of these cases, the name server includes NSEC RRs in the
- response to prove that an exact match for <SNAME, SCLASS, STYPE> was
- not present in the zone and that the response that the name server is
- returning is correct given the data that are in the zone.
-
-3.1.3.1 Including NSEC RRs: No Data Response
-
- If the zone contains RRsets matching <SNAME, SCLASS> but contains no
- RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
- include the NSEC RR for <SNAME, SCLASS> along with its associated
- RRSIG RR(s) in the Authority section of the response (see Section
- 3.1.1). If space does not permit inclusion of the NSEC RR or its
- associated RRSIG RR(s), the name server MUST set the TC bit (see
- Section 3.1.1).
-
- Since the search name exists, wildcard name expansion does not apply
- to this query, and a single signed NSEC RR suffices to prove the
- requested RR type does not exist.
-
-3.1.3.2 Including NSEC RRs: Name Error Response
-
- If the zone does not contain any RRsets matching <SNAME, SCLASS>
- either exactly or via wildcard name expansion, then the name server
- MUST include the following NSEC RRs in the Authority section, along
- with their associated RRSIG RRs:
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 12]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- o An NSEC RR proving that there is no exact match for <SNAME,
- SCLASS>; and
-
- o An NSEC RR proving that the zone contains no RRsets that would
- match <SNAME, SCLASS> via wildcard name expansion.
-
- In some cases a single NSEC RR may prove both of these points, in
- that case the name server SHOULD only include the NSEC RR and its
- RRSIG RR(s) once in the Authority section.
-
- If space does not permit inclusion of these NSEC and RRSIG RRs, the
- name server MUST set the TC bit (see Section 3.1.1).
-
- The owner names of these NSEC and RRSIG RRs are not subject to
- wildcard name expansion when these RRs are included in the Authority
- section of the response.
-
- Note that this form of response includes cases in which SNAME
- corresponds to an empty non-terminal name within the zone (a name
- which is not the owner name for any RRset but which is the parent
- name of one or more RRsets).
-
-3.1.3.3 Including NSEC RRs: Wildcard Answer Response
-
- If the zone does not contain any RRsets which exactly match <SNAME,
- SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
- STYPE> via wildcard name expansion, the name server MUST include the
- wildcard-expanded answer and the corresponding wildcard-expanded
- RRSIG RRs in the Answer section, and MUST include in the Authority
- section an NSEC RR and associated RRSIG RR(s) proving that the zone
- does not contain a closer match for <SNAME, SCLASS>. If space does
- not permit inclusion of the answer, NSEC and RRSIG RRs, the name
- server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.4 Including NSEC RRs: Wildcard No Data Response
-
- This case is a combination of the previous cases. The zone does not
- contain an exact match for <SNAME, SCLASS>, and while the zone does
- contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
- none of those RRsets match STYPE. The name server MUST include the
- following NSEC RRs in the Authority section, along with their
- associated RRSIG RRs:
-
- o An NSEC RR proving that there are no RRsets matching STYPE at the
- wildcard owner name which matched <SNAME, SCLASS> via wildcard
- expansion; and
-
- o An NSEC RR proving that there are no RRsets in the zone which
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 13]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- would have been a closer match for <SNAME, SCLASS>.
-
- In some cases a single NSEC RR may prove both of these points, in
- which case the name server SHOULD only include the NSEC RR and its
- RRSIG RR(s) once in the Authority section.
-
- The owner names of these NSEC and RRSIG RRs are not subject to
- wildcard name expansion when these RRs are included in the Authority
- section of the response.
-
- If space does not permit inclusion of these NSEC and RRSIG RRs, the
- name server MUST set the TC bit (see Section 3.1.1).
-
-3.1.3.5 Finding The Right NSEC RRs
-
- As explained above, there are several situations in which a
- security-aware authoritative name server needs to locate an NSEC RR
- which proves that a particular SNAME does not exist. Locating such
- an NSEC RR within an authoritative zone is relatively simple, at
- least in concept. The following discussion assumes that the name
- server is authoritative for the zone which would have held the
- nonexistent SNAME. The algorithm below is written for clarity, not
- efficiency.
-
- To find the NSEC which proves that name N does not exist in the zone
- Z which would have held it, construct sequence S consisting of every
- name in Z, sorted into canonical order
- [I-D.ietf-dnsext-dnssec-records]. Find the name M which would have
- immediately preceded N in S if N had existed. M is the owner name of
- the NSEC RR which proves that N does not exist.
-
- The algorithm for finding the NSEC RR which proves that a given name
- is not covered by any applicable wildcard is similar, but requires an
- extra step. More precisely, the algorithm for finding the NSEC
- proving that the applicable wildcard name does not exist is precisely
- the same as the algorithm for finding the NSEC RR which proves that
- any other name does not exist: the part that's missing is how to
- determine the name of the nonexistent applicable wildcard. In
- practice, this is easy, because the authoritative name server has
- already checked for the presence of precisely this wildcard name as
- part of step (1)(c) of the normal lookup algorithm described in
- Section 4.3.2 of [RFC1034].
-
-3.1.4 Including DS RRs In a Response
-
- When responding to a query which has the DO bit set to one, a
- security-aware authoritative name server returning a referral
- includes DNSSEC data along with the NS RRset.
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 14]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- If a DS RRset is present at the delegation point, the name server
- MUST return both the DS RRset and its associated RRSIG RR(s) in the
- Authority section along with the NS RRset. The name server MUST
- place the NS RRset before the DS RRset and its associated RRSIG
- RR(s).
-
- If no DS RRset is present at the delegation point, the name server
- MUST return both the NSEC RR which proves that the DS RRset is not
- present and the NSEC RR's associated RRSIG RR(s) along with the NS
- RRset. The name server MUST place the NS RRset before the NSEC RRset
- and its associated RRSIG RR(s).
-
- Including these DS, NSEC, and RRSIG RRs increases the size of
- referral messages, and may cause some or all glue RRs to be omitted.
- If space does not permit inclusion of the DS or NSEC RRset and
- associated RRSIG RRs, the name server MUST set the TC bit (see
- Section 3.1.1).
-
-3.1.4.1 Responding to Queries for DS RRs
-
- The DS resource record type is unusual in that it appears only on the
- parent zone's side of a zone cut. For example, the DS RRset for the
- delegation of "foo.example" is stored in the "example" zone rather
- than in the "foo.example" zone. This requires special processing
- rules for both name servers and resolvers, since the name server for
- the child zone is authoritative for the name at the zone cut by the
- normal DNS rules but the child zone does not contain the DS RRset.
-
- A security-aware resolver sends queries to the parent zone when
- looking for a needed DS RR at a delegation point (see Section 4.2).
- However, special rules are necessary to avoid confusing
- security-oblivious resolvers which might become involved in
- processing such a query (for example, in a network configuration that
- forces a security-aware resolver to channel its queries through a
- security-oblivious recursive name server). The rest of this section
- describes how a security-aware name server processes DS queries in
- order to avoid this problem.
-
- The need for special processing by a security-aware name server only
- arises when all the following conditions are met:
-
- o the name server has received a query for the DS RRset at a zone
- cut; and
-
- o the name server is authoritative for the child zone; and
-
- o the name server is not authoritative for the parent zone; and
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 15]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- o the name server does not offer recursion.
-
- In all other cases, the name server either has some way of obtaining
- the DS RRset or could not have been expected to have the DS RRset
- even by the pre-DNSSEC processing rules, so the name server can
- return either the DS RRset or an error response according to the
- normal processing rules.
-
- If all of the above conditions are met, however, the name server is
- authoritative for SNAME but cannot supply the requested RRset. In
- this case, the name server MUST return an authoritative "no data"
- response showing that the DS RRset does not exist in the child zone's
- apex. See Appendix B.8 for an example of such a response.
-
-3.1.5 Responding to Queries for Type AXFR or IXFR
-
- DNSSEC does not change the DNS zone transfer process. A signed zone
- will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
- records have no special meaning with respect to a zone transfer
- operation, and these RRs are treated as any other resource record
- type.
-
- An authoritative name server is not required to verify that a zone is
- properly signed before sending or accepting a zone transfer.
- However, an authoritative name server MAY choose to reject the entire
- zone transfer if the zone fails meets any of the signing requirements
- described in Section 2. The primary objective of a zone transfer is
- to ensure that all authoritative name servers have identical copies
- of the zone. An authoritative name server which chooses to perform
- its own zone validation MUST NOT selectively reject some RRs and
- accept others.
-
- DS RRsets appear only on the parental side of a zone cut and are
- authoritative data in the parent zone. As with any other
- authoritative RRset, the DS RRset MUST be included in zone transfers
- of the zone in which the RRset is authoritative data: in the case of
- the DS RRset, this is the parent zone.
-
- NSEC RRs appear in both the parent and child zones at a zone cut, and
- are authoritative data in both the parent and child zones. The
- parental and child NSEC RRs at a zone cut are never identical to each
- other, since the NSEC RR in the child zone's apex will always
- indicate the presence of the child zone's SOA RR while the parental
- NSEC RR at the zone cut will never indicate the presence of an SOA
- RR. As with any other authoritative RRs, NSEC RRs MUST be included
- in zone transfers of the zone in which they are authoritative data:
- the parental NSEC RR at a zone cut MUST be included zone transfers of
- the parent zone, while the NSEC at the zone apex of the child zone
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 16]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- MUST be included in zone transfers of the child zone.
-
- RRSIG RRs appear in both the parent and child zones at a zone cut,
- and are authoritative in whichever zone contains the authoritative
- RRset for which the RRSIG RR provides the signature. That is, the
- RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
- authoritative in the parent zone, while the RRSIG for any RRset in
- the child zone's apex will be authoritative in the child zone. As
- with any other authoritative RRs, RRSIG RRs MUST be included in zone
- transfers of the zone in which they are authoritative data.
-
-3.1.6 The AD and CD Bits in an Authoritative Response
-
- The CD and AD bits are designed to be used in communication between
- security-aware resolvers and security-aware recursive name servers.
- This bits are for the most part not relevant to query processing by
- security-aware authoritative name servers.
-
- Since a security-aware name server does not perform signature
- validation for authoritative data during query processing even when
- the CD bit is set to zero, a security-aware name server SHOULD ignore
- the setting of the CD bit when composing an authoritative response.
-
- A security-aware name server MUST NOT set the AD bit in a response
- unless the name server considers all RRsets in the Answer and
- Authority sections of the response to be authentic. A security-aware
- name server's local policy MAY consider data from an authoritative
- zone to be authentic without further validation, but the name server
- MUST NOT do so unless the name server obtained the authoritative zone
- via secure means (such as a secure zone transfer mechanism), and MUST
- NOT do so unless this behavior has been configured explicitly.
-
- A security-aware name server which supports recursion MUST follow the
- rules for the CD and AD bits given in Section 3.2 when generating a
- response that involves data obtained via recursion.
-
-3.2 Recursive Name Servers
-
- As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
- recursive name server is an entity which acts in both the
- security-aware name server and security-aware resolver roles. This
- section uses the terms "name server side" and "resolver side" to
- refer to the code within a security-aware recursive name server which
- implements the security-aware name server role and the code which
- implements the security-aware resolver role, respectively.
-
- The resolver side follows the usual rules for caching and negative
- caching which would apply to any security-aware resolver.
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 17]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-3.2.1 The DO bit
-
- The resolver side of a security-aware recursive name server MUST set
- the DO bit when sending requests, regardless of the state of the DO
- bit in the initiating request received by the name server side. If
- the DO bit in an initiating query is not set, the name server side
- MUST strip any authenticating DNSSEC RRs from the response, but MUST
- NOT strip any DNSSEC RRs that the initiating query explicitly
- requested.
-
-3.2.2 The CD bit
-
- The CD bit exists in order to allow a security-aware resolver to
- disable signature validation in a security-aware name server's
- processing of a particular query.
-
- The name server side MUST copy the setting of the CD bit from a query
- to the corresponding response.
-
- The name server side of a security-aware recursive name server MUST
- pass the sense of the CD bit to the resolver side along with the rest
- of an initiating query, so that the resolver side will know whether
- or not it is required to verify the response data it returns to the
- name server side. If the CD bit is set to one, it indicates that the
- originating resolver is willing to perform whatever authentication
- its local policy requires, thus the resolver side of the recursive
- name server need not perform authentication on the RRsets in the
- response. When the CD bit is set to one the recursive name server
- SHOULD, if possible, return the requested data to the originating
- resolver even if the recursive name server's local authentication
- policy would reject the records in question. That is, by setting the
- CD bit, the originating resolver has indicated that it takes
- responsibility for performing its own authentication, and the
- recursive name server should not interfere.
-
- If the resolver side implements a BAD cache (see Section 4.7) and the
- name server side receives a query which matches an entry in the
- resolver side's BAD cache, the name server side's response depends on
- the sense of the CD bit in the original query. If the CD bit is set,
- the name server side SHOULD return the data from the BAD cache; if
- the CD bit is not set, the name server side MUST return RCODE 2
- (server failure).
-
-3.2.3 The AD bit
-
- The name server side of a security-aware recursive name server MUST
- NOT set the AD bit in a response unless the name server considers all
- RRsets in the Answer and Authority sections of the response to be
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 18]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- authentic, and SHOULD set the AD bit if and only if the resolver side
- considers all RRsets in the Answer section and any relevant negative
- response RRs in the Authority section to be authentic. The resolver
- side MUST follow the procedure described in Section 5 to determine
- whether the RRs in question are authentic.
-
-3.3 Example DNSSEC Responses
-
- See Appendix B for example response packets.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 19]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-4. Resolving
-
- This section describes the behavior of entities which include
- security-aware resolver functions. In many cases such functions will
- be part of a security-aware recursive name server, but a stand-alone
- security-aware resolver has many of the same requirements. Functions
- specific to security-aware recursive name servers are described in
- Section 3.2.
-
-4.1 EDNS Support
-
- A security-aware resolver MUST include an EDNS [RFC2671] OPT
- pseudo-RR with the DO [RFC3225] bit set to one when sending queries.
-
- A security-aware resolver MUST support a message size of at least
- 1220 octets, SHOULD support a message size of 4000 octets, and MUST
- advertise the supported message size using the "sender's UDP payload
- size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST
- handle fragmented UDP packets correctly regardless of whether any
- such fragmented packets were received via IPv4 or IPv6. Please see
- [RFC3226] for discussion of these requirements.
-
-4.2 Signature Verification Support
-
- A security-aware resolver MUST support the signature verification
- mechanisms described in Section 5, and MUST apply them to every
- received response except when:
-
- o The security-aware resolver is part of a security-aware recursive
- name server, and the response is the result of recursion on behalf
- of a query received with the CD bit set;
-
- o The response is the result of a query generated directly via some
- form of application interface which instructed the security-aware
- resolver not to perform validation for this query; or
-
- o Validation for this query has been disabled by local policy.
-
- A security-aware resolver's support for signature verification MUST
- include support for verification of wildcard owner names.
-
- Editors' note: The rest of this section is expected to change once
- the WG reaches closure on Q-23.
-
- A security-aware resolver MUST attempt to retrieve missing DS,
- DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these
- RRs in order to perform signature verification.
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 20]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- A security-aware resolver MUST attempt to retrieve a missing NSEC RR
- which the resolver needs to authenticate a NODATA response. In
- general it is not possible for a resolver to retrieve missing NSEC
- RRs, since the resolver will have no way of knowing the owner name of
- the missing NSEC RR, but in the specific case of a NODATA response,
- the resolver may know the name of the missing NSEC RR, and in such
- cases must therefore attempt to retrieve it.
-
- When attempting to retrieve missing NSEC RRs which reside on the
- parental side at a zone cut, a security-aware iterative-mode resolver
- MUST query the name servers for the parent zone, not the child zone.
-
- When attempting to retrieve a missing DS, a security-aware
- iterative-mode resolver MUST query the name servers for the parent
- zone, not the child zone. As explained in Section 3.1.4.1,
- security-aware name servers need to apply special processing rules to
- handle the DS RR, and in some situations the resolver may also need
- to apply special rules to locate the name servers for the parent zone
- if the resolver does not already have the parent's NS RRset. To
- locate the parent NS RRset, the resolver can start with the
- delegation name, strip off the leftmost label, and query for an NS
- RRset by that name; if no NS RRset is present at that name, the
- resolver then strips of the leftmost remaining label and retries the
- query for that name, repeating this process of walking up the tree
- until it either finds the NS RRset or runs out of labels.
-
- Editors' note: This algorithm could easily be read as an
- invitation to careless implementors to hammer the root zone
- servers. Better wording would be welcome.
-
-
-4.3 Determining Security Status of Data
-
- Editors' note: This section is waiting for resolution of Q-28.
-
- A security-aware resolver MUST be able to determine whether or not it
- should expect a particular RRset to be signed. More precisely, a
- security-aware resolver must be able to distinguish between three
- cases:
-
- 1. An RRset for which the resolver is able to build a chain of
- signed DNSKEY and DS RRs from a trusted security anchor to the
- RRset. In this case, the RRset should be signed, and is subject
- to signature validation as described above.
-
- 2. An RRset for which the resolver knows that it has no chain of
- signed DNSKEY and DS RRs from any trusted starting point to the
- RRset. This can occur when the target RRset lies in an unsigned
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 21]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- zone or in a descendent of an unsigned zone. In this case, the
- RRset may or may not be signed, but the resolver will not be able
- to verify the signature.
-
- 3. An RRset for which the resolver is not able to determine whether
- or not the RRset should be signed, because the resolver is not
- able to obtain the necessary DNSSEC RRs. This can occur when the
- security-aware resolver is not able to contact security-aware
- name servers for the relevant zones.
-
-
-4.4 Preconfigured Public Keys
-
- A security-aware resolver MUST be capable of being preconfigured with
- at least one trusted public key or DS RR, and SHOULD be capable of
- being preconfigured with multiple trusted public keys or DS RRs.
- Since a security-aware resolver will not be able to validate
- signatures without such a preconfigured trusted key, the resolver
- SHOULD have some reasonably robust mechanism for obtaining such keys
- when it boots; examples of such a mechanism would be some form of
- non-volatile storage (such as a disk drive) or some form of trusted
- local network configuration mechanism.
-
-4.5 Response Caching
-
- Editors' note: RIPE "last call" workshop felt that the WG needs to
- reexamine and discuss this section.
-
- A security-aware resolver SHOULD cache each response as a single
- atomic entry containing the entire answer, including the named RRset
- and any associated DNSSEC RRs. The resolver SHOULD discard the
- entire atomic entry when any of the RRs contained in it expire. In
- most cases the appropriate cache index for the atomic entry will be
- the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
- form described in Section 3.1.3.2 the appropriate cache index will be
- the double <QNAME,QCLASS>.
-
-4.6 Handling of the CD and AD bits
-
- A security-aware resolver MAY set the CD bit in a query to one in
- order to indicate that the resolver takes responsibility for
- performing whatever authentication its local policy requires on the
- RRsets in the response. See Section 3.2 for the effect this bit has
- on the behavior of security-aware recursive name servers.
-
- A security-aware resolver MUST zero the AD bit when composing query
- messages to protect against buggy name servers which blindly copy
- header bits which they do not understand from the query message to
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 22]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- the response message.
-
- A resolver MUST disregard the meaning of the CD and AD bits in a
- response unless the response was obtained using a secure channel or
- the resolver was specifically configured to regard the message header
- bits without using a secure channel.
-
-4.7 Rate Limiting
-
- A security-aware resolver SHOULD NOT cache data with invalid
- signatures under normal circumstances. However, a security-aware
- resolver SHOULD take steps to rate limit the number of identical
- queries that it generates if signature validation of the responses
- fails repeatedly.
-
- Conceptually, this is similar in some respects to negative caching
- [RFC2308], but since the resolver has no way of obtaining an
- appropriate caching TTL from received data in this case, the TTL will
- have to be set by the implementation. This document refers to the
- data retained as part of such a rate limiting mechanism as the "BAD
- cache".
-
- A security-aware resolver MAY chose to retain RRsets for which
- signature validation has failed in its BAD cache, but MUST NOT return
- such RRsets from its BAD cache unless both of the following
- conditions are met:
-
- o The resolver has recently generated enough queries identical to
- this one that the resolver is suppressing queries for this <QNAME,
- QTYPE, QCLASS>; and
-
- o The resolver is not required to validate the signatures of the
- RRsets in question under the rules given in Section 4 of this
- document.
-
- The intent of the above rule is to provide the raw data to clients
- which are capable of performing their own signature verification
- checks while protecting clients which depend on this resolver to
- perform such checks. Several of the possible reasons why signature
- validation might fail involve conditions which may not apply equally
- to this resolver and the client which invoked it: for example, this
- resolver's clock may be set incorrectly, or the client may have
- knowledge of a relevant island of security which this resolver does
- not share. In such cases, "protecting" a client which is capable of
- performing its own signature validation from ever seeing the "bad"
- data does not help the client.
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 23]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-4.8 Stub resolvers
-
- A security-aware stub resolver MUST support the DNSSEC RR types, at
- least to the extent of not mishandling responses just because they
- contain DNSSEC RRs.
-
-4.8.1 Handling of the DO Bit
-
- A non-validating security-aware stub resolver MAY include the DNSSEC
- RRs returned by a security-aware recursive name server as part of the
- data that the stub resolver hands back to the application which
- invoked it but is not required to do so. A non-validating stub
- resolver that wishes to do this will need to set the DO bit in
- receive DNSSEC RRs from the recursive name server.
-
- A validating security-aware stub resolver MUST set the DO bit, since
- otherwise it will not receive the DNSSEC RRs it needs to perform
- signature validation.
-
-4.8.2 Handling of the CD Bit
-
- A non-validating security-aware stub resolver SHOULD NOT set the CD
- bit when sending queries unless requested by the application layer,
- since by definition, a non-validating stub resolver depends on the
- security-aware recursive name server to perform validation on its
- behalf.
-
- A validating security-aware stub resolver SHOULD set the CD bit,
- since otherwise the security-aware recursive name server will answer
- the query using the name server's local policy, which may prevent the
- stub resolver from receiving data which would be acceptable to the
- stub resolver's local policy.
-
-4.8.3 Handling of the AD Bit
-
- A non-validating security-aware stub resolver MAY chose to examine
- the setting of the AD bit in response messages that it receives in
- order to determine whether the security-aware recursive name server
- which sent the response claims to have cryptographically verified the
- data in the Answer and Authority sections of the response message.
- Note, however, that the responses received by a security-aware stub
- resolver are heavily dependent on the local policy of the
- security-aware recursive name server, so as a practical matter there
- may be little practical value to checking the status of the AD bit
- except perhaps as a debugging aid. In any case, a security-aware
- stub resolver MUST NOT place any reliance on signature validation
- allegedly performed on its behalf except when the security-aware stub
- resolver obtained the data in question from a trusted security-aware
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 24]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- recursive name server via a secure channel.
-
- A validating security-aware stub resolver SHOULD NOT examine the
- setting of the AD bit in response messages, since, by definition, the
- stub resolver performs its own signature validation regardless of the
- setting of the AD bit.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 25]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-5. Authenticating DNS Responses
-
- In order to use DNSSEC RRs for authentication, a security-aware
- resolver requires preconfigured knowledge of at least one
- authenticated DNSKEY or DS RR. The process for obtaining and
- authenticating this initial DNSKEY or DS RR is achieved via some
- external mechanism. For example, a resolver could use some off-line
- authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR
- that identifies and authenticates a zone's DNSKEY RR. The remainder
- of this section assumes that the resolver has somehow obtained an
- initial set of authenticated DNSKEY RRs.
-
- An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
- RRset. To authenticate an apex DNSKEY RRset using an initial key,
- the resolver MUST:
-
- 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY
- RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
- (DNSKEY RDATA bit 7) set to one.
-
- 2. Verify that there is some RRSIG RR that covers the apex DNSKEY
- RRset, and that the combination of the RRSIG RR and the initial
- DNSKEY RR authenticates the DNSKEY RRset. The process for using
- an RRSIG RR to authenticate an RRset is described in Section 5.3.
-
- Once the resolver has authenticated the apex DNSKEY RRset using an
- initial DNSKEY RR, delegations from that zone can be authenticated
- using DS RRs. This allows a resolver to start from an initial key,
- and use DS RRsets to proceed recursively down the DNS tree obtaining
- other apex DNSKEY RRsets. If the resolver were preconfigured with a
- root DNSKEY RR, and if every delegation had a DS RR associated with
- it, then the resolver could obtain and validate any apex DNSKEY
- RRset. The process of using DS RRs to authenticate referrals is
- described in Section 5.2.
-
- Once the resolver has authenticated a zone's apex DNSKEY RRset,
- Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
- DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
- RRsets in the zone. Section 5.4 shows how the resolver can use
- authenticated NSEC RRsets from the zone to prove that an RRset is not
- present in the zone.
-
- When a resolver indicates support for DNSSEC (by setting the DO bit),
- a security-aware name server should attempt to provide the necessary
- DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
- However, a security-aware resolver may still receive a response that
- that lacks the appropriate DNSSEC RRs, whether due to configuration
- issues such as a security-oblivious recursive name server that
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 26]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- accidentally interfere with DNSSEC RRs or due to a deliberate attack
- in which an adversary forges a response, strips DNSSEC RRs from a
- response, or modifies a query so that DNSSEC RRs appear not to be
- requested. The absence of DNSSEC data in a response MUST NOT by
- itself be taken as an indication that no authentication information
- exists.
-
- A resolver SHOULD expect authentication information from signed
- zones. A resolver SHOULD believe that a zone is signed if the
- resolver has been configured with public key information for the
- zone, or if the zone's parent is signed and the delegation from the
- parent contains a DS RRset.
-
-5.1 Special Considerations for Islands of Security
-
- Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
- zones for which it is not possible to construct an authentication
- chain to the zone from its parent. Validating signatures within an
- island of security requires the validator to have some other means of
- obtaining an initial authenticated zone key for the island. If a
- validator cannot obtain such a key, it will have to choose whether to
- accept the unvalidated responses or not based on local policy.
-
- All the normal processes for validating responses apply to islands of
- security. The only difference between normal validation and
- validation within an island of security is in how the validator
- obtains a starting point for the authentication chain.
-
-5.2 Authenticating Referrals
-
- Once the apex DNSKEY RRset for a signed parent zone has been
- authenticated, DS RRsets can be used to authenticate the delegation
- to a signed child zone. A DS RR identifies a DNSKEY RR in the child
- zone's apex DNSKEY RRset, and contains a cryptographic digest of the
- child zone's DNSKEY RR. A strong cryptographic digest algorithm
- ensures that an adversary can not easily generate a DNSKEY RR that
- matches the digest. Thus, authenticating the digest allows a
- resolver to authenticate the matching DNSKEY RR. The resolver can
- then use this child DNSKEY RR to authenticate the entire child apex
- DNSKEY RRset.
-
- Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
- can be authenticated if all of the following hold:
-
- o The DS RR has been authenticated using some DNSKEY RR in the
- parent's apex DNSKEY RRset (see Section 5.3);
-
- o The Algorithm and Key Tag in the DS RR match the Algorithm field
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 27]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
- RRset that, when hashed using the digest algorithm specified in
- the DS RR's Digest Type field, results in a digest value that
- matches the Digest field of the DS RR; and
-
- o The matching DNSKEY RR in the child zone has the Zone Flag bit set
- to one, the corresponding private key has signed the child zone's
- apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
- child zone's apex DNSKEY RRset.
-
- If the referral from the parent zone did not contain a DS RRset, the
- response should have included a signed NSEC RRset proving that no DS
- RRset exists for the delegated name (see Section 3.1.4). A
- security-aware resolver MUST query the name servers for the parent
- zone for the DS RRset if the referral includes neither a DS RRset nor
- a NSEC RRset proving that the DS RRset does not exist (see Section
- 4).
-
- If the resolver authenticates an NSEC RRset that proves that no DS
- RRset is present for this zone, then there is no authentication path
- leading from the parent to the child. If the resolver has an initial
- DNSKEY or DS RR that belongs to the child zone or to any delegation
- below the child zone, this initial DNSKEY or DS RR MAY be used to
- re-establish an authentication path. If no such initial DNSKEY or DS
- RR exists, the resolver can not authenticate RRsets in or below the
- child zone.
-
- Note that, for a signed delegation, there are two NSEC RRs associated
- with the delegated name. One NSEC RR resides in the parent zone, and
- can be used to prove whether a DS RRset exists for the delegated
- name. The second NSEC RR resides in the child zone, and identifies
- which RRsets are present at the apex of the child zone. The parent
- NSEC RR and child NSEC RR can always be distinguished, since the SOA
- bit will be set in the child NSEC RR and clear in the parent NSEC RR.
- A security-aware resolver MUST use the parent NSEC RR when attempting
- to prove that a DS RRset does not exist.
-
- If the resolver does not support any of the algorithms listed in an
- authenticated DS RRset, then the resolver will not be able to verify
- the authentication path to the child zone. In this case, the
- resolver SHOULD treat the child zone as if it were unsigned.
-
-5.3 Authenticating an RRset Using an RRSIG RR
-
- A resolver can use an RRSIG RR and its corresponding DNSKEY RR to
- attempt to authenticate RRsets. The resolver first checks the RRSIG
- RR to verify that it covers the RRset, has a valid time interval, and
- identifies a valid DNSKEY RR. The resolver then constructs the
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 28]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- canonical form of the signed data by appending the RRSIG RDATA
- (excluding the Signature Field) with the canonical form of the
- covered RRset. Finally, resolver uses the public key and signature
- to authenticate the signed data. Section 5.3.1, Section 5.3.2, and
- Section 5.3.3 describe each step in detail.
-
-5.3.1 Checking the RRSIG RR Validity
-
- A security-aware resolver can use an RRSIG RR to authenticate an
- RRset if all of the following conditions hold:
-
- o The RRSIG RR and the RRset MUST have the same owner name and the
- same class;
-
- o The RRSIG RR's Signer's Name field MUST be the name of the zone
- that contains the RRset;
-
- o The RRSIG RR's Type Covered field MUST equal the RRset's type;
-
- o The number of labels in the RRset owner name MUST be greater than
- or equal to the value in the RRSIG RR's Labels field;
-
- o The resolver's notion of the current time MUST be less than or
- equal to the time listed in the RRSIG RR's Expiration field;
-
- o The resolver's notion of the current time MUST be greater than or
- equal to the time listed in the RRSIG RR's Inception field;
-
- o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
- match the owner name, algorithm, and key tag for some DNSKEY RR in
- the zone's apex DNSKEY RRset;
-
- o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
- RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
- set to one.
-
- It is possible for more than one DNSKEY RR to match the conditions
- above. In this case, the resolver can not predetermine which DNSKEY
- RR to use to authenticate the signature, MUST try each matching
- DNSKEY RR until the resolver has either validated the signature or
- has run out of matching public keys to try.
-
- Note that this authentication process is only meaningful if the
- resolver authenticates the DNSKEY RR before using it to validate
- signatures. The matching DNSKEY RR is considered to be authentic if:
-
- o The apex DNSKEY RRset containing the DNSKEY RR is considered
- authentic; or
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 29]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
- and the DNSKEY RR either matches an authenticated DS RR from the
- parent zone or matches a DS RR or DNSKEY RR that the resolver has
- been preconfigured to believe to be authentic.
-
-
-5.3.2 Reconstructing the Signed Data
-
- Once the RRSIG RR has met the validity requirements described in
- Section 5.3.1, the resolver needs to reconstruct the original signed
- data. The original signed data includes RRSIG RDATA (excluding the
- Signature field) and the canonical form of the RRset. Aside from
- being ordered, the canonical form of the RRset might also differ from
- the received RRset due to DNS name compression, decremented TTLs, or
- wildcard expansion. The resolver should use the following to
- reconstruct the original signed data:
-
- signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
-
- "|" denotes concatenation
-
- RRSIG_RDATA is the wire format of the RRSIG RDATA fields
- with the Signature field excluded and the Signer's Name
- in canonical form.
-
- RR(i) = name | class | type | OrigTTL | RDATA length | RDATA
-
- name is calculated according to the function below
-
- class is the RRset's class
-
- type is the RRset type and all RRs in the class
-
- OrigTTL is the value from the RRSIG Original TTL field
-
- All names in the RDATA field are in canonical form
-
- The set of all RR(i) is sorted into canonical order.
-
- To calculate the name:
- let rrsig_labels = the value of the RRSIG Labels field
-
- let fqdn = RRset's fully qualified domain name in
- canonical form
-
- let fqdn_labels = Label count of the fqdn above.
-
- if rrsig_labels = fqdn_labels,
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 30]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- name = fqdn
-
- if rrsig_labels < fqdn_labels,
- name = "*." | the rightmost rrsig_label labels of the
- fqdn
-
- if rrsig_labels > fqdn_labels
- the RRSIG RR did not pass the necessary validation
- checks and MUST NOT be used to authenticate this
- RRset.
-
- The canonical forms for names and RRsets are defined in
- [I-D.ietf-dnsext-dnssec-records].
-
- NSEC RRsets at a delegation boundary require special processing.
- There are two distinct NSEC RRsets associated with a signed delegated
- name. One NSEC RRset resides in the parent zone, and specifies which
- RRset are present at the parent zone. The second NSEC RRset resides
- at the child zone, and identifies which RRsets are present at the
- apex in the child zone. The parent NSEC RRset and child NSEC RRset
- can always be distinguished since only the child NSEC RRs will
- specify an SOA RRset exists at the name. When reconstructing the
- original NSEC RRset for the delegation from the parent zone, the NSEC
- RRs MUST NOT be combined with NSEC RRs from the child zone, and when
- reconstructing the original NSEC RRset for the apex of the child
- zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
- zone.
-
- Note also that each of the two NSEC RRsets at a delegation point has
- a corresponding RRSIG RR with an owner name matching the delegated
- name, and each of these RRSIG RRs is authoritative data associated
- with the same zone that contains the corresponding NSEC RRset. If
- necessary, a resolver can tell these RRSIG RRs apart by checking the
- Signer's Name field.
-
-5.3.3 Checking the Signature
-
- Once the resolver has validated the RRSIG RR as described in Section
- 5.3.1 and reconstructed the original signed data as described in
- Section 5.3.2, the resolver can attempt to use the cryptographic
- signature to authenticate the signed data, and thus (finally!)
- authenticate the RRset.
-
- The Algorithm field in the RRSIG RR identifies the cryptographic
- algorithm used to generate the signature. The signature itself is
- contained in the Signature field of the RRSIG RDATA, and the public
- key used to verify the signature is contained in the Public Key field
- of the matching DNSKEY RR(s) (found in Section 5.3.1).
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 31]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
- and provides pointers to the documents that define each algorithm's
- use.
-
- Note that it is possible for more than one DNSKEY RR to match the
- conditions in Section 5.3.1. In this case, the resolver can only
- determine which DNSKEY RR by trying each matching public key until
- the resolver either succeeds in validating the signature or runs out
- of keys to try.
-
- If the Labels field of the RRSIG RR is not equal to the number of
- labels in the RRset's fully qualified owner name, then the RRset is
- either invalid or the result of wildcard expansion. The resolver
- MUST verify that wildcard expansion was applied properly before
- considering the RRset to be authentic. Section 5.3.4 describes how
- to determine whether a wildcard was applied properly.
-
- If other RRSIG RRs also cover this RRset, the local resolver security
- policy determines whether the resolver also needs to test these RRSIG
- RRs, and determines how to resolve conflicts if these RRSIG RRs lead
- to differing results.
-
- If the resolver accepts the RRset as authentic, the resolver MUST set
- the TTL of the RRSIG RR and each RR in the authenticated RRset to a
- value no greater than the minimum of:
-
- o The RRset's TTL as received in the response;
-
- o The RRSIG RR's TTL as received in the response; and
-
- o The value in the RRSIG RR's Original TTL field.
-
-
-5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
-
- If the number of labels in an RRset's owner name is greater than the
- Labels field of the covering RRSIG RR, then the RRset and its
- covering RRSIG RR were created as a result of wildcard expansion.
- Once the resolver has verified the signature as described in Section
- 5.3, the resolver must take additional steps to verify the
- non-existence of an exact match or closer wildcard match for the
- query. Section 5.4 discusses these steps.
-
- Note that the response received by the resolver should include all
- NSEC RRs needed to authenticate the response (see Section 3.1.3).
-
-5.4 Authenticated Denial of Existence
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 32]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- A resolver can use authenticated NSEC RRs to prove that an RRset is
- not present in a signed zone. Security-aware name servers should
- automatically include any necessary NSEC RRs for signed zones in
- their responses to security-aware resolvers.
-
- Security-aware resolvers MUST first authenticate NSEC RRsets
- according to the standard RRset authentication rules described in
- Section 5.3, then apply the NSEC RRsets as follows:
-
- o If the requested RR name matches the owner name of an
- authenticated NSEC RR, then the NSEC RR's type bit map field lists
- all RR types present at that owner name, and a resolver can prove
- that the requested RR type does not exist by checking for the RR
- type in the bit map. If the number of labels in an authenticated
- NSEC RR's owner name equals the Labels field of the covering RRSIG
- RR, then the existence of the NSEC RR proves that wildcard
- expansion could not have been used to match the request.
-
- o If the requested RR name would appear after an authenticated NSEC
- RR's owner name and before the name listed in that NSEC RR's Next
- Domain Name field according to the canonical DNS name order
- defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
- the requested name exist in the zone. However, it is possible
- that a wildcard could be used to match the requested RR owner name
- and type, so proving that the requested RRset does not exist also
- requires proving that no possible wildcard RRset exists that could
- have been used to generate a positive response.
-
- To prove non-existence of an RRset, the resolver must be able to
- verify both that the queried RRset does not exist and that no
- relevant wildcard RRset exists. Proving this may require more than
- one NSEC RRset from the zone. If the complete set of necessary NSEC
- RRsets is not present in a response (perhaps due to message
- truncation), then a security-aware resolver MUST resend the query in
- order to attempt to obtain the full collection of NSEC RRs necessary
- to verify non-existence of the requested RRset. As with all DNS
- operations, however, the resolver MUST bound the work it puts into
- answering any particular query.
-
- Since a verified NSEC RR proves the existence of both itself and its
- corresponding RRSIG RR, a verifier MUST ignore the settings of the
- NSEC and RRSIG bits in an NSEC RR.
-
-5.5 Authentication Example
-
- Appendix C shows an example the authentication process.
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 33]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-6. IANA Considerations
-
- [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
- considerations introduced by DNSSEC. The additional IANA
- considerations discussed in this document:
-
- [RFC2535] reserved the CD and AD bits in the message header. The
- meaning of the AD bit was redefined in [RFC3655] and the meaning of
- both the CD and AD bit are restated in this document. No new bits in
- the DNS message header are defined in this document.
-
- [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
- and defined its use. The use is restated but not altered in this
- document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 34]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-7. Security Considerations
-
- This document describes how the DNS security extensions use public
- key cryptography to sign and authenticate DNS resource record sets.
- Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
- security considerations related to DNSSEC; see
- [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
- DNSSEC resource record types.
-
- An active attacker who can set the CD bit in a DNS query message or
- the AD bit in a DNS response message can use these bits to defeat the
- protection which DNSSEC attempts to provide to security-oblivious
- recursive-mode resolvers. For this reason, use of these control bits
- by a security-aware recursive-mode resolver requires a secure
- channel. See Section 3.2.2 and Section 4.8 for further discussion.
-
- The protocol described in this document attempts to extend the
- benefits of DNSSEC to security-oblivious stub resolvers. However,
- since recovery from validation failures is likely to be specific to
- particular applications, the facilities that DNSSEC provides for stub
- resolvers may prove inadequate. Operators of security-aware
- recursive name servers will need to pay close attention to the
- behavior of the applications which use their services when choosing a
- local validation policy; failure to do so could easily result in the
- recursive name server accidently denying service to the clients it is
- intended to support.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 35]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-8. Acknowledgements
-
- This document was created from the input and ideas of the members of
- the DNS Extensions Working Group and working group mailing list. The
- editors would like to express their thanks for the comments and
- suggestions received during the revision of these security extension
- specifications. While explicitly listing everyone who has
- contributed during the decade during which DNSSEC has been under
- development would be an impossible task,
- [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
- participants who were kind enough to comment on these documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 36]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
- August 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
- [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
- [I-D.ietf-dnsext-dnssec-intro]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "DNS Security Introduction and Requirements",
- draft-ietf-dnsext-dnssec-intro-09 (work in progress),
- February 2004.
-
- [I-D.ietf-dnsext-dnssec-records]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "Resource Records for DNS Security Extensions",
- draft-ietf-dnsext-dnssec-records-07 (work in progress),
- February 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 37]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-Informative References
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
- Authenticated Data (AD) bit", RFC 3655, November 2003.
-
- [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
- (RR)", RFC 3658, December 2003.
-
- [I-D.ietf-dnsext-wcard-clarify]
- Halley, B. and E. Lewis, "Clarifying the Role of Wild Card
- Domains in the Domain Name System",
- draft-ietf-dnsext-wcard-clarify-02 (work in progress),
- September 2003.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 38]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- Rob Austein
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- EMail: sra@isc.org
-
-
- Dan Massey
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.edu
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-8920
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 39]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-Appendix A. Signed Zone Example
-
- The following example shows a (small) complete signed zone.
-
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1071609350
- 3600
- 300
- 3600000
- 3600
- )
- 3600 RRSIG SOA 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
- hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
- VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
- CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
- owLe/OV+Qqqic7ShV/S9l2YJF9I= )
- 3600 NS ns1.example.
- 3600 NS ns2.example.
- 3600 RRSIG NS 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
- +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
- s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
- eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
- FTVyQbVkcaxQ6U2FbZtMbfo//go= )
- 3600 MX 1 xx.example.
- 3600 RRSIG MX 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18
- 7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe
- IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+
- M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q
- 7wxkDWyzgasGiMNIKgYrm9vXz04= )
- 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
- 3600 RRSIG NSEC 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
- vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
- TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
- Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
- 7T/nOEOVZujD8IN/Utv+KUg+P6U= )
- 3600 DNSKEY 256 3 5 (
- AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH
- UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV
- fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv
- BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 40]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- 5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q==
- )
- 3600 DNSKEY 257 3 5 (
- AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U
- Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv
- klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE
- 2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT
- nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ==
- )
- 3600 RRSIG DNSKEY 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU
- pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5
- YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc
- tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG
- PjJstq6fvRq8kX7TPJcljUmDFKM= )
- 3600 RRSIG DNSKEY 5 1 3600 20040115201552 (
- 20031216201552 60717 example.
- EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/
- C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK
- L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY
- J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34
- Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= )
- a.example. 3600 IN NS ns1.a.example.
- 3600 IN NS ns2.a.example.
- 3600 DS 48327 5 1 (
- DFEB5E00E71A4DED5CABBBD7F15F24871983
- CAB7 )
- 3600 RRSIG DS 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
- hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
- rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
- ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
- 0yfe2uolEkeegjesDZuF+fC61Eg= )
- 3600 NSEC ai.example. NS DS RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb
- RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1
- 3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O
- ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf
- YgfAHJEJJj7K88QbKEK4/Je1hyk= )
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
- ai.example. 3600 IN A 192.0.2.9
- 3600 RRSIG A 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 41]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
- jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
- Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
- OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
- sWifTxvcG5hv+A6TOd0O2xJYRik= )
- 3600 HINFO "KLH-10" "ITS"
- 3600 RRSIG HINFO 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- 4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C
- hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2
- KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2
- Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92
- xo9NLoltg0GuwggZM240pRoTwO8= )
- 3600 AAAA 2001:db8::f00:baa9
- 3600 RRSIG AAAA 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
- 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
- G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
- A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
- zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )
- 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE
- ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y
- ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU
- 4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR
- ovChG5Ih3TOa8Qnch4IJQVfSFNU= )
- b.example. 3600 IN NS ns1.b.example.
- 3600 IN NS ns2.b.example.
- 3600 NSEC ns1.example. NS RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
- VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
- VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
- k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
- GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
- ns1.example. 3600 IN A 192.0.2.1
- 3600 RRSIG A 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
- CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
- RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
- +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 42]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
- 3600 NSEC ns2.example. A RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
- sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
- eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
- s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
- I2A5W86mMEbSgEF/pZHX/wi5FJI= )
- ns2.example. 3600 IN A 192.0.2.2
- 3600 RRSIG A 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
- xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
- HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
- sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
- wCbeY0Rl8MIRcAaiIkFos/8hd1g= )
- 3600 NSEC *.w.example. A RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb
- IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b
- f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J
- aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl
- yCup5bk/Dr47eU2/6+lqrBTOV8Q= )
- *.w.example. 3600 IN MX 1 ai.example.
- 3600 RRSIG MX 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
- OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns
- Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
- n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
- 91Ena87PA2MvoOE+A3ZpEk8MjEE= )
- 3600 NSEC x.w.example. MX RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
- f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
- 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
- /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
- ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )
- x.w.example. 3600 IN MX 1 xx.example.
- 3600 RRSIG MX 5 3 3600 20040115201552 (
- 20031216201552 41681 example.
- g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
- ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
- 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
- MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 43]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- btznHMFDIbtuw/tAX7xXH2pDDHY= )
- 3600 NSEC x.y.w.example. MX RRSIG NSEC
- 3600 RRSIG NSEC 5 3 3600 20040115201552 (
- 20031216201552 41681 example.
- zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia
- CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA
- EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA
- aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT
- 3lMXiX4KNWUhB87q/pT/5z+xrqY= )
- x.y.w.example. 3600 IN MX 1 xx.example.
- 3600 RRSIG MX 5 4 3600 20040115201552 (
- 20031216201552 41681 example.
- slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD
- v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE
- unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK
- Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk
- Iykd5UmaTO5j4LlRnAvF8Z1m9/k= )
- 3600 NSEC xx.example. MX RRSIG NSEC
- 3600 RRSIG NSEC 5 4 3600 20040115201552 (
- 20031216201552 41681 example.
- sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
- VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
- Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
- AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
- viOQHZ6I4xoZQP5G7r98/PhlrLM= )
- xx.example. 3600 IN A 192.0.2.10
- 3600 RRSIG A 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
- tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
- iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
- KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
- 0ToQVY81bPc3WXKZjRxQl3jiKtU= )
- 3600 HINFO "KLH-10" "TOPS-20"
- 3600 RRSIG HINFO 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw
- p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA
- gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/
- pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp
- EDXT07qFXtGntvBSpF9uQbEub6Y= )
- 3600 AAAA 2001:db8::f00:baaa
- 3600 RRSIG AAAA 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2
- dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
- mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
- CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 44]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- D4ZubIon0XGe9fIjLnmb3pX/FUk= )
- 3600 NSEC example. A HINFO AAAA RRSIG NSEC
- 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn
- uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE
- NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a
- 1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187
- sSNF3PAC0HPadh7SdHmXlFQtQ44= )
-
- The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
- Flags indicate that each of these DNSKEY RRs is a zone key. One of
- these DNSKEY RRs also has the SEP flag set and has been used to sign
- the apex DNSKEY RRset; this is the key which should be hashed to
- generate a DS record to be inserted into the parent zone. The other
- DNSKEY is used to sign all the other RRsets in the zone.
-
- The zone includes a wildcard entry "*.w.example". Note that the name
- "*.w.example" is used in constructing NSEC chains, and that the RRSIG
- covering the "*.w.example" MX RRset has a label count of 2.
-
- The zone also includes two delegations. The delegation to
- "b.example" includes an NS RRset, glue address records, and an NSEC
- RR; note that only the NSEC RRset is signed. The delegation to
- "a.example" provides a DS RR; note that only the NSEC and DS RRsets
- are signed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 45]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-Appendix B. Example Responses
-
- The examples in this section show response messages using the signed
- zone example in Appendix A.
-
-B.1 Answer
-
- A successful query to an authoritative server.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- x.w.example. IN MX
-
- ;; Answer
- x.w.example. 3600 IN MX 1 xx.example.
- x.w.example. 3600 RRSIG MX 5 3 3600 20040115201552 (
- 20031216201552 41681 example.
- g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
- ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
- 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
- MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv
- btznHMFDIbtuw/tAX7xXH2pDDHY= )
-
- ;; Authority
- example. 3600 NS ns1.example.
- example. 3600 NS ns2.example.
- example. 3600 RRSIG NS 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
- +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
- s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
- eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
- FTVyQbVkcaxQ6U2FbZtMbfo//go= )
-
- ;; Additional
- xx.example. 3600 IN A 192.0.2.10
- xx.example. 3600 RRSIG A 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
- tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
- iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
- KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
- 0ToQVY81bPc3WXKZjRxQl3jiKtU= )
- xx.example. 3600 AAAA 2001:db8::f00:baaa
- xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 46]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
- mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
- CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z
- D4ZubIon0XGe9fIjLnmb3pX/FUk= )
- ns1.example. 3600 IN A 192.0.2.1
- ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
- CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
- RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
- +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa
- WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
- ns2.example. 3600 IN A 192.0.2.2
- ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
- xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
- HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
- sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
- wCbeY0Rl8MIRcAaiIkFos/8hd1g= )
-
-
-B.2 Name Error
-
- An authoritative name error. The NSEC RRs prove that the name does
- not exist and that no covering wildcard exists.
-
- ;; Header: QR AA DO RCODE=3
- ;;
- ;; Question
- ml.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1071609350
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
- hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
- VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 47]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
- owLe/OV+Qqqic7ShV/S9l2YJF9I= )
- b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
- b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
- VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
- VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
- k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
- GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
- example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
- example. 3600 RRSIG NSEC 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
- vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
- TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
- Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
- 7T/nOEOVZujD8IN/Utv+KUg+P6U= )
-
- ;; Additional
- ;; (empty)
-
-
-B.3 No Data Error
-
- A "NODATA" response. The NSEC RR proves that the name exists and
- that the requested RR type does not.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- ns1.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1071609350
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
- hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 48]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
- CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
- owLe/OV+Qqqic7ShV/S9l2YJF9I= )
- ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
- ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
- sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
- eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
- s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
- I2A5W86mMEbSgEF/pZHX/wi5FJI= )
-
- ;; Additional
- ;; (empty)
-
-
-B.4 Referral to Signed Zone
-
- Referral to a signed zone. The DS RR contains the data which the
- resolver will need to validate the corresponding DNSKEY RR in the
- child zone's apex.
-
- ;; Header: QR DO RCODE=0
- ;;
- ;; Question
- mc.a.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- a.example. 3600 IN NS ns1.a.example.
- a.example. 3600 IN NS ns2.a.example.
- a.example. 3600 DS 48327 5 1 (
- DFEB5E00E71A4DED5CABBBD7F15F24871983
- CAB7 )
- a.example. 3600 RRSIG DS 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
- hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
- rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
- ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
- 0yfe2uolEkeegjesDZuF+fC61Eg= )
-
- ;; Additional
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 49]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-B.5 Referral to Unsigned Zone
-
- Referral to an unsigned zone. The NSEC RR proves that no DS RR for
- this delegation exists in the parent zone.
-
- ;; Header: QR DO RCODE=0
- ;;
- ;; Question
- mc.b.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- b.example. 3600 IN NS ns1.b.example.
- b.example. 3600 IN NS ns2.b.example.
- b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
- b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
- VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
- VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
- k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
- GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
-
- ;; Additional
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
-
-
-B.6 Wildcard Expansion
-
- A successful query which was answered via wildcard expansion. The
- label count in the answer's RRSIG RR indicates that a wildcard RRset
- was expanded to produce this response, and the NSEC RR proves that no
- closer match exists in the zone.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN MX
-
- ;; Answer
- a.z.w.example. 3600 IN MX 1 ai.example.
- a.z.w.example. 3600 RRSIG MX 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
- OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 50]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
- n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
- 91Ena87PA2MvoOE+A3ZpEk8MjEE= )
-
- ;; Authority
- example. 3600 NS ns1.example.
- example. 3600 NS ns2.example.
- example. 3600 RRSIG NS 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
- +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
- s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
- eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
- FTVyQbVkcaxQ6U2FbZtMbfo//go= )
- x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
- x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 (
- 20031216201552 41681 example.
- sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
- VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
- Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
- AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
- viOQHZ6I4xoZQP5G7r98/PhlrLM= )
-
- ;; Additional
- ai.example. 3600 IN A 192.0.2.9
- ai.example. 3600 RRSIG A 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
- jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
- Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
- OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
- sWifTxvcG5hv+A6TOd0O2xJYRik= )
- ai.example. 3600 AAAA 2001:db8::f00:baa9
- ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
- 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
- G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
- A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
- zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )
-
-
-B.7 Wildcard No Data Error
-
- A "NODATA" response for a name covered by a wildcard. The NSEC RRs
- prove that the matching wildcard name does not have any RRs of the
- requested type and that no closer match exists in the zone.
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 51]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN AAAA
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1071609350
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
- hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
- VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
- CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
- owLe/OV+Qqqic7ShV/S9l2YJF9I= )
- x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
- x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 (
- 20031216201552 41681 example.
- sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
- VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
- Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
- AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
- viOQHZ6I4xoZQP5G7r98/PhlrLM= )
- *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
- *.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
- 20031216201552 41681 example.
- OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
- f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
- 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
- /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
- ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )
-
- ;; Additional
- ;; (empty)
-
-
-B.8 DS Child Zone No Data Error
-
- A "NODATA" response for a QTYPE=DS query which was mistakenly sent to
- a name server for the child zone.
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 52]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- example. IN DS
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1071609350
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
- hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
- VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
- CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
- owLe/OV+Qqqic7ShV/S9l2YJF9I= )
- example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
- example. 3600 RRSIG NSEC 5 1 3600 20040115201552 (
- 20031216201552 41681 example.
- kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
- vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
- TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
- Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
- 7T/nOEOVZujD8IN/Utv+KUg+P6U= )
-
- ;; Additional
- ;; (empty)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 53]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-Appendix C. Authentication Examples
-
- The examples in this section show how the response messages in
- Appendix B are authenticated.
-
-C.1 Authenticating An Answer
-
- The query in section Appendix B.1 returned an MX RRset for
- "x.w.example.com". The corresponding RRSIG indicates the MX RRset was
- signed by an "example" DNSKEY with algorithm 5 and key tag 41681.
- The resolver needs the corresponding DNSKEY RR in order to
- authenticate this answer. The discussion below describes how a
- resolver might obtain this DNSKEY RR.
-
- The RRSIG indicates the original TTL of the MX RRset was 3600 and,
- for the purpose of authentication, the current TTL is replaced by
- 3600. The RRSIG labels field value of 3 indicates the answer was
- not the result of wildcard expansion. The "x.w.example.com" MX RRset
- is placed in canonical form and, assuming the current time falls
- between the signature inception and expiration dates, the signature
- is authenticated.
-
-C.1.1 Authenticating the example DNSKEY RR
-
- This example shows the logical authentication process that starts
- from the a preconfigured root DNSKEY (or DS RR) and moves down the
- tree to authenticate the desired "example" DNSKEY RR. Note the
- logical order is presented for clarity and an implementation may
- choose to construct the authentication as referrals are received or
- may choose to construct the authentication chain only after all
- RRsets have been obtained, or in any other combination it sees fit.
- The example here demonstrates only the logical process and does not
- dictate any implementation rules.
-
- We assume the resolver starts with an preconfigured DNSKEY RR for the
- root zone (or a preconfigured DS RR for the root zone). The resolver
- checks this preconfigured DNSKEY RR is present in the root DNSKEY
- RRset (or the DS RR matches some DNSKEY in the root DNSKEY RRset),
- this DNSKEY RR has signed the root DNSKEY RRset and the signature
- lifetime is valid. If all these conditions are met, all keys in the
- DNSKEY RRset are considered authenticated. The resolver then uses
- one (or more) of the root DNSKEY RRs to authenticate the "example" DS
- RRset. Note the resolver may need to query the root zone to obtain
- the root DNSKEY RRset and/or "example" DS RRset.
-
- Once the DS RRset has been authenticated using the root DNSKEY, the
- resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
- RR that matches one of the authenticated "example" DS RRs. If such a
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 54]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- matching "example" DNSKEY is found, the resolver checks this DNSKEY
- RR has signed the "example" DNSKEY RRset and the signature lifetime
- is valid. If all these conditions are met, all keys in the "example"
- DNSKEY RRset are considered authenticated.
-
- Finally the resolver checks that some DNSKEY RR in the "example"
- DNSKEY RRset uses algorithm 5 and has a key tag of 41681. This
- DNSKEY is used to authenticated the RRSIG included in the response.
- If multiple "example" DNSKEY RRs have algorithm 5 and key tag of
- 41681, then each DNSKEY RR is tried and the answer is authenticated
- if either DNSKEY RR validates the signature as described above.
-
-C.2 Name Error
-
- The query in section Appendix B.2 returned NSEC RRs that prove the
- requested data does not exist and no wildcard applies. The negative
- reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
- authenticated in a manner identical to that of the MX RRset discussed
- above.
-
-C.3 No Data Error
-
- The query in section Appendix B.3 returned an NSEC RR that proves the
- requested name exists, but the requested RR type does not exist. The
- negative reply is authenticated by verifying the NSEC RR. The NSEC
- RR is authenticated in a manner identical to that of the MX RRset
- discussed above.
-
-C.4 Referral to Signed Zone
-
- The query in section Appendix B.4 returned a referral to the signed
- "a.example." zone. The DS RR is authenticated in a manner identical
- to that of the MX RRset discussed above. This DS RR is used to
- authenticate the "a.example" DNSKEY RRset.
-
- Once the "a.example" DS RRset has been authenticated using the
- "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
- for some "a.example" DNSKEY RR that matches the DS RR. If such a
- matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
- RR has signed the "a.example" DNSKEY RRset and the signature lifetime
- is valid. If all these conditions are met, all keys in the
- "a.example" DNSKEY RRset are considered authenticated.
-
-C.5 Referral to Unsigned Zone
-
- The query in section Appendix B.5 returned a referral to an unsigned
- "b.example." zone. The NSEC proves that no authentication leads from
- "example" to "b.example" and the NSEC RR is authenticated in a manner
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 55]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- identical to that of the MX RRset discussed above.
-
-C.6 Wildcard Expansion
-
- The query in section Appendix B.6 returned an answer that was
- produced as a result of wildcard expansion. The RRset expanded as
- the similar to The corresponding RRSIG indicates the MX RRset was
- signed by an "example" DNSKEY with algorithm 5 and key tag 41681.
- The RRSIG indicates the original TTL of the MX RRset was 3600 and,
- for the purpose of authentication, the current TTL is replaced by
- 3600. The RRSIG labels field value of 2 indicates the answer the
- result of wildcard expansion since the "a.z.w.example" name contains
- 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example",
- the MX RRset is placed in canonical form and, assuming the current
- time falls between the signature inception and expiration dates, the
- signature is authenticated.
-
- The NSEC proves that no closer match (exact or closer wildcard) could
- have been used to answer this query and the NSEC RR must also be
- authenticated before the answer is considered valid.
-
-C.7 Wildcard No Data Error
-
- The query in section Appendix B.7 returned NSEC RRs that prove the
- requested data does not exist and no wildcard applies. The negative
- reply is authenticated by verifying both NSEC RRs.
-
-C.8 DS Child Zone No Data Error
-
- The query in section Appendix B.8 returned NSEC RRs that shows the
- requested was answered by a child server ("example" server). The
- NSEC RR indicates the presence of an SOA RR, showing the answer is
- from the child . Queries for the "example" DS RRset should be sent
- to the parent servers ("root" servers).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 56]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 57]
-\f
-Internet-Draft DNSSEC Protocol Modifications February 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 58]
-\f
-
+++ /dev/null
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 16, 2004 R. Austein
- ISC
- M. Larson
- VeriSign
- D. Massey
- USC/ISI
- S. Rose
- NIST
- February 16, 2004
-
-
- Resource Records for the DNS Security Extensions
- draft-ietf-dnsext-dnssec-records-07
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 16, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document is part of a family of documents that describes the DNS
- Security Extensions (DNSSEC). The DNS Security Extensions are a
- collection of resource records and protocol modifications that
- provide source authentication for the DNS. This document defines the
- public key (DNSKEY), delegation signer (DS), resource record digital
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 1]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- signature (RRSIG), and authenticated denial of existence (NSEC)
- resource records. The purpose and format of each resource record is
- described in detail, and an example of each resource record is given.
-
- This document obsoletes RFC 2535 and incorporates changes from all
- updates to RFC 2535.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Background and Related Documents . . . . . . . . . . . . . . 4
- 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
- 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
- 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
- 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 6
- 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6
- 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6
- 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7
- 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7
- 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7
- 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . . . . 7
- 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7
- 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8
- 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9
- 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . . 9
- 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10
- 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10
- 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10
- 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11
- 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11
- 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11
- 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 12
- 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12
- 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13
- 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13
- 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15
- 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15
- 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15
- 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . . . . 16
- 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 17
- 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 17
- 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17
- 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 19
- 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 19
- 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 20
- 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 20
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 2]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 20
- 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 20
- 5.2 Processing of DS RRs When Validating Responses . . . . . . . 20
- 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 21
- 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 21
- 6. Canonical Form and Order of Resource Records . . . . . . . . 22
- 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 22
- 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 22
- 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 23
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
- 8. Security Considerations . . . . . . . . . . . . . . . . . . 26
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27
- Normative References . . . . . . . . . . . . . . . . . . . . 28
- Informative References . . . . . . . . . . . . . . . . . . . 30
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
- A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 32
- A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 32
- A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 32
- A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33
- B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34
- B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35
- Intellectual Property and Copyright Statements . . . . . . . 36
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 3]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) introduce four new DNS resource
- record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the
- purpose of each resource record (RR), the RR's RDATA format, and its
- presentation format (ASCII representation).
-
-1.1 Background and Related Documents
-
- The reader is assumed to be familiar with the basic DNS concepts
- described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs
- that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308
- [RFC2308].
-
- This document is part of a family of documents that define the DNS
- security extensions. The DNS security extensions (DNSSEC) are a
- collection of resource records and DNS protocol modifications that
- add source authentication and data integrity to the Domain Name
- System (DNS). An introduction to DNSSEC and definitions of common
- terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description
- of DNS protocol modifications can be found in
- [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC
- resource records.
-
-1.2 Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1.3 Editors' Notes
-
-1.3.1 Open Technical Issues
-
- The cryptographic algorithm types (Appendix A) requires input from
- the working group. The DSA algorithm was moved to OPTIONAL. This
- had strong consensus in workshops and various discussions and a
- separate Internet-Draft solely to move DSA from MANDATORY to OPTIONAL
- seemed excessive. This draft solicits input on that proposed change.
-
-1.3.2 Technical Changes or Corrections
-
- Please report technical corrections to dnssec-editors@east.isi.edu.
- To assist the editors, please indicate the text in error and point
- out the RFC that defines the correct behavior. For a technical
- change where no RFC that defines the correct behavior, or if there's
- more than one applicable RFC and the definitions conflict, please
- post the issue to namedroppers.
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 4]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- An example correction to dnssec-editors might be: Page X says
- "DNSSEC RRs SHOULD be automatically returned in responses." This was
- true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
- DNSSEC RR types MUST NOT be included in responses unless the resolver
- indicated support for DNSSEC.
-
-1.3.3 Typos and Minor Corrections
-
- Please report any typos corrections to dnssec-editors@east.isi.edu.
- To assist the editors, please provide enough context for us to find
- the incorrect text quickly.
-
- An example message to dnssec-editors might be: page X says "the
- DNSSEC standard has been in development for over 1 years". It
- should read "over 10 years".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 5]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-2. The DNSKEY Resource Record
-
- DNSSEC uses public key cryptography to sign and authenticate DNS
- resource record sets (RRsets). The public keys are stored in DNSKEY
- resource records and are used in the DNSSEC authentication process
- described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
- authoritative RRsets using a private key and stores the corresponding
- public key in a DNSKEY RR. A resolver can then use the public key to
- authenticate signatures covering the RRsets in the zone.
-
- The DNSKEY RR is not intended as a record for storing arbitrary
- public keys, and MUST NOT be used to store certificates or public
- keys that do not directly relate to the DNS infrastructure.
-
- The Type value for the DNSKEY RR type is 48.
-
- The DNSKEY RR is class independent.
-
- The DNSKEY RR has no special TTL requirements.
-
-2.1 DNSKEY RDATA Wire Format
-
- The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
- octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
- Field.
-
- 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 /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-2.1.1 The Flags Field
-
- Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
- then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner
- name MUST be the name of a zone. If bit 7 has value 0, then the
- DNSKEY record holds some other type of DNS public key, such as a
- public key used by TKEY and MUST NOT be used to verify RRSIGs that
- cover RRsets.
-
- Bit 15 of the Flags field is the Secure Entry Point flag, described
- in [I-D.ietf-dnsext-keyrr-key-signing-flag]. If bit 15 has value 1,
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 6]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- then the DNSKEY record holds a key intended for use as a secure entry
- point. This flag is only intended to be to a hint to zone signing or
- debugging software as to the intended use of this DNSKEY record;
- security-aware resolvers MUST NOT alter their behavior during the
- signature validation process in any way based on the setting of this
- bit.
-
- Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
- creation of the DNSKEY RR, and MUST be ignored upon reception.
-
-2.1.2 The Protocol Field
-
- The Protocol Field MUST have value 3 and MUST be treated as invalid
- during signature verification if found to be some value other than 3.
-
-2.1.3 The Algorithm Field
-
- The Algorithm field identifies the public key's cryptographic
- algorithm and determines the format of the Public Key field. A list
- of DNSSEC algorithm types can be found in Appendix A.1
-
-2.1.4 The Public Key Field
-
- The Public Key Field holds the public key material. The format
- depends on the algorithm of the key being stored and are described in
- separate documents.
-
-2.1.5 Notes on DNSKEY RDATA Design
-
- Although the Protocol Field always has value 3, it is retained for
- backward compatibility with early versions of the KEY record.
-
-2.2 The DNSKEY RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Flag field MUST be represented as an unsigned decimal integer
- with a value of 0, 256, or 257.
-
- The Protocol Field MUST be represented as an unsigned decimal integer
- with a value of 3.
-
- The Algorithm field MUST be represented either as an unsigned
- decimal integer or as an algorithm mnemonic as specified in Appendix
- A.1.
-
- The Public Key field MUST be represented as a Base64 encoding of the
- Public Key. Whitespace is allowed within the Base64 text. For a
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 7]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- definition of Base64 encoding, see [RFC1521] Section 5.2.
-
-2.3 DNSKEY RR Example
-
- The following DNSKEY RR stores a DNS zone key for example.com.
-
- example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
- Cbl+BBZH4b/0PY1kxkmvHjcZc8no
- kfzj31GajIQKY+5CptLr3buXA10h
- WqTkF7H6RfoRqXQeogmMHfpftf6z
- Mv1LyBUgia7za6ZEzOJBOztyvhjL
- 742iU/TpPSEDhm2SNKLijfUppn1U
- aNvv4w== )
-
- The first four text fields specify the owner name, TTL, Class, and RR
- type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in
- the Flags field has value 1. Value 3 is the fixed Protocol value.
- Value 5 indicates the public key algorithm. Appendix A.1 identifies
- algorithm type 5 as RSA/SHA1 and indicates that the format of the
- RSA/SHA1 public key field is defined in [RFC3110]. The remaining
- text is a Base64 encoding of the public key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 8]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-3. The RRSIG Resource Record
-
- DNSSEC uses public key cryptography to sign and authenticate DNS
- resource record sets (RRsets). Digital signatures are stored in
- RRSIG resource records and are used in the DNSSEC authentication
- process described in [I-D.ietf-dnsext-dnssec-protocol]. A
- security-aware resolver can use these RRSIG RRs to authenticate
- RRsets from the zone. The RRSIG RR MUST only be used to carry
- verification material (digital signatures) used to secure DNS
- operations.
-
- An RRSIG record contains the signature for an RRset with a particular
- name, class, and type. The RRSIG RR specifies a validity interval
- for the signature and uses the Algorithm, the Signer's Name, and the
- Key Tag to identify the DNSKEY RR containing the public key that a
- resolver can use to verify the signature.
-
- Because every authoritative RRset in a zone must be protected by a
- digital signature, RRSIG RRs must be present for names containing a
- CNAME RR. This is a change to the traditional DNS specification
- [RFC1034] that stated that if a CNAME is present for a name, it is
- the only type allowed at that name. A RRSIG and NSEC (see Section 4)
- MUST exist for the same name as a CNAME resource record in a secure
- zone.
-
- The Type value for the RRSIG RR type is 46.
-
- The RRSIG RR is class independent.
-
- An RRSIG RR MUST have the same class as the RRset it covers.
-
- The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
- it covers. This is an exception to the [RFC2181] rules for TTL
- values of individual RRs within a RRset: individual RRSIG with the
- same owner name will have different TTL values if the RRsets that
- they cover have different TTL values.
-
-3.1 RRSIG RDATA Wire Format
-
- The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
- 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
- TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
- Inception field, a 2 octet Key tag, the Signer's Name field, and the
- Signature field.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 9]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- | Type Covered | Algorithm | Labels |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Original TTL |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Signature Expiration |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Signature Inception |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Key Tag | /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / /
- / Signature /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1.1 The Type Covered Field
-
- The Type Covered field identifies the type of the RRset which is
- covered by this RRSIG record.
-
-3.1.2 The Algorithm Number Field
-
- The Algorithm Number field identifies the cryptographic algorithm
- used to create the signature. A list of DNSSEC algorithm types can
- be found in Appendix A.1
-
-3.1.3 The Labels Field
-
- The Labels field specifies the number of labels in the original RRSIG
- RR owner name. The significance of this field is that from it a
- verifier can determine if the answer was synthesized from a wildcard.
- If so, it can be used to determine what owner name was used in
- generating the signature.
-
- To validate a signature, the validator needs the original owner name
- that was used to create the signature. If the original owner name
- contains a wildcard label ("*"), the owner name may have been
- expanded by the server during the response process, in which case the
- validator will need to reconstruct the original owner name in order
- to validate the signature. [I-D.ietf-dnsext-dnssec-protocol]
- describes how to use the Labels field to reconstruct the original
- owner name.
-
- The value of the Labels field MUST NOT count either the null (root)
- label that terminates the owner name or the wildcard label (if
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 10]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- present). The value of the Labels field MUST be less than or equal
- to the number of labels in the RRSIG owner name. For example,
- "www.example.com." has a Labels field value of 3, and
- "*.example.com." has a Labels field value of 2. Root (".") has a
- Labels field value of 0.
-
- Although the wildcard label is not included in the count stored in
- the Labels field of the RRSIG RR, the wildcard label is part of the
- RRset's owner name when generating or verifying the signature.
-
-3.1.4 Original TTL Field
-
- The Original TTL field specifies the TTL of the covered RRset as it
- appears in the authoritative zone.
-
- The Original TTL field is necessary because a caching resolver
- decrements the TTL value of a cached RRset. In order to validate a
- signature, a resolver requires the original TTL.
- [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
- TTL field value to reconstruct the original TTL.
-
-3.1.5 Signature Expiration and Inception Fields
-
- The Signature Expiration and Inception fields specify a validity
- period for the signature. The RRSIG record MUST NOT be used for
- authentication prior to the inception date and MUST NOT be used for
- authentication after the expiration date.
-
- Signature Expiration and Inception field values are in POSIX.1 time
- format: a 32-bit unsigned number of seconds elapsed since 1 January
- 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The
- longest interval which can be expressed by this format without
- wrapping is approximately 136 years. An RRSIG RR can have an
- Expiration field value which is numerically smaller than the
- Inception field value if the expiration field value is near the
- 32-bit wrap-around point or if the signature is long lived. Because
- of this, all comparisons involving these fields MUST use "Serial
- number arithmetic" as defined in [RFC1982]. As a direct consequence,
- the values contained in these fields cannot refer to dates more than
- 68 years in either the past or the future.
-
-3.1.6 The Key Tag Field
-
- The Key Tag field contains the key tag value of the DNSKEY RR that
- validates this signature. Appendix B explains how to calculate Key
- Tag values.
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 11]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-3.1.7 The Signer's Name Field
-
- The Signer's Name field value identifies the owner name of the DNSKEY
- RR which a security-aware resolver should use to validate this
- signature. The Signer's Name field MUST contain the name of the zone
- of the covered RRset. A sender MUST NOT use DNS name compression on
- the Signer's Name field when transmitting a RRSIG RR. A receiver
- which receives an RRSIG RR containing a compressed Signer's Name
- field SHOULD decompress the field value.
-
-3.1.8 The Signature Field
-
- The Signature field contains the cryptographic signature which covers
- the RRSIG RDATA (excluding the Signature field) and the RRset
- specified by the RRSIG owner name, RRSIG class, and RRSIG Type
- Covered field. The format of this field depends on the algorithm in
- use and these formats are described in separate companion documents.
-
-3.1.8.1 Signature Calculation
-
- A signature covers the RRSIG RDATA (excluding the Signature Field)
- and covers the data RRset specified by the RRSIG owner name, RRSIG
- class, and RRSIG Type Covered fields. The RRset is in canonical form
- (see Section 6) and the set RR(1),...RR(n) is signed as follows:
-
- signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
-
- "|" denotes concatenation;
-
- RRSIG_RDATA is the wire format of the RRSIG RDATA fields
- with the Signer's Name field in canonical form and
- the Signature field excluded;
-
- RR(i) = owner | class | type | TTL | RDATA length | RDATA;
-
- "owner" is the fully qualified owner name of the RRset in
- canonical form (for RRs with wildcard owner names, the
- wildcard label is included in the owner name);
-
- Each RR MUST have the same owner name as the RRSIG RR;
-
- Each RR MUST have the same class as the RRSIG RR;
-
- Each RR in the RRset MUST have the RR type listed in the
- RRSIG RR's Type Covered field;
-
- Each RR in the RRset MUST have the TTL listed in the
- RRSIG Original TTL Field;
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 12]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- Any DNS names in the RDATA field of each RR MUST be in
- canonical form; and
-
- The RRset MUST be sorted in canonical order.
-
-
-3.2 The RRSIG RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Type Covered field value MUST be represented either as an
- unsigned decimal integer or as the mnemonic for the covered RR type.
-
- The Algorithm field value MUST be represented either as an unsigned
- decimal integer or as an algorithm mnemonic as specified in Appendix
- A.1.
-
- The Labels field value MUST be represented as an unsigned decimal
- integer.
-
- The Original TTL field value MUST be represented as an unsigned
- decimal integer.
-
- The Signature Expiration Time and Inception Time field values MUST be
- represented in the form YYYYMMDDHHmmSS in UTC, where:
-
- YYYY is the year (0000-9999, but see Section 3.1.5);
-
- MM is the month number (01-12);
-
- DD is the day of the month (01-31);
-
- HH is the hour in 24 hours notation (00-23);
-
- mm is the minute (00-59);
-
- SS is the second (00-59).
-
- The Key Tag field MUST be represented as an unsigned decimal integer.
-
- The Signer's Name field value MUST be represented as a domain name.
-
- The Signature field is represented as a Base64 encoding of the
- signature. Whitespace is allowed within the Base64 text. For a
- definition of Base64 encoding see [RFC1521] Section 5.2.
-
-3.3 RRSIG RR Example
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 13]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- The following an RRSIG RR stores the signature for the A RRset of
- host.example.com:
-
- host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
- 20030220173103 2642 example.com.
- oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
- PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
- B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
- GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
- J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
-
- The first four fields specify the owner name, TTL, Class, and RR type
- (RRSIG). The "A" represents the Type Covered field. The value 5
- identifies the algorithm used (RSA/SHA1) to create the signature.
- The value 3 is the number of Labels in the original owner name. The
- value 86400 in the RRSIG RDATA is the Original TTL for the covered A
- RRset. 20030322173103 and 20030220173103 are the expiration and
- inception dates, respectively. 2642 is the Key Tag, and example.com.
- is the Signer's Name. The remaining text is a Base64 encoding of the
- signature.
-
- Note that combination of RRSIG RR owner name, class, and Type Covered
- indicate that this RRSIG covers the "host.example.com" A RRset. The
- Label value of 3 indicates that no wildcard expansion was used. The
- Algorithm, Signer's Name, and Key Tag indicate this signature can be
- authenticated using an example.com zone DNSKEY RR whose algorithm is
- 5 and key tag is 2642.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 14]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-4. The NSEC Resource Record
-
- The NSEC resource record lists two separate things: the owner name of
- the next authoritative RRset in the canonical ordering of the zone,
- and the set of RR types present at the NSEC RR's owner name. The
- complete set of NSEC RRs in a zone both indicate which authoritative
- RRsets exist in a zone and also form a chain of authoritative owner
- names in the zone. This information is used to provide authenticated
- denial of existence for DNS data, as described in
- [I-D.ietf-dnsext-dnssec-protocol].
-
- Because every authoritative name in a zone must be part of the NSEC
- chain, NSEC RRs must be present for names containing a CNAME RR.
- This is a change to the traditional DNS specification [RFC1034] that
- stated that if a CNAME is present for a name, it is the only type
- allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist
- for the same name as a CNAME resource record in a secure zone.
-
- The type value for the NSEC RR is 47.
-
- The NSEC RR is class independent.
-
- The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
- field. This is in the spirt of negative caching [RFC2308].
-
-4.1 NSEC RDATA Wire Format
-
- The RDATA of the NSEC RR is as shown below:
-
- 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 Maps /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-4.1.1 The Next Domain Name Field
-
- The Next Domain Name field contains the owner name of the next
- authoritative owner name in the canonical ordering of the zone; see
- Section 6.1 for an explanation of canonical ordering. The value of
- the Next Domain Name field in the last NSEC record in the zone is the
- name of the zone apex (the owner name of the zone's SOA RR).
-
- A sender MUST NOT use DNS name compression on the Next Domain Name
- field when transmitting an NSEC RR. A receiver which receives an
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 15]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- NSEC RR containing a compressed Next Domain Name field SHOULD
- decompress the field value.
-
- Owner names of RRsets not authoritative for the given zone (such as
- glue records) MUST NOT be listed in the Next Domain Name unless at
- least one authoritative RRset exists at the same owner name.
-
-4.1.2 The Type Bit Maps Field
-
- The Type Bit Maps field identifies the RRset types which exist at the
- NSEC RR's owner name.
-
- The RR type space is split into 256 window blocks, each representing
- the low-order 8 bits of the 16-bit RR type space. Each block that has
- at least one active RR type is encoded using a single octet window
- number (from 0 to 255), a single octet bitmap length (from 1 to 32)
- indicating the number of octets used for the window block's bitmap,
- and up to 32 octets (256 bits) of bitmap.
-
- Blocks are present in the NSEC RR RDATA in increasing numerical
- order.
-
- Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
- where "|" denotes concatenation.
-
- Each bitmap encodes the low-order 8 bits of RR types within the
- window block, in network bit order. The first bit is bit 0. For
- window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
- to RR type 2 (NS), and so forth. For window block 1, bit 1
- corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
- 1, it indicates that an RRset of that type is present for the NSEC
- RR's owner name. If a bit is set to 0, it indicates that no RRset of
- that type is present for the NSEC RR's owner name.
-
- Since bit 0 in window block 0 refers to the non-existent RR type 0,
- it MUST be set to 0. After verification, the validator MUST ignore
- the value of bit 0 in window block 0.
-
- Bits representing pseudo-types MUST be set to 0, since they do not
- appear in zone data. If encountered, they MUST be ignored upon
- reading.
-
- Blocks with no types present MUST NOT be included. Trailing zero
- octets in the bitmap MUST be omitted. The length of each block's
- bitmap is determined by the type code with the largest numerical
- value, within that block, among the set of RR types present at the
- NSEC RR's owner name. Trailing zero octets not specified MUST be
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 16]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- interpreted as zero octets.
-
- A zone MUST NOT generate an NSEC RR for any domain name that only
- holds glue records.
-
-4.1.3 Inclusion of Wildcard Names in NSEC RDATA
-
- If a wildcard owner name appears in a zone, the wildcard label ("*")
- is treated as a literal symbol and is treated the same as any other
- owner name for purposes of generating NSEC RRs. Wildcard owner names
- appear in the Next Domain Name field without any wildcard expansion.
- [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards
- on authenticated denial of existence.
-
-4.2 The NSEC RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Next Domain Name field is represented as a domain name.
-
- The Type Bit Maps field is represented as a sequence of RR type
- mnemonics. When the mnemonic is not known, the TYPE representation
- as described in [RFC3597] (section 5) MUST be used.
-
-4.3 NSEC RR Example
-
- The following NSEC RR identifies the RRsets associated with
- alfa.example.com. and identifies the next authoritative name after
- alfa.example.com.
-
- alfa.example.com. 86400 IN NSEC host.example.com. (
- A MX RRSIG NSEC TYPE1234 )
-
- The first four text fields specify the name, TTL, Class, and RR type
- (NSEC). The entry host.example.com. is the next authoritative name
- after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
- and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
- TYPE1234 RRsets associated with the name alfa.example.com.
-
- The RDATA section of the NSEC RR above would be encoded as:
-
- 0x04 'h' 'o' 's' 't'
- 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
- 0x03 'c' 'o' 'm' 0x00
- 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
- 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 17]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- 0x00 0x00 0x00 0x00 0x20
-
- Assuming that the resolver can authenticate this NSEC record, it
- could be used to prove that beta.example.com does not exist, or could
- be used to prove there is no AAAA record associated with
- alfa.example.com. Authenticated denial of existence is discussed in
- [I-D.ietf-dnsext-dnssec-protocol].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 18]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-5. The DS Resource Record
-
- The DS Resource Record refers to a DNSKEY RR and is used in the DNS
- DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
- storing the key tag, algorithm number, and a digest of the DNSKEY RR.
- Note that while the digest should be sufficient to identify the
- public key, storing the key tag and key algorithm helps make the
- identification process more efficient. By authenticating the DS
- record, a resolver can authenticate the DNSKEY RR to which the DS
- record points. The key authentication process is described in
- [I-D.ietf-dnsext-dnssec-protocol].
-
- The DS RR and its corresponding DNSKEY RR have the same owner name,
- but they are stored in different locations. The DS RR appears only
- on the upper (parental) side of a delegation, and is authoritative
- data in the parent zone. For example, the DS RR for "example.com" is
- stored in the "com" zone (the parent zone) rather than in the
- "example.com" zone (the child zone). The corresponding DNSKEY RR is
- stored in the "example.com" zone (the child zone). This simplifies
- DNS zone management and zone signing, but introduces special response
- processing requirements for the DS RR; these are described in
- [I-D.ietf-dnsext-dnssec-protocol].
-
- The type number for the DS record is 43.
-
- The DS resource record is class independent.
-
- The DS RR has no special TTL requirements.
-
-5.1 DS RDATA Wire Format
-
- The RDATA for a DS RR consists of a 2 octet Key Tag field, a one
- octet Algorithm field, a one octet Digest Type field, and a Digest
- field.
-
- 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 /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 19]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-5.1.1 The Key Tag Field
-
- The Key Tag field lists the key tag of the DNSKEY RR referred to by
- the DS record.
-
- The Key Tag used by the DS RR is identical to the Key Tag used by
- RRSIG RRs. Appendix B describes how to compute a Key Tag.
-
-5.1.2 The Algorithm Field
-
- The Algorithm field lists the algorithm number of the DNSKEY RR
- referred to by the DS record.
-
- The algorithm number used by the DS RR is identical to the algorithm
- number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm
- number types.
-
-5.1.3 The Digest Type Field
-
- The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
- RR. The Digest Type field identifies the algorithm used to construct
- the digest. Appendix A.2 lists the possible digest algorithm types.
-
-5.1.4 The Digest Field
-
- The DS record refers to a DNSKEY RR by including a digest of that
- DNSKEY RR.
-
- The digest is calculated by concatenating the canonical form of the
- fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
- and then applying the digest algorithm.
-
- digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
-
- "|" denotes concatenation
-
- DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
-
-
- The size of the digest may vary depending on the digest algorithm and
- DNSKEY RR size. As of the time of writing, the only defined digest
- algorithm is SHA-1, which produces a 20 octet digest.
-
-5.2 Processing of DS RRs When Validating Responses
-
- The DS RR links the authentication chain across zone boundaries, so
- the DS RR requires extra care in processing. The DNSKEY RR referred
- to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 20]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- have Flags bit 7 set to value 1. If the key tag does not indicate a
- DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT be
- used in the validation process.
-
-5.3 The DS RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Key Tag field MUST be represented as an unsigned decimal integer.
-
- The Algorithm field MUST be represented either as an unsigned decimal
- integer or as an algorithm mnemonic specified in Appendix A.1.
-
- The Digest Type field MUST be represented as an unsigned decimal
- integer.
-
- The Digest MUST be represented as a sequence of case-insensitive
- hexadecimal digits. Whitespace is allowed within the hexadecimal
- text.
-
-5.4 DS RR Example
-
- The following example shows a DNSKEY RR and its corresponding DS RR.
-
- dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
- fwJr1AYtsmx3TGkJaNXVbfi/
- 2pHm822aJ5iI9BMzNXxeYCmZ
- DRD99WYwYqUSdjMmmAphXdvx
- egXd/M5+X7OrzKBaMbCVdFLU
- Uh6DhweJBjEVv5f2wwjM9Xzc
- nOf+EPbtG9DMBmADjFDc2w/r
- ljwvFw==
- ) ; key id = 60485
-
- dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
- 98631FAD1A292118 )
-
-
- The first four text fields specify the name, TTL, Class, and RR type
- (DS). Value 60485 is the key tag for the corresponding
- "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
- used by this "dskey.example.com." DNSKEY RR. The value 1 is the
- algorithm used to construct the digest, and the rest of the RDATA
- text is the digest in hexadecimal.
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 21]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-6. Canonical Form and Order of Resource Records
-
- This section defines a canonical form for resource records, a
- canonical ordering of DNS names, and a canonical ordering of resource
- records within an RRset. A canonical name order is required to
- construct the NSEC name chain. A canonical RR form and ordering
- within an RRset are required to construct and verify RRSIG RRs.
-
-6.1 Canonical DNS Name Order
-
- For purposes of DNS security, owner names are ordered by treating
- individual labels as unsigned left-justified octet strings. The
- absence of a octet sorts before a zero value octet, and upper case
- US-ASCII letters are treated as if they were lower case US-ASCII
- letters.
-
- To compute the canonical ordering of a set of DNS names, start by
- sorting the names according to their most significant (rightmost)
- labels. For names in which the most significant label is identical,
- continue sorting according to their next most significant label, and
- so forth.
-
- For example, the following names are sorted in canonical DNS name
- order. The most significant label is "example". At this level,
- "example" sorts first, followed by names ending in "a.example", then
- names ending "z.example". The names within each level are sorted in
- the same way.
-
- example
- a.example
- yljkjljk.a.example
- Z.a.example
- zABC.a.EXAMPLE
- z.example
- \001.z.example
- *.z.example
- \200.z.example
-
-
-6.2 Canonical RR Form
-
- For purposes of DNS security, the canonical form of an RR is the wire
- format of the RR where:
-
- 1. Every domain name in the RR is fully expanded (no DNS name
- compression) and fully qualified;
-
- 2. All uppercase US-ASCII letters in the owner name of the RR are
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 22]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- replaced by the corresponding lowercase US-ASCII letters;
-
- 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
- HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
- SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in
- the DNS names contained within the RDATA are replaced by the
- corresponding lowercase US-ASCII letters;
-
- 4. If the owner name of the RR is a wildcard name, the owner name is
- in its original unexpanded form, including the "*" label (no
- wildcard substitution); and
-
- 5. The RR's TTL is set to its original value as it appears in the
- originating authoritative zone or the Original TTL field of the
- covering RRSIG RR.
-
-
-6.3 Canonical RR Ordering Within An RRset
-
- For purposes of DNS security, RRs with the same owner name, class,
- and type are sorted by treating the RDATA portion of the canonical
- form of each RR as a left-justified unsigned octet sequence where the
- absence of an octet sorts before a zero octet.
-
- [RFC2181] specifies that an RRset is not allowed to contain duplicate
- records (multiple RRs with the same owner name, class, type, and
- RDATA). Therefore, if an implementation detects duplicate RRs during
- RRset canonicalization, the implementation MUST treat this as a
- protocol error. If the implementation chooses to handle this
- protocol error in the spirit of the robustness principle (being
- liberal in what it accepts), the implementation MUST remove all but
- one of the duplicate RR(s) for purposes of calculating the canonical
- form of the RRset.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 23]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-7. IANA Considerations
-
- This document introduces no new IANA considerations, because all of
- the protocol parameters used in this document have already been
- assigned by previous specifications. However, since the evolution of
- DNSSEC has been long and somewhat convoluted, this section attempts
- to describe the current state of the IANA registries and other
- protocol parameters which are (or once were) related to DNSSEC.
-
- Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA
- considerations.
-
- DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
- the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS
- Resource Record Type 43 to DS.
- [I-D.ietf-dnsext-dnssec-2535typecode-change] assigned types 46,
- 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
- [I-D.ietf-dnsext-dnssec-2535typecode-change] also marked type 30
- (NXT) as Obsolete, and restricted use of types 24 (SIG) and 25
- (KEY) to the "SIG(0)" transaction security protocol described in
- [RFC2931] and the transaction KEY Resource Record described in
- [RFC2930].
-
- DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
- for DNSSEC Resource Record Algorithm field numbers, and assigned
- values 1-4 and 252-255. [RFC3110] assigned value 5.
- [I-D.ietf-dnsext-dnssec-2535typecode-change] altered this registry
- to include flags for each entry regarding its use with the DNS
- security extensions. Each algorithm entry could refer to an
- algorithm that can be used for zone signing, transaction security
- (see [RFC2931]) or both. Values 6-251 are available for assignment
- by IETF standards action. See Appendix A for a full listing of the
- DNS Security Algorithm Numbers entries at the time of writing and
- their status of use in DNSSEC.
-
- [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
- assigned value 0 to reserved and value 1 to SHA-1.
-
- KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
- Protocol Values, but [RFC3445] re-assigned all assigned values
- other than 3 to reserved and closed this IANA registry. The
- registry remains closed, and all KEY and DNSKEY records are
- required to have Protocol Octet value of 3.
-
- Flag bits in the KEY and DNSKEY RRs:
- [I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA
- registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
- this registry only contains an assignment for bit 7 (the ZONE bit)
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 24]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- and a reservation for bit 15 for the Secure Entry Point flag (SEP
- bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14
- are available for assignment by IETF Standards Action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 25]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-8. Security Considerations
-
- This document describes the format of four DNS resource records used
- by the DNS security extensions, and presents an algorithm for
- calculating a key tag for a public key. Other than the items
- described below, the resource records themselves introduce no
- security considerations. Please see [I-D.ietf-dnsext-dnssec-intro]
- and [I-D.ietf-dnsext-dnssec-protocol] for additional security
- considerations related to the use of these records.
-
- The DS record points to a DNSKEY RR using a cryptographic digest, the
- key algorithm type and a key tag. The DS record is intended to
- identify an existing DNSKEY RR, but it is theoretically possible for
- an attacker to generate a DNSKEY that matches all the DS fields. The
- probability of constructing such a matching DNSKEY depends on the
- type of digest algorithm in use. The only currently defined digest
- algorithm is SHA-1, and the working group believes that constructing
- a public key which would match the algorithm, key tag, and SHA-1
- digest given in a DS record would be a sufficiently difficult problem
- that such an attack is not a serious threat at this time.
-
- The key tag is used to help select DNSKEY resource records
- efficiently, but it does not uniquely identify a single DNSKEY
- resource record. It is possible for two distinct DNSKEY RRs to have
- the same owner name, the same algorithm type, and the same key tag.
- An implementation which used only the key tag to select a DNSKEY RR
- might select the wrong public key in some circumstances.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 26]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-9. Acknowledgments
-
- This document was created from the input and ideas of the members of
- the DNS Extensions Working Group and working group mailing list. The
- editors would like to express their thanks for the comments and
- suggestions received during the revision of these security extension
- specifications. While explicitly listing everyone who has
- contributed during the decade during which DNSSEC has been under
- development would be an impossible task,
- [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
- participants who were kind enough to comment on these documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 27]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
- Mail Extensions) Part One: Mechanisms for Specifying and
- Describing the Format of Internet Message Bodies", RFC
- 1521, September 1993.
-
- [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
- August 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
- Name System (DNS)", RFC 3110, May 2001.
-
- [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
- Resource Record (RR)", RFC 3445, December 2002.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
- [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
- (RR)", RFC 3658, December 2003.
-
- [I-D.ietf-dnsext-dnssec-intro]
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 28]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "DNS Security Introduction and Requirements",
- draft-ietf-dnsext-dnssec-intro-09 (work in progress),
- February 2004.
-
- [I-D.ietf-dnsext-dnssec-protocol]
- Arends, R., Austein, R., Larson, M., Massey, D. and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in
- progress), February 2004.
-
- [I-D.ietf-dnsext-keyrr-key-signing-flag]
- Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
- Entry Point Flag",
- draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in
- progress), December 2003.
-
- [I-D.ietf-dnsext-dnssec-2535typecode-change]
- Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06
- (work in progress), December 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 29]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-Informative References
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Rob Austein
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- EMail: sra@isc.org
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
- Dan Massey
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.edu
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 30]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-8920
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 31]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-Appendix A. DNSSEC Algorithm and Digest Types
-
- The DNS security extensions are designed to be independent of the
- underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS
- resource records all use a DNSSEC Algorithm Number to identify the
- cryptographic algorithm in use by the resource record. The DS
- resource record also specifies a Digest Algorithm Number to identify
- the digest algorithm used to construct the DS record. The currently
- defined Algorithm and Digest Types are listed below. Additional
- Algorithm or Digest Types could be added as advances in cryptography
- warrant.
-
- A DNSSEC aware resolver or name server MUST implement all MANDATORY
- algorithms.
-
-A.1 DNSSEC Algorithm Types
-
- The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify
- the security algorithm being used. These values are stored in the
- "Algorithm number" field in the resource record RDATA.
-
- Some algorithms are usable only for zone signing (DNSSEC), some only
- for transaction security mechanisms (SIG(0) and TSIG), and some for
- both. Those usable for zone signing may appear in DNSKEY, RRSIG, and
- DS RRs. Those usable for transaction security would be present in
- SIG(0) and KEY RRs as described in [RFC2931]
-
- Zone
- Value Algorithm [Mnemonic] Signing References Status
- ----- -------------------- --------- ---------- ---------
- 0 reserved
- 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED
- 2 Diffie-Hellman [DH] n RFC 2539 -
- 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL
- 4 Elliptic Curve [ECC] TBA -
- 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY
- 252 Indirect [INDIRECT] n -
- 253 Private [PRIVATEDNS] y see below OPTIONAL
- 254 Private [PRIVATEOID] y see below OPTIONAL
- 255 reserved
-
- 6 - 251 Available for assignment by IETF Standards Action.
-
-A.1.1 Private Algorithm Types
-
- Algorithm number 253 is reserved for private use and will never be
- assigned to a specific algorithm. The public key area in the DNSKEY
- RR and the signature area in the RRSIG RR begin with a wire encoded
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 32]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- domain name, which MUST NOT be compressed. The domain name indicates
- the private algorithm to use and the remainder of the public key area
- is determined by that algorithm. Entities should only use domain
- names they control to designate their private algorithms.
-
- Algorithm number 254 is reserved for private use and will never be
- assigned to a specific algorithm. The public key area in the DNSKEY
- RR and the signature area in the RRSIG RR begin with an unsigned
- length byte followed by a BER encoded Object Identifier (ISO OID) of
- that length. The OID indicates the private algorithm in use and the
- remainder of the area is whatever is required by that algorithm.
- Entities should only use OIDs they control to designate their private
- algorithms.
-
-A.2 DNSSEC Digest Types
-
- A "Digest Type" field in the DS resource record types identifies the
- cryptographic digest algorithm used by the resource record. The
- following table lists the currently defined digest algorithm types.
-
- VALUE Algorithm STATUS
- 0 Reserved -
- 1 SHA-1 MANDATORY
- 2-255 Unassigned -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 33]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-Appendix B. Key Tag Calculation
-
- The Key Tag field in the RRSIG and DS resource record types provides
- a mechanism for selecting a public key efficiently. In most cases, a
- combination of owner name, algorithm, and key tag can efficiently
- identify a DNSKEY record. Both the RRSIG and DS resource records
- have corresponding DNSKEY records. The Key Tag field in the RRSIG
- and DS records can be used to help select the corresponding DNSKEY RR
- efficiently when more than one candidate DNSKEY RR is available.
-
- However, it is essential to note that the key tag is not a unique
- identifier. It is theoretically possible for two distinct DNSKEY RRs
- to have the same owner name, the same algorithm, and the same key
- tag. The key tag is used to limit the possible candidate keys, but it
- does not uniquely identify a DNSKEY record. Implementations MUST NOT
- assume that the key tag uniquely identifies a DNSKEY RR.
-
- The key tag is the same for all DNSKEY algorithm types except
- algorithm 1 (please see Appendix B.1 for the definition of the key
- tag for algorithm 1). The key tag algorithm is the sum of the wire
- format of the DNSKEY RDATA broken into 2 octet groups. First the
- RDATA (in wire format) is treated as a series of 2 octet groups,
- these groups are then added together ignoring any carry bits. A
- reference implementation of the key tag algorithm is as an ANSI C
- function is given below with the RDATA portion of the DNSKEY RR is
- used as input. It is not necessary to use the following reference
- code verbatim, but the numerical value of the Key Tag MUST be
- identical to what the reference implementation would generate for the
- same input.
-
- Please note that the algorithm for calculating the Key Tag is almost
- but not completely identical to the familiar ones complement checksum
- used in many other Internet protocols. Key Tags MUST be calculated
- using the algorithm described here rather than the ones complement
- checksum.
-
- The following ANSI C reference implementation calculates the value of
- a Key Tag. This reference implementation applies to all algorithm
- types except algorithm 1 (see Appendix B.1). The input is the wire
- format of the RDATA portion of the DNSKEY RR. The code is written
- for clarity, not efficiency.
-
- /*
- * Assumes that int is at least 16 bits.
- * First octet of the key tag is the most significant 8 bits of the
- * return value;
- * Second octet of the key tag is the least significant 8 bits of the
- * return value.
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 34]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- */
-
- unsigned int
- keytag (
- unsigned char key[], /* the RDATA part of the DNSKEY RR */
- unsigned int keysize /* the RDLENGTH */
- )
- {
- unsigned long ac; /* assumed to be 32 bits or larger */
- int i; /* loop index */
-
- for ( ac = 0, i = 0; i < keysize; ++i )
- ac += (i & 1) ? key[i] : key[i] << 8;
- ac += (ac >> 16) & 0xFFFF;
- return ac & 0xFFFF;
- }
-
-
-B.1 Key Tag for Algorithm 1 (RSA/MD5)
-
- The key tag for algorithm 1 (RSA/MD5) is defined differently than the
- key tag for all other algorithms, for historical reasons. For a
- DNSKEY RR with algorithm 1, the key tag is defined to be the most
- significant 16 bits of the least significant 24 bits in the public
- key modulus (in other words, the 4th to last and 3rd to last octets
- of the public key modulus).
-
- Please note that Algorithm 1 is NOT RECOMMENDED.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 35]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 36]
-\f
-Internet-Draft DNSSEC Resource Records February 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 16, 2004 [Page 37]
-\f
-
+++ /dev/null
-
-
-DNSEXT Working Group Levon Esibov
-INTERNET-DRAFT Bernard Aboba
-Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-29.txt> Microsoft
-20 January 2004
-
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC 2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-Today, with the rise of home networking, there are an increasing number
-of ad-hoc networks operating without a Domain Name System (DNS) server.
-In order to allow name resolution in such environments, Link-Local
-Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all
-current and future DNS formats, types and classes, while operating on a
-separate port from DNS, and with a distinct resolver cache.
-
-The goal of LLMNR is to enable name resolution in scenarios in which
-conventional DNS name resolution is not possible. Since LLMNR only
-operates on the local link, it cannot be considered a substitute for
-DNS.
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 3
- 1.2 Terminology ..................................... 4
-2. Name resolution using LLMNR ........................... 4
- 2.1 LLMNR packet format ............................. 5
- 2.2 Sender behavior ................................. 8
- 2.3 Responder behavior .............................. 8
- 2.4 Unicast queries ................................. 10
- 2.5 Off-link detection .............................. 11
- 2.6 Responder responsibilities ...................... 12
- 2.7 Retransmission and jitter ....................... 13
- 2.8 DNS TTL ......................................... 14
- 2.9 Use of the authority and additional sections .... 14
-3. Usage model ........................................... 14
- 3.1 LLMNR configuration ............................. 15
-4. Conflict resolution ................................... 16
- 4.1 Considerations for multiple interfaces .......... 18
- 4.2 API issues ...................................... 19
-5. Security considerations ............................... 20
- 5.1 Scope restriction ............................... 20
- 5.2 Usage restriction ............................... 21
- 5.3 Cache and port separation ....................... 22
- 5.4 Authentication .................................. 22
-6. IANA considerations ................................... 22
-7. References ............................................ 22
- 7.1 Normative References ............................ 22
- 7.2 Informative References .......................... 23
-Acknowledgments .............................................. 24
-Authors' Addresses ........................................... 25
-Intellectual Property Statement .............................. 25
-Full Copyright Statement ..................................... 26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-1. Introduction
-
-This document discusses Link Local Multicast Name Resolution (LLMNR),
-which utilizes the DNS packet format and supports all current and future
-DNS formats, types and classes. LLMNR operates on a separate port from
-the Domain Name System (DNS), with a distinct resolver cache.
-
-The goal of LLMNR is to enable name resolution in scenarios in which
-conventional DNS name resolution is not possible. These include
-scenarios in which hosts are not configured with the address of a DNS
-server, where configured DNS servers do not reply to a query, or where
-they respond with errors, as described in Section 2. Since LLMNR only
-operates on the local link, it cannot be considered a substitute for
-DNS.
-
-Link-scope multicast addresses are used to prevent propagation of LLMNR
-traffic across routers, potentially flooding the network. LLMNR queries
-can also be sent to a unicast address, as described in Section 2.4.
-
-Propagation of LLMNR packets on the local link is considered sufficient
-to enable name resolution in small networks. The assumption is that if
-a network has a gateway, then the network is able to provide DNS server
-configuration. Configuration issues are discussed in Section 3.1.
-
-In the future, it may be desirable to consider use of multicast name
-resolution with multicast scopes beyond the link-scope. This could
-occur if LLMNR deployment is successful, the need for multicast name
-resolution beyond the link-scope, or multicast routing becomes
-ubiquitous. For example, expanded support for multicast name resolution
-might be required for mobile ad-hoc networking scenarios, or where no
-DNS server is available that is authoritative for the names of local
-hosts, and can support dynamic DNS, such as in wireless hotspots.
-
-Once we have experience in LLMNR deployment in terms of administrative
-issues, usability and impact on the network, it will be possible to
-reevaluate which multicast scopes are appropriate for use with multicast
-name resolution.
-
-Service discovery in general, as well as discovery of DNS servers using
-LLMNR in particular, is outside of the scope of this document, as is
-name resolution over non-multicast capable media.
-
-1.1. Requirements
-
-In this document, several words are used to signify the requirements of
-the specification. These words are often capitalized. The key words
-"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
-NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-interpreted as described in [RFC2119].
-
-1.2. Terminology
-
-This document assumes familiarity with DNS terminology defined in
-[RFC1035]. Other terminology used in this document includes:
-
-Positively Resolved
- Responses with RCODE set to zero are referred to in this document
- as "positively resolved".
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An address is considered reachable over a link if either an ARP or
- neighbor discovery cache entry exists for the address on the link.
-
-Responder
- A host that listens to LLMNR queries, and responds to those for
- which it is authoritative.
-
-Sender
- A host that sends an LLMNR query.
-
-2. Name resolution using LLMNR
-
-LLMNR is a peer-to-peer name resolution protocol that is not intended as
-a replacement for DNS. LLMNR queries are sent to and received on port
-TBD. IPv4 administratively scoped multicast usage is specified in
-"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope
-multicast address a given responder listens to, and to which a sender
-sends queries, is TBD. The IPv6 link-scope multicast address a given
-responder listens to, and to which a sender sends all queries, is TBD.
-
-Typically a host is configured as both an LLMNR sender and a responder.
-A host MAY be configured as a sender, but not a responder. However, a
-host configured as a responder MUST act as a sender to verify the
-uniqueness of names as described in Section 4. This document does not
-specify how names are chosen or configured. This may occur via any
-mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].
-
-LLMNR usage MAY be configured manually or automatically on a per
-interface basis. By default, LLMNR responders SHOULD be enabled on all
-interfaces, at all times. Enabling LLMNR for use in situations where a
-DNS server has been configured will result in a change in default
-behavior without a simultaneous update to configuration information.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Where this is considered undesirable, LLMNR SHOULD NOT be enabled by
-default, so that hosts will neither listen on the link-scope multicast
-address, nor will they send queries to that address.
-
-An LLMNR sender may send a request for any name. However, by default,
-LLMNR requests SHOULD be sent only when one of the following conditions
-are met:
-
-[1] No manual or automatic DNS configuration has been performed. If an
- interface has been configured with DNS server address(es), then
- LLMNR SHOULD NOT be used as the primary name resolution mechanism
- on that interface, although it MAY be used as a name resolution
- mechanism of last resort.
-
-[2] DNS servers do not respond.
-
-[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section.
-
-A typical sequence of events for LLMNR usage is as follows:
-
-[a] DNS servers are not configured or do not respond to a DNS query, or
- respond with RCODE=3, or RCODE=0 and an empty answer section.
-
-[b] An LLMNR sender sends an LLMNR query to the link-scope multicast
- address(es) defined in Section 2, unless a unicast query is
- indicated. A sender SHOULD send LLMNR queries for PTR RRs via
- unicast, as specified in Section 2.4.
-
-[c] A responder responds to this query only if it is authoritative for
- the domain name in the query. A responder responds to a multicast
- query by sending a unicast UDP response to the sender. Unicast
- queries are responded to as indicated in Section 2.4.
-
-[d] Upon reception of the response, the sender processes it.
-
-Further details of sender and responder behavior are provided in the
-sections that follow.
-
-2.1. LLMNR packet format
-
-LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for
-both queries and responses. LLMNR implementations SHOULD send UDP
-queries and responses only as large as are known to be permissible
-without causing fragmentation. When in doubt a maximum packet size of
-512 octets SHOULD be used. LLMNR implementations MUST accept UDP
-queries and responses as large as permitted by the link MTU.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-2.1.1. LLMNR header format
-
-LLMNR queries and responses utilize the DNS header format defined in
-[RFC1035] with exceptions noted below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| ID |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| QDCOUNT |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| ANCOUNT |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| NSCOUNT |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-| ARCOUNT |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value.
-
-QR A one bit field that specifies whether this message is an LLMNR
- query (0), or an LLMNR response (1).
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set an LLMNR response,
- then the sender MAY use the response if it contains all necessary
- information, or the sender MAY discard the response and resend the
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
- LLMNR query over TCP using the unicast address of the responder as
- the destination address. See [RFC2181] and Section 2.4 of this
- specification for further discussion of the TC bit.
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the RCODE MUST be zero, and is
- ignored by the responder. The response to a multicast LLMNR query
- MUST have RCODE set to zero. A sender MUST silently discard an
- LLMNR response with a non-zero RCODE sent in response to a
- multicast query.
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferrable to
- not sending a response, since it enables errors to be diagnosed.
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender behavior
-
-A sender may send an LLMNR query for any legal resource record type
-(e.g. A, AAAA, SRV, etc.) to the link-scope multicast address.
-
-As described in Section 2.4, a sender may also send a unicast query.
-Sections 2 and 3 describe the circumstances in which LLMNR queries may
-be sent.
-
-The sender MUST anticipate receiving no replies to some LLMNR queries,
-in the event that no responders are available within the link-scope or
-in the event no positive non-null responses exist for the transmitted
-query. If no positive response is received, a resolver treats it as a
-response that no records of the specified type and class exist for the
-specified name (it is treated the same as a response with RCODE=0 and an
-empty answer section).
-
-Since the responder may order the RRs in the response so as to indicate
-preference, the sender SHOULD preserve ordering in the response to the
-querying application.
-
-2.3. Responder behavior
-
-An LLMNR response MUST be sent to the sender via unicast.
-
-Upon configuring an IP address responders typically will synthesize
-corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR
-queries for these RRs. An SOA RR is synthesized only when a responder
-has another RR as well; the SOA RR MUST NOT be the only RR that a
-responder has. However, in general whether RRs are manually or
-automatically created is an implementation decision.
-
-For example, a host configured to have computer name "host1" and to be a
-member of the "example.com" domain, and with IPv4 address 10.1.1.1 and
-IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the
-following records:
-
-host1. IN A 10.1.1.1
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-host1.example.com. IN A 10.1.1.1
-IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-1.1.1.10.in-addr.arpa. IN PTR host1.
-IN PTR host1.example.com.
-
-6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
-IN PTR host1.
-IN PTR host1.example.com
-
-An LLMNR responder might be further manually configured with the name of
-a local mail server with an MX RR included in the "host1." and
-"host1.example.com." records.
-
-In responding to queries:
-
-[a] Responders MUST listen on UDP port TBD on the link-scope multicast
- address(es) defined in Section 2, and on UDP and TCP port TBD on
- the unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses SHOULD always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-[e] Responders MUST NOT respond using cached data.
-
-[f] If a DNS server is running on a host that supports LLMNR, the DNS
- server MUST respond to LLMNR queries only for the RRSets relating
- to the host on which the server is running, but MUST NOT respond
- for other records for which the server is authoritative. DNS
- servers also MUST NOT send LLMNR queries in order to resolve DNS
- queries.
-
-[g] If a responder is authoritative for a name, it MAY respond with
- RCODE=0 and an empty answer section, if the type of query does not
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
- match a RR that the responder has.
-
-As an example, a host configured to respond to LLMNR queries for the
-name "foo.example.com." is authoritative for the name
-"foo.example.com.". On receiving an LLMNR query for an A RR with the
-name "foo.example.com." the host authoritatively responds with A RR(s)
-that contain IP address(es) in the RDATA of the resource record. If the
-responder has a AAAA RR, but no A RR, and an A RR query is received, the
-responder would respond with RCODE=0 and an empty answer section.
-
-In conventional DNS terminology a DNS server authoritative for a zone is
-authoritative for all the domain names under the zone apex except for
-the branches delegated into separate zones. Contrary to conventional
-DNS terminology, an LLMNR responder is authoritative only for the zone
-apex.
-
-For example the host "foo.example.com." is not authoritative for the
-name "child.foo.example.com." unless the host is configured with
-multiple names, including "foo.example.com." and
-"child.foo.example.com.". As a result, "foo.example.com." cannot reply
-to an LLMNR query for "child.foo.example.com." with RCODE=3
-(authoritative name error). The purpose of limiting the name authority
-scope of a responder is to prevent complications that could be caused by
-coexistence of two or more hosts with the names representing child and
-parent (or grandparent) nodes in the DNS tree, for example,
-"foo.example.com." and "child.foo.example.com.".
-
-In this example (unless this limitation is introduced) an LLMNR query
-for an A resource record for the name "child.foo.example.com." would
-result in two authoritative responses: RCODE=3 (authoritative name
-error) received from "foo.example.com.", and a requested A record - from
-"child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
-hosts could perform a dynamic update of the parent (or grandparent) zone
-with a delegation to a child zone. In this example a host
-"child.foo.example.com." would send a dynamic update for the NS and glue
-A record to "foo.example.com.", but this approach significantly
-complicates implementation of LLMNR and would not be acceptable for
-lightweight hosts.
-
-2.4. Unicast queries and responses
-
-Unicast queries SHOULD be sent when:
-
-[a] A sender repeats a query after it received a response with the TC
- bit set to the previous LLMNR multicast query, or
-
-[b] The sender queries for a PTR RR of a fully formed IP address within
- the "in-addr.arpa" or "ip6.arpa" zones.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-A responder receiving a unicast query MUST send the response with a
-source address set to the destination address field of the IP header of
-the query causing the response.
-
-Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support
-sending TCP queries, and responders MUST support listening for TCP
-queries.
-
-Responses to TCP unicast LLMNR queries MUST be sent using TCP, using
-the same connection as the query. If the sender of a TCP query receives
-a response to that query not using TCP, the response MUST be silently
-discarded.
-
-Unicast UDP queries MAY be responded to with a UDP response containing
-an empty answer section and the TC bit set, so as to require the sender
-to resend the query using TCP.
-
-If an ICMP "Time Exceeded" message is received in response to a unicast
-UDP query, or if TCP connection setup cannot be completed in order to
-send a unicast TCP query, this is treated as a response that no records
-of the specified type and class exist for the specified name (it is
-treated the same as a response with RCODE=0 and an empty answer
-section). The UDP sender receiving an ICMP "Time Exceeded" message
-SHOULD verify that the ICMP error payload contains a valid LLMNR query
-packet, which matches a query that is currently in progress, so as to
-guard against a potential Denial of Service (DoS) attack. If a match
-cannot be made, then the sender relies on the retransmission and timeout
-behavior described in Section 2.7.
-
-2.5. "Off link" detection
-
-For IPv4, an "on link" address is defined as a link-local address
-[IPv4Link] or an address whose prefix belongs to a subnet on the local
-link. For IPv6 [RFC2460] an "on link" address is either a link-local
-address, defined in [RFC2373], or an address whose prefix belongs to a
-subnet on the local link.
-
-A sender MUST select a source address for LLMNR queries that is "on
-link". The destination address of an LLMNR query MUST be a link-scope
-multicast address or an "on link" unicast address.
-
-A responder MUST select a source address for responses that is "on
-link". The destination address of an LLMNR response MUST be an "on link"
-unicast address.
-
-On receiving an LLMNR query, the responder MUST check whether it was
-sent to a LLMNR multicast addresses defined in Section 2. If it was
-sent to another multicast address, then the query MUST be silently
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-discarded.
-
-In composing LLMNR queries, the sender MUST set the Hop Limit field in
-the IPv6 header and the TTL field in IPv4 header of the response to one
-(1). Even when LLMNR queries are sent to a link-scope multicast
-address, it is possible that some routers may not properly implement
-link-scope multicast, or that link-scope multicast addresses may leak
-into the multicast routing system. Therefore setting the IPv6 Hop Limit
-or IPv4 TTL field to one provides an additional precaution against
-leakage of LLMNR queries.
-
-In composing a response to an LLMNR query, the responder MUST set the
-Hop Limit field in the IPv6 header and the TTL field in IPv4 header of
-the response to one (1). This is done so as to prevent the use of LLMNR
-for denial of service attacks across the Internet.
-
-Section 2.4 discusses use of TCP for LLMNR queries and responses. The
-responder SHOULD set the TTL or Hop Limit settings on the TCP listen
-socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop
-Limit (IPv6) set to one (1). This prevents an incoming connection from
-off-link since the sender will not receive a SYN-ACK from the responder.
-
-Implementation note:
-
- In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL
- socket options are used to set the TTL of outgoing unicast and
- multicast packets. The IP_RECVTTL socket option is available on some
- platforms to retrieve the IPv4 TTL of received packets with
- recvmsg(). [RFC2292] specifies similar options for setting and
- retrieving the IPv6 Hop Limit.
-
-2.6. Responder responsibilities
-
-It is the responsibility of the responder to ensure that RRs returned in
-LLMNR responses MUST only include values that are valid on the local
-interface, such as IPv4 or IPv6 addresses valid on the local link or
-names defended using the mechanism described in Section 4. In
-particular:
-
-[a] If a link-scope IPv6 address is returned in a AAAA RR, that address
- MUST be valid on the local link over which LLMNR is used.
-
-[b] If an IPv4 address is returned, it MUST be reachable through the
- link over which LLMNR is used.
-
-[c] If a name is returned (for example in a CNAME, MX or SRV RR), the
- name MUST be resolvable on the local link over which LLMNR is used.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Routable addresses MUST be included first in the response, if available.
-This encourages use of routable address(es) for establishment of new
-connections.
-
-2.7. Retransmission and jitter
-
-An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
-when to retransmit an LLMNR query and how long to collect responses to
-an LLMNR query.
-
-If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
-then a sender MAY repeat the transmission of the query in order to
-assure that it was received by a host capable of responding to it.
-Retransmission of UDP queries SHOULD NOT be attempted more than 3 times.
-Where LLMNR queries are sent using TCP, retransmission is handled by the
-transport layer.
-
-Because an LLMNR sender cannot know in advance if a query sent using
-multicast will receive no response, one response, or more than one
-response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect
-all possible responses, rather than considering the multicast query
-answered after the first response is received. A unicast query sender
-considers the query answered after the first response is received, so
-that it only waits for LLMNR_TIMEOUT if no response has been received.
-
-An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
-for each transmission. It is suggested that the computation of
-LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries
-sent on the same interface.
-
-For example, the algorithms described in RFC 2988 [RFC2988] (including
-exponential backoff) to compute an RTO, which is used as the value of
-LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed
-in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in
-Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed
-in Section 2 of [RFC2988], paragraph 2.5).
-
-Recommended values are an initial RTO of 1 second, a minimum RTO of
-200ms, and a maximum RTO of 5 seconds. In order to avoid
-synchronization, the transmission of each LLMNR query and response
-SHOULD delayed by a time randomly selected from the interval 0 to 100
-ms. This delay MAY be avoided by responders responding with RRs which
-they have previously determined to be UNIQUE (see Section 4 for
-details).
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-2.8. DNS TTL
-
-The responder should use a pre-configured TTL value in the records
-returned an LLMNR response. A default value of 30 seconds is
-RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
-networks), the TTL value may need to be reduced.
-
-Due to the TTL minimalization necessary when caching an RRset, all TTLs
-in an RRset MUST be set to the same value.
-
-2.9. Use of the authority and additional sections
-
-Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
-concept of delegation. In LLMNR, the NS resource record type may be
-stored and queried for like any other type, but it has no special
-delegation semantics as it does in the DNS. Responders MAY have NS
-records associated with the names for which they are authoritative, but
-they SHOULD NOT include these NS records in the authority sections of
-responses.
-
-Responders SHOULD insert an SOA record into the authority section of a
-negative response, to facilitate negative caching as specified in
-[RFC2308]. The owner name of this SOA record MUST be equal to the query
-name.
-
-Responders SHOULD NOT perform DNS additional section processing, except
-as required for EDNS0 and DNSSEC.
-
-Senders MUST NOT cache RRs from the authority or additional section of a
-response as answers, though they may be used for other purposes such as
-negative caching.
-
-3. Usage model
-
-Since LLMNR is a secondary name resolution mechanism, its usage is in
-part determined by the behavior of DNS implementations. This document
-does not specify any changes to DNS resolver behavior, such as
-searchlist processing or retransmission/failover policy. However,
-robust DNS resolver implementations are more likely to avoid unnecessary
-LLMNR queries.
-
-As noted in [DNSPerf], even when DNS servers are configured, a
-significant fraction of DNS queries do not receive a response, or result
-in negative responses due to missing inverse mappings or NS records that
-point to nonexistent or inappropriate hosts. This has the potential to
-result in a large number of unnecessary LLMNR queries.
-
-[RFC1536] describes common DNS implementation errors and fixes. If the
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-proposed fixes are implemented, unnecessary LLMNR queries will be
-reduced substantially, and so implementation of [RFC1536] is
-recommended.
-
-For example, [RFC1536] Section 1 describes issues with retransmission
-and recommends implementation of a retransmission policy based on round
-trip estimates, with exponential backoff. [RFC1536] Section 4 describes
-issues with failover, and recommends that resolvers try another server
-when they don't receive a response to a query. These policies are
-likely to avoid unnecessary LLMNR queries.
-
-[RFC1536] Section 3 describes zero answer bugs, which if addressed will
-also reduce unnecessary LLMNR queries.
-
-[RFC1536] Section 6 describes name error bugs and recommended searchlist
-processing that will reduce unnecessary RCODE=3 (authoritative name)
-errors, thereby also reducing unnecessary LLMNR queries.
-
-3.1. LLMNR configuration
-
-Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
-possible for a dual stack host to be configured with the address of a
-DNS server over IPv4, while remaining unconfigured with a DNS server
-suitable for use over IPv6.
-
-In these situations, a dual stack host will send AAAA queries to the
-configured DNS server over IPv4. However, an IPv6-only host
-unconfigured with a DNS server suitable for use over IPv6 will be unable
-to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms
-(such as [RFC3315] and [DNSDisc]) are not yet widely deployed, and not
-all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration
-may be a common problem in the short term, and LLMNR may prove useful in
-enabling linklocal name resolution over IPv6.
-
-Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
-IPv6-only hosts may not be configured with a DNS server. Where there is
-no DNS server authoritative for the name of a host or the authoritative
-DNS server does not support dynamic client update over IPv6 or
-DHCPv6-based dynamic update, then an IPv6-only host will not be able to
-do DNS dynamic update, and other hosts will not be able to resolve its
-name.
-
-For example, if the configured DNS server responds to AAAA RR queries
-sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then
-it will not be possible to resolve the names of IPv6-only hosts. In
-this situation, LLMNR over IPv6 can be used for local name resolution.
-
-Similarly, if a DHCPv4 server is available providing DNS server
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-configuration, and DNS server(s) exist which are authoritative for the A
-RRs of local hosts and support either dynamic client update over IPv4 or
-DHCPv4-based dynamic update, then the names of local IPv4 hosts can be
-resolved over IPv4 without LLMNR. However, if no DNS server is
-authoritative for the names of local hosts, or the authoritative DNS
-server(s) do not support dynamic update, then LLMNR enables linklocal
-name resolution over IPv4.
-
-Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-configure LLMNR on an interface. The LLMNR Enable Option, described in
-[LLMNREnable], can be used to explicitly enable or disable use of LLMNR
-on an interface. The LLMNR Enable Option does not determine whether or
-in which order DNS itself is used for name resolution. The order in
-which various name resolution mechanisms should be used can be specified
-using the Name Service Search Option (NSSO) for DHCP [RFC2937], using
-the LLMNR Enable Option code carried in the NSSO data.
-
-It is possible that DNS configuration mechanisms will go in and out of
-service. In these circumstances, it is possible for hosts within an
-administrative domain to be inconsistent in their DNS configuration.
-
-For example, where DHCP is used for configuring DNS servers, one or more
-DHCP servers can fail. As a result, hosts configured prior to the
-outage will be configured with a DNS server, while hosts configured
-after the outage will not. Alternatively, it is possible for the DNS
-configuration mechanism to continue functioning while configured DNS
-servers fail.
-
-Unless unconfigured hosts periodically retry configuration, an outage in
-the DNS configuration mechanism will result in hosts continuing to use
-LLMNR even once the outage is repaired. Since LLMNR only enables
-linklocal name resolution, this represents an unnecessary degradation in
-capabilities. As a result, it is recommended that hosts without a
-configured DNS server periodically attempt to obtain DNS configuration.
-For example, where DHCP is used for DNS configuration, [RFC2131]
-recommends a maximum retry interval of 64 seconds. In the absence of
-other guidance, a default retry interval of one (1) minute is
-RECOMMENDED.
-
-4. Conflict resolution
-
-The sender MUST anticipate receiving multiple replies to the same LLMNR
-query, in the event that several LLMNR enabled computers receive the
-query and respond with valid answers. When this occurs, the responses
-may first be concatenated, and then treated in the same manner that
-multiple RRs received from the same DNS server would; the sender
-perceives no inherent conflict in the receipt of multiple responses.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-There are some scenarios when multiple responders MAY respond to the
-same query. There are other scenarios when only one responder MAY
-respond to a query. Resource records for which the latter queries are
-submitted are referred as UNIQUE throughout this document. The
-uniqueness of a resource record depends on a nature of the name in the
-query and type of the query. For example it is expected that:
-
- - multiple hosts may respond to a query for an SRV type record
- - multiple hosts may respond to a query for an A or AAAA type
- record for a cluster name (assigned to multiple hosts in
- the cluster)
- - only a single host may respond to a query for an A or AAAA
- type record for a name.
-
-Every responder that responds to an LLMNR query AND includes a UNIQUE
-record in the response:
-
-[1] MUST verify that there is no other host within the scope of the
- LLMNR query propagation that can return a resource record for the
- same name, type and class.
-
-[2] MUST NOT include a UNIQUE resource record in the response without
- having verified its uniqueness.
-
-Where a host is configured to issue LLMNR queries on more than one
-interface, each interface should have its own independent LLMNR cache.
-For each UNIQUE resource record in a given interface's configuration,
-the host MUST verify resource record uniqueness on that interface. To
-accomplish this, the host MUST send an LLMNR query for each UNIQUE
-resource record.
-
-By default, a host SHOULD be configured to behave as though all RRs are
-UNIQUE. Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive during sleep)
- - is configured to respond to the LLMNR queries on an interface
- enabled for transmission and reception of IP traffic
- - is configured to respond to the LLMNR queries using additional
- UNIQUE resource records
- - detects that an interface is connected and is usable
- (e.g. an IEEE 802 hardware link-state change indicating
- that a cable was attached or that an association has occurred
- with a wireless base station and that any required authentication
- has completed)
-
-When a host that has a UNIQUE record receives an LLMNR query for that
-record, the host MUST respond. After the client receives a response, it
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-MUST check whether the response arrived on an interface different from
-the one on which the query was sent. If the response arrives on a
-different interface, the client can use the UNIQUE resource record in
-response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
-resource record in response to LLMNR queries.
-
-The name conflict detection mechanism doesn't prevent name conflicts
-when previously partitioned segments are connected by a bridge. In order
-to minimize the chance of conflicts in such a situation, it is
-recommended that steps be taken to ensure name uniqueness. For example,
-the name could be chosen randomly from a large pool of potential names,
-or the name could be assigned via a process designed to guarantee
-uniqueness.
-
-When name conflicts are detected, they SHOULD be logged. To detect
-duplicate use of a name, an administrator can use a name resolution
-utility which employs LLMNR and lists both responses and responders.
-This would allow an administrator to diagnose behavior and potentially
-to intervene and reconfigure LLMNR responders who should not be
-configured to respond to the same name.
-
-4.1. Considerations for Multiple Interfaces
-
-A multi-homed host may elect to configure LLMNR on only one of its
-active interfaces. In many situations this will be adequate. However,
-should a host need to configure LLMNR on more than one of its active
-interfaces, there are some additional precautions it MUST take.
-Implementers who are not planning to support LLMNR on multiple
-interfaces simultaneously may skip this section.
-
-A multi-homed host checks the uniqueness of UNIQUE records as described
-in Section 4. The situation is illustrated in figure 1.
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
-In this situation, the multi-homed myhost will probe for, and defend,
-its host name on both interfaces. A conflict will be detected on one
-interface, but not the other. The multi-homed myhost will not be able
-to respond with a host RR for "myhost" on the interface on the right
-(see Figure 1). The multi-homed host may, however, be configured to use
-the "myhost" name on the interface on the left.
-
-Since names are only unique per-link, hosts on different links could be
-using the same name. If an LLMNR client sends requests over multiple
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-interfaces, and receives replies from more than one, the result returned
-to the client is defined by the implementation. The situation is
-illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
-If host myhost is configured to use LLMNR on both interfaces, it will
-send LLMNR queries on both interfaces. When host myhost sends a query
-for the host RR for name "A" it will receive a response from hosts on
-both interfaces.
-
-Host myhost cannot distinguish between the situation shown in Figure 2,
-and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
-This illustrates that the proposed name conflict resolution mechanism
-does not support detection or resolution of conflicts between hosts on
-different links. This problem can also occur with unicast DNS when a
-multi-homed host is connected to two different networks with separated
-name spaces. It is not the intent of this document to address the issue
-of uniqueness of names within DNS.
-
-4.2. API issues
-
-[RFC2553] provides an API which can partially solve the name ambiguity
-problem for applications written to use this API, since the sockaddr_in6
-structure exposes the scope within which each scoped address exists, and
-this structure can be used for both IPv4 (using v4-mapped IPv6
-addresses) and IPv6 addresses.
-
-Following the example in Figure 2, an application on 'myhost' issues the
-request getaddrinfo("A", ...) with ai_family=AF_INET6 and
-ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
-interfaces and the resolver library will return a list containing
-multiple addrinfo structures, each with an associated sockaddr_in6
-structure. This list will thus contain the IPv4 and IPv6 addresses of
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-both hosts responding to the name 'A'. Link-local addresses will have a
-sin6_scope_id value that disambiguates which interface is used to reach
-the address. Of course, to the application, Figures 2 and 3 are still
-indistinguishable, but this API allows the application to communicate
-successfully with any address in the list.
-
-5. Security Considerations
-
-LLMNR is by nature a peer-to-peer name resolution protocol. It is
-therefore inherently more vulnerable than DNS, since existing DNS
-security mechanisms are difficult to apply to LLMNR. While tools exist
-to alllow an attacker to spoof a response to a DNS query, spoofing a
-response to an LLMNR query is easier since the query is sent to a link-
-scope multicast address, where every host on the logical link will be
-made aware of it.
-
-In order to address the security vulnerabilities, the following
-mechanisms are contemplated:
-
-[1] Scope restrictions.
-
-[2] Usage restrictions.
-
-[3] Cache and port separation.
-
-[4] Authentication.
-
-These techniques are described in the following sections.
-
-5.1. Scope restriction
-
-With LLMNR it is possible that hosts will allocate conflicting names for
-a period of time, or that attackers will attempt to deny service to
-other hosts by allocating the same name. Such attacks also allow hosts
-to receive packets destined for other hosts.
-
-Since LLMNR is typically deployed in situations where no trust model can
-be assumed, it is likely that LLMNR queries and responses will be
-unauthenticated. In the absence of authentication, LLMNR reduces the
-exposure to such threats by utilizing queries sent to a link-scope
-multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
-fields to one (1) on both queries and responses.
-
-A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can
-be used to launch denial of service attacks. For example, were the TTL
-of an LLMNR Response to be set to a value larger than one (1), an
-attacker could send a large volume of queries from a spoofed source
-address, causing an off-link target to be deluged with responses.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Utilizing a TTL of one (1) in LLMNR responses ensures that they will not
-be forwarded off-link. Using a TTL of one (1) to set up a TCP connection
-in order to send a unicast LLMNR query reduces the likelihood of both
-denial of service attacks and spoofed responses. Checking that an LLMNR
-query is sent to a link-scope multicast address should prevent spoofing
-of multicast queries by off-link attackers.
-
-While this limits the ability of off-link attackers to spoof LLMNR
-queries and responses, it does not eliminate it. For example, it is
-possible for an attacker to spoof a response to a frequent query (such
-as an A or AAAA query for a popular Internet host), and by using a TTL
-or Hop Limit field larger than one (1), for the forged response to reach
-the LLMNR sender.
-
-There also are scenarios such as public "hotspots" where attackers can
-be present on the same link. These threats are most serious in wireless
-networks such as 802.11, since attackers on a wired network will require
-physical access to the home network, while wireless attackers may reside
-outside the home. Link-layer security can be of assistance against
-these threats if it is available.
-
-5.2. Usage restriction
-
-As noted in Sections 2 and 3, LLMNR is intended for usage in a limited
-set of scenarios.
-
-If an LLMNR query is sent whenever a DNS server does not respond in a
-timely way, then an attacker can poison the LLMNR cache by responding to
-the query with incorrect information. To some extent, these
-vulnerabilities exist today, since DNS response spoofing tools are
-available that can allow an attacker to respond to a query more quickly
-than a distant DNS server.
-
-Since LLMNR queries are sent and responded to on the local-link, an
-attacker will need to respond more quickly to provide its own response
-prior to arrival of the response from a legitimate responder. If an
-LLMNR query is sent for an off-link host, spoofing a response in a
-timely way is not difficult, since a legitimate response will never be
-received.
-
-The vulnerability is more serious if LLMNR is given higher priority than
-DNS among the enabled name resolution mechanisms. In such a
-configuration, a denial of service attack on the DNS server would not be
-necessary in order to poison the LLMNR cache, since LLMNR queries would
-be sent even when the DNS server is available. In addition, the LLMNR
-cache, once poisoned, would take precedence over the DNS cache,
-eliminating the benefits of cache separation. As a result, LLMNR is only
-used as a name resolution mechanism of last resort.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-5.3. Cache and port separation
-
-In order to prevent responses to LLMNR queries from polluting the DNS
-cache, LLMNR implementations MUST use a distinct, isolated cache for
-LLMNR on each interface. The use of separate caches is most effective
-when LLMNR is used as a name resolution mechanism of last resort, since
-this minimizes the opportunities for poisoning the LLMNR cache, and
-decreases reliance on it.
-
-LLMNR operates on a separate port from DNS, reducing the likelihood that
-a DNS server will unintentionally respond to an LLMNR query.
-
-5.4. Authentication
-
-LLMNR implementations may not support DNSSEC or TSIG, and as a result,
-responses to LLMNR queries may be unauthenticated. If authentication is
-desired, and a pre-arranged security configuration is possible, then
-IPsec ESP with a null-transform MAY be used to authenticate LLMNR
-responses. In a small network without a certificate authority, this can
-be most easily accomplished through configuration of a group pre-shared
-key for trusted hosts.
-
-6. IANA Considerations
-
-This specification creates one new name space: the reserved bits in the
-LLMNR header. These are allocated by IETF Consensus, in accordance with
-BCP 26 [RFC2434].
-
-LLMNR requires allocation of a port TBD for both TCP and UDP.
-Assignment of the same port for both transports is requested.
-
-LLMNR requires allocation of a link-scope multicast IPv4 address TBD.
-LLMNR also requires allocation of a link-scope multicast IPv6 address
-TBD.
-
-7. References
-
-7.1. Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 2460, December 1998.
-
-[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
- Timer", RFC 2988, November 2000.
-
-7.2. Informative References
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
- Caching", IEEE/ACM Transactions on Networking, Volume 10,
- Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- Internet draft (work in progress), draft-ietf-ipv6-dns-
- discovery-07.txt, October 2002.
-
-[IPV4Link]
- Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of IPv4 Link-Local Addresses", Internet draft (work in
- progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October
- 2003.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[NodeInfo]
- Crawford, M., "IPv6 Node Information Queries", Internet draft
- (work in progress), draft-ietf-ipn-gwg-icmp-name-
- lookups-09.txt, May 2002.
-
-Acknowledgments
-
-This work builds upon original work done on multicast DNS by Bill
-Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
-grant #F30602-99-1-0523. The authors gratefully acknowledge their
-contribution to the current specification. Constructive input has also
-been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert
-Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron
-Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van-
-Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku
-Savela.
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Authors' Addresses
-
-Levon Esibov
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-EMail: levone@microsoft.com
-
-Bernard Aboba
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-Phone: +1 425 706 6605
-EMail: bernarda@microsoft.com
-
-Dave Thaler
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-Phone: +1 425 703 8835
-EMail: dthaler@microsoft.com
-
-Intellectual Property Statement
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-rights made available for publication and any assurances of licenses to
-be made available, or the result of an attempt made to obtain a general
-license or permission for the use of such proprietary rights by
-implementors or users of this specification can be obtained from the
-IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-which may cover technology that may be required to practice this
-standard. Please address the information to the IETF Executive
-Director.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 20 January 2004
-
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (2004). All Rights Reserved.
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it or
-assist in its implementation may be prepared, copied, published and
-distributed, in whole or in part, without restriction of any kind,
-provided that the above copyright notice and this paragraph are included
-on all such copies and derivative works. However, this document itself
-may not be modified in any way, such as by removing the copyright notice
-or references to the Internet Society or other Internet organizations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet
-Standards process must be followed, or as required to translate it into
-languages other than English. The limited permissions granted above are
-perpetual and will not be revoked by the Internet Society or its
-successors or assigns. This document and the information contained
-herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
-INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Open Issues
-
-Open issues with this specification are tracked on the following web
-site:
-
-http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-Expiration Date
-
-This memo is filed as <draft-ietf-dnsext-mdns-29.txt>, and expires
-August 4, 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 26]
-
+++ /dev/null
-
-
-DNS Extensions Working Group J. Schlyter, Ed.
-Internet-Draft March 11, 2004
-Updates: RFC 2535, RFC TCR
-Expires: September 9, 2004
-
-
- DNSSEC NSEC RDATA Format
- draft-ietf-dnsext-nsec-rdata-05.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 9, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document redefines the wire format of the "Type Bit Map" field
- in the NSEC resource record RDATA format to cover the full RR type
- space.
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 1]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3
- 2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4
- 2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4
- 2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4
- 2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5
- 2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5
- 2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 6
- 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
- 4. Security Considerations . . . . . . . . . . . . . . . . . . 6
- Normative References . . . . . . . . . . . . . . . . . . . . 6
- Informational References . . . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
- A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
- Intellectual Property and Copyright Statements . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 2]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-1. Introduction
-
- The NSEC [6] Resource Record (RR) is used for authenticated proof of
- the non-existence of DNS owner names and types. The NSEC RR is based
- on the NXT RR as described in RFC 2535 [3], and is similar except for
- the name and typecode. The RDATA format for the NXT RR had a
- limitation in that, without using a yet undefined extension
- mechanism, the the RDATA could only carry information about the
- existence of the first 127 types.
-
- To prevent the introduction of an extension mechanism into a deployed
- base of DNSSEC aware servers and resolvers, once the first 127 type
- codes are allocated, this document redefines the wire format of the
- "Type Bit Map" field in the NSEC RDATA to cover the full RR type
- space.
-
- This document introduces a new format for the type bit map. The
- properties of the type bit map format are that it can cover the full
- possible range of typecodes, that it is relatively economic in the
- amount of space it uses for the common case of a few types with an
- owner name, that it can represent owner names with all possible types
- present in packets of approximately 8.5 kilobytes and that the
- representation is simple to implement. Efficient searching of the
- type bitmap for the presence of certain types is not a requirement.
-
- For convenience and completeness this document presents the syntax
- and semantics for the NSEC RR based on the specification in RFC 2535
- [3] and as updated by RFC TCR [6], thereby not introducing changes
- except for the syntax of the type bit map.
-
- This document updates RFC 2535 [3] and RFC TCR [6].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [1].
-
-2. The NSEC Resource Record
-
- The NSEC resource record lists two separate things: the owner name of
- the next RRset in the canonical ordering of the zone, and the set of
- RR types present at the NSEC RR's owner name. The complete set of
- NSEC RRs in a zone both indicate which RRsets exist in a zone and
- also form a chain of owner names in the zone. This information is
- used to provide authenticated denial of existence for DNS data, as
- described in RFC 2535 [3].
-
- The type value for the NSEC RR is 47.
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 3]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- The NSEC RR RDATA format is class independent and defined for all
- classes.
-
- The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
- field. This is in the spirit of negative caching [2].
-
-2.1 NSEC RDATA Wire Format
-
- The RDATA of the NSEC RR is as shown below:
-
- 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 /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / List of Type Bit Map(s) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-2.1.1 The Next Domain Name Field
-
- The Next Domain Name field contains the owner name of the next RR in
- the canonical ordering of the zone. The value of the Next Domain
- Name field in the last NSEC record in the zone is the name of the
- zone apex (the owner name of the zone's SOA RR).
-
- A sender MUST NOT use DNS name compression on the Next Domain Name
- field when transmitting an NSEC RR. A receiver which receives an
- NSEC RR containing a compressed Next Domain Name field SHOULD
- decompress the field value.
-
- Owner names of RRsets not authoritative for the given zone (such as
- glue records) MUST NOT be listed in the Next Domain Name unless at
- least one authoritative RRset exists at the same owner name.
-
-2.1.2 The List of Type Bit Map(s) Field
-
- The RR type space is split into 256 window blocks, each representing
- the low-order 8 bits of the 16-bit RR type space. Each block that has
- at least one active RR type is encoded using a single octet window
- number (from 0 to 255), a single octet bitmap length (from 1 to 32)
- indicating the number of octets used for the window block's bitmap,
- and up to 32 octets (256 bits) of bitmap.
-
- Blocks are present in the NSEC RR RDATA in increasing numerical
- order.
-
- "|" denotes concatenation
-
-
-
-Schlyter Expires September 9, 2004 [Page 4]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
- Each bitmap encodes the low-order 8 bits of RR types within the
- window block, in network bit order. The first bit is bit 0. For
- window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
- to RR type 2 (NS), and so forth. For window block 1, bit 1
- corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
- 1, it indicates that an RRset of that type is present for the NSEC
- RR's owner name. If a bit is set to 0, it indicates that no RRset of
- that type is present for the NSEC RR's owner name.
-
- Since bit 0 in window block 0 refers to the non-existing RR type 0,
- it MUST be set to 0. After verification, the validator MUST ignore
- the value of bit 0 in window block 0.
-
- Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4]
- (section 3.1) or within the range reserved for assignment only to
- QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
- zone data. If encountered, they must be ignored upon reading.
-
- Blocks with no types present MUST NOT be included. Trailing zero
- octets in the bitmap MUST be omitted. The length of each block's
- bitmap is determined by the type code with the largest numerical
- value, within that block, among the set of RR types present at the
- NSEC RR's owner name. Trailing zero octets not specified MUST be
- interpretted as zero octets.
-
-2.1.3 Inclusion of Wildcard Names in NSEC RDATA
-
- If a wildcard owner name appears in a zone, the wildcard label ("*")
- is treated as a literal symbol and is treated the same as any other
- owner name for purposes of generating NSEC RRs. Wildcard owner names
- appear in the Next Domain Name field without any wildcard expansion.
- RFC 2535 [3] describes the impact of wildcards on authenticated
- denial of existence.
-
-2.2 The NSEC RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Next Domain Name field is represented as a domain name.
-
- The List of Type Bit Map(s) Field is represented as a sequence of RR
- type mnemonics. When the mnemonic is not known, the TYPE
- representation as described in RFC 3597 [5] (section 5) MUST be used.
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 5]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-2.3 NSEC RR Example
-
- The following NSEC RR identifies the RRsets associated with
- alfa.example.com. and identifies the next authoritative name after
- alfa.example.com.
-
- alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234
-
- The first four text fields specify the name, TTL, Class, and RR type
- (NSEC). The entry host.example.com. is the next authoritative name
- after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC
- and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and
- TYPE1234 RRsets associated with the name alfa.example.com.
-
- The RDATA section of the NSEC RR above would be encoded as:
-
- 0x04 'h' 'o' 's' 't'
- 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
- 0x03 'c' 'o' 'm' 0x00
- 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
- 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x20
-
- Assuming that the resolver can authenticate this NSEC record, it
- could be used to prove that beta.example.com does not exist, or could
- be used to prove there is no AAAA record associated with
- alfa.example.com. Authenticated denial of existence is discussed in
- RFC 2535 [3].
-
-3. IANA Considerations
-
- This document introduces no new IANA considerations, because all of
- the protocol parameters used in this document have already been
- assigned by RFC TCR [6].
-
-4. Security Considerations
-
- The update of the RDATA format and encoding does not affect the
- security of the use of NSEC RRs.
-
-Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-
-
-
-Schlyter Expires September 9, 2004 [Page 6]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- 2308, March 1998.
-
- [3] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [4] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name
- System (DNS) IANA Considerations", BCP 42, RFC 2929, September
- 2000.
-
- [5] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
- [6] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
- in progress), October 2003.
-
-Informational References
-
- [7] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [8] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
-
-Author's Address
-
- Jakob Schlyter (editor)
- Karl Gustavsgatan 15
- Goteborg SE-411 25
- Sweden
-
- EMail: jakob@schlyter.se
-
-Appendix A. Acknowledgements
-
- The encoding described in this document was initially proposed by
- Mark Andrews. Other encodings where proposed by David Blacka and
- Michael Graff.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 7]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Schlyter Expires September 9, 2004 [Page 8]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 9]
-
+++ /dev/null
-
-
-DNSOP O. Kolkman
-Internet-Draft RIPE NCC
-Expires: March 1, 2004 R. Gieben
- NLnet Labs
- September 2003
-
-
- DNSSEC Operational Practices
- draft-ietf-dnsop-dnssec-operational-practices-00.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on March 1, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document intends to describe a set of practices for operating a
- DNSSEC aware enviroment. Its target audience is zone administrators
- who are deploying DNSSEC and need a guide to help them chose sensible
- values for DNSSEC parameters. Is also discusses operational matters
- like key rollovers, KSK and ZSK considerations and more.
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 1]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 The use of the term 'key' . . . . . . . . . . . . . . . . . 3
- 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.1 Time definitions . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2 Time considerations . . . . . . . . . . . . . . . . . . . . 4
- 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1 Motivations for the KSK and ZSK functions . . . . . . . . . 6
- 3.2 Key security considerations . . . . . . . . . . . . . . . . 7
- 3.3 Key rollovers . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3.1 Zone-signing key rollovers . . . . . . . . . . . . . . . . . 9
- 3.3.2 Key-signing key rollovers . . . . . . . . . . . . . . . . . 12
- 4. Planning for emergency key rollover. . . . . . . . . . . . . 13
- 4.1 KSK compromise . . . . . . . . . . . . . . . . . . . . . . . 13
- 4.2 ZSK compromise . . . . . . . . . . . . . . . . . . . . . . . 14
- 4.3 Compromises of keys anchored in resolvers . . . . . . . . . 14
- 5. Parental policies. . . . . . . . . . . . . . . . . . . . . . 14
- 5.1 Initial key exchanges and parental policies
- considerations. . . . . . . . . . . . . . . . . . . . . . . 14
- 5.2 Storing keys so hashes can be regenerated . . . . . . . . . 15
- 5.3 Security lameness checks. . . . . . . . . . . . . . . . . . 15
- 5.4 SIG DS validity period. . . . . . . . . . . . . . . . . . . 15
- 6. Security considerations . . . . . . . . . . . . . . . . . . 16
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
- Normative References . . . . . . . . . . . . . . . . . . . . 16
- Informative References . . . . . . . . . . . . . . . . . . . 16
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
- A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 17
- B. Zone-signing key rollover howto . . . . . . . . . . . . . . 18
- C. Typographic conventions . . . . . . . . . . . . . . . . . . 19
- D. Document Details and Changes . . . . . . . . . . . . . . . . 20
- D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . . 21
- Intellectual Property and Copyright Statements . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 2]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
-1. Introduction
-
- During workshops and early operational deployment tests, operators
- and system administrators gained knowledge about operating DNSSEC
- aware DNS services. This document describes these practices.
-
- The structure of the document is as follows. It starts with
- discussing some of the considerations with respect to timing
- parameters of DNS in relation to DNSSEC (Section 2). Aspects of key
- management such as key rollover schemes are described in Section 3.
- Emergency rollover considerations are addressed in Section 4. The
- Typographic conventions used in this document are explained in
- Appendix C.
-
- Since this is a document with operational suggestions and there is no
- protocol specifications the RFC2119 [5] language does not apply.
-
-1.1 The use of the term 'key'
-
- It is assumed that the reader is familiar with the concept of
- asymmetric keys on which DNSSEC is based. Therefore this document
- will use the term key rather loosely. Wherever we write that 'a key
- is used to sign data' it is assumed that the reader knows that it is
- the private part of the key-pair that is used for signing. It is also
- assumed that the reader will know that the public part of the
- key-pair is published in the DNSKEY resource record and that it is
- the public part of a key-pair that is used in key-exchanges.
-
-2. Time in DNSSEC
-
- Without DNSSEC all times in DNS are relative. The SOA's refresh,
- retry and expiration timers are counters that are being used to
- determine the time elapsed after a slave server synced (or tried to
- sync) with a master server. The TTL value and the SOA minimum TTL
- parameter [6] are used to to determine how long a forwarder should
- cache data after it has been fetched from an authoritative server.
- DNSSEC introduces the notion of an absolute time in the DNS.
- Signatures in DNSSEC have an expiration date after which the
- signature is invalid and the signed data is to be considered BAD.
-
-2.1 Time definitions
-
- In this document we will be using a number of time related terms.
- Within the context of this document the following definitions apply:
-
- o "Signature validity period"
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 3]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- The period that a signature is valid. It starts at the time
- specified in the signature inception field of the RRSIG RR and
- ends at the time specified in the expiration field of the RRSIG
- RR.
-
- o "Signature publication period"
-
- Time after which a signature made with a key is replaced with a
- new signature made with the same key. This replacement takes
- place by publishing the relevant RRSIG in the master zone file.
- If a signature is published on time T0 and a new signature is
- published on time T1, the signature publication period is T1 -
- T0. If all signatures are refreshed at zone (re)signing then
- the signature publication period is equal to the period between
- two consecutive zone signing operations.
-
- o "Key publication period"
-
- The period for which the public part of the key is published in
- the DNS. The public part of the key can be published in the DNS
- while it has not yet been used to sign data. As soon as a
- public key is published a brute force attack can be attempted
- to recover the private key. Publishing the public key in
- advance (and not signing any data with it) does not guard
- against this attack.
-
- [Editor's Note: We don't use this term in the doc yet, is it
- needed elsewhere and handy to define here? No:1 Yes:0]
-
- o "Maximum/Minimum Zone TTL"
-
- The maximum or minimum value of all the TTLs in a zone.
-
-
-2.2 Time considerations
-
- Because of the expiration of signatures one should consider the
- following.
-
- o The Maximum zone TTL of your zone data should be a fraction of
- your signature validity period.
-
- If the TTL would be of similar order as the signature validity
- period then all RRsets fetched during the validity period would
- be cached until the signature expiration time. As a result
- query behavior might become bursty.
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 4]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- We suggest the TTL on all the RRs in your zone to be at least
- an order of magnitude smaller than your signature validity
- period.
-
- o The signature publication period should at least be one maximum
- TTL smaller than the signature validity period.
-
- If a zone is resigned shortly before the end of the signature
- validity period this may cause simultaneous expiration of data
- from caches which leads to bursty query behavior and increase
- the load on authoritative servers.
-
- o The Minimum zone TTL should be long enough to fetch and verify all
- the RRs in the authentication chain.
-
- 1. During validation, some data may expire before validation
- is complete. The validator should be able to keep all the
- data, until validation is complete. This applies to all data
- in the chain of trust: DSs, DNSKEYs, RRSIGs, and the final
- answers i.e. the RR that is returned for the initial query.
-
- 2. Frequent verification causes load on recursive
- nameservers. Data at delegation points, DSs, DNSKEYs and
- RRSIGs benefit from caching. The TTL on those should be
- relatively long.
-
- We have seen events where data needed for verification of an
- authentication chain had expired from caches.
-
- We suggest the TTL on DNSKEY and DSs to be at least of the
- order 10 minutes to an hour and all the other RRs in your zone
- to be at least 30 seconds. These are absolute minimum, we
- recommend zone administrators to chose longer ones.
-
- [Editor's Note: this observation could be implementation
- specific. We are not sure if we should leave this item]
-
- o Slave servers will need to be able to fetch newly signed zones
- well before the data expires from your zone.
-
- If a properly implemented slave server is not able to contact a
- master server for an extended period the data will at some
- point expire and the slave server will not hand out any data.
- If the server serves a DNSSEC zone than it may well happen that
- the signatures expire well before the SOA expiration timer
- counted down to zero. It is not possible to fully prevent this
- from happening by tweaking the SOA parameters. But the effects
- can be minimized if the SOA expiration time is of the same of
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 5]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- order of magnitude as or smaller than the signature validity
- period.
-
- When a zone cannot be updated while signatures in that zone
- have expired non-secure resolvers will continue to be able to
- resolve the data served by the particular slave servers. Only
- security aware resolvers that receive data with expired
- signatures will experience problems.
-
- We suggest the SOA expiration timer being approximately one
- third or one fourth of the signature validity period.
-
- We also suggest that operators of nameservers with slave zones
- develop watchdogs to be able to spot these upcoming signature
- expirations in slave zones, so that appropriate action can be
- taken.
-
- o [Editor's Note: Need examples here]
-
-
-3. Keys
-
-3.1 Motivations for the KSK and ZSK functions
-
- Delegation Signer [7] introduced the concept of key-signing and
- zone-signing keys.The Key-signing-flag [4] introduced the concept of
- a key with the Secure Entry Point flag set; a key that is the first
- key from the zone when following an authentication chain. When using
- a key-signing key with the SEP flag set (the parent has a DS RR
- pointing to that DNSKEY) and when using zone-signing keys without the
- SEP flag set (a practice which we recommend ) one can use the
- following operational procedures.
-
- The zone-signing key can be used to sign all the data in a zone on a
- regular basis. When a zone-signing key is to be rolled over no
- interactions with the parent is needed. This allows for relatively
- short "Signature Validity Periods" (order of days).
-
- The key-signing key (with the SEP flag set) is only to be used to
- sign the Key RR set from the zone apex. If a key-signing key is to be
- rolled over, there will be interactions with parties other than the
- zone maintainer such as the registry of the parent zone or
- administrators of verifying resolvers that have the particular key
- configured as trusted entry points. Hence, the "Key Usage Time" of
- these keys can and should be made much longer. Although, given a long
- enough key, the "Key Usage Time" can be on the order of years we
- suggest to plan for a "Key Usage Time" of the order of a few months
- so that a key rollover remains an operational routine.
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 6]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
-3.2 Key security considerations
-
- In RFC2541 [2] a number of considerations with respect to the
- security of keys are described. That document deals with the
- generation, lifetime, size and storage of private keys.
-
- In Section 3 of RFC2541 [2], Eastlake does have some suggestions: 13
- months for long-lived keys and 36 days for transaction keys but
- suggestions for key sizes are not made.
-
- If we read the long-lived key being a key that is used as key-signing
- key and transaction keys being zone signing keys, then these
- recommendations are good starting points for an operational
- procedure. These recommendations will lead to rollovers occurring
- frequently enough so that they can become part of 'operational
- habits' and the procedure does not have to be reinvented every time a
- key is replaced.
-
- When choosing a key sizes, zone administrators will need to take into
- account how long a key will be used and how much data will be signed
- during the key publication period. It is hard to give precise
- recommendations but Lenstra and Verheul [9] supplied the following
- table with lower bound estimates for cryptographic key sizes. Their
- recommendations are based on a set of explicitly formulated parameter
- settings, combined with existing data points about cryptosystems. For
- details we refer to the original paper.
-
- Year RSA key sizes Elliptic Curve Key Size
- 2000 952 132
- 2001 990 135
- 2002 1028 139
- 2003 1068 140
- 2004 1108 143
-
- 2005 1149 147
- 2006 1191 148
- 2007 1235 152
- 2008 1279 155
- 2009 1323 157
-
-
- 2010 1369 160
- 2011 1416 163
- 2012 1464 165
- 2013 1513 168
- 2014 1562 172
-
- 2015 1613 173
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 7]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- 2016 1664 177
- 2017 1717 180
- 2018 1771 181
- 2019 1825 185
-
-
- 2020 1881 188
- 2021 1937 190
- 2022 1995 193
- 2023 2054 197
- 2024 2113 198
-
- 2025 2174 202
- 2026 2236 205
- 2027 2299 207
- 2028 2362 210
- 2029 2427 213
-
- Suppose you want your key to last 3 years and the current year is
- 2003. Add 3 to 2003 equals 2006 and read of the sizes: 1191 for
- asymmetric keys and 148 bits for elliptic curve keys.
-
- Note that adding only a "handful of bits" to the key size will
- increase the key's resistance against brute force attacks.
-
-3.3 Key rollovers
-
- Key rollovers are a fact of life when using DNSSEC. A DNSSEC key
- cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone
- maintainers who are in the process of rolling their keys have to take
- into account that data they have published in previous versions of
- their zone still lives in caches. When deploying DNSSEC this becomes
- an important consideration; ignoring data that may be in caches may
- lead to loss of service for clients.
-
- The most pressing example of this is when zone material which is
- signed with an old key is being validated by a resolver which does
- not have the old zone key cached. If the old key is no longer present
- in the current zone, this validation fails, marking the data BAD.
- Alternatively, an attempt could be made to validate data which is
- signed with a new key against an old key that lives in a local cache,
- also resulting in data being marked BAD.
-
- To appreciate the situation one could think of a number of
- authoritative servers that may not be instantaneously running the
- same version of a zone and a security aware non-recursive resolver
- that sits behind security aware caching forwarders.
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 8]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- Note that KSK rollovers and ZSK rollovers are different. A zone-key
- rollover can be handled in two different way: pre-publish and
- [Editors note: ref please] double-sig. The pre-publish technique
- works because the key-signing key stays the same during this ZSK
- rollover. With this KSK a cache is able to validate the new keyset of
- a zone. With a KSK rollover a cache can not validate the new keyset,
- because it does not trust the new KSK.
-
- [Editors note: This needs more verbose explanation, nobody will
- appreciate the situation just yet. Help with text and examples is
- appreciated]
-
-3.3.1 Zone-signing key rollovers
-
- For zone-signing key rollovers there are two ways to make sure that
- during the rollover the data still in caches can be verified with the
- new keysets or the newly generated signatures can be verified with
- the keys still in caches. One schema uses double signatures, it is
- described in Section 3.3.1.1, the other uses key pre-publication
- (Section 3.3.1.2). The pros, cons and recommendations are described
- in Section 3.3.1.3.
-
-3.3.1.1 A double signature zone-signing key rollover
-
- This section shows how to perform a ZSK key rollover using the double
- zone data signature scheme.
-
- During the rollover stage the new version of the zone file will need
- to propagate to all authoritative servers and the data that exists in
- (distant) caches will need to expire, this will take at least the
- maximum Zone TTL .
-
- normal roll after
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
- RRSIG11(SOA1)
-
- DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11
- RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
- RRSIG11(DNSKEY)
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 9]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- normal: Version 0 of the zone: DNSKEY 1 is a key-signing key. DNSKEY
- 10 is used to sign all the data of the zone, it is the
- zone-signing key.
-
- roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
- into the keyset and all the data in the zone is signed with DNSKEY
- 10 and DNSKEY 11. The rollover period will need to exist until all
- data from version 0 of the zone has expired from remote caches.
- This will take at least the Maximum Zone TTL of the version 0 of
- the zone.
-
- after: DNSKEY 10 is removed from the zone. All the signatures from
- DNSKEY 10 are removed from the zone. The keyset, now only
- containing DNSKEY 11 is resigned with the DNSKEY 1.
-
- At every instance the data from the previous version of the zone can
- be verified with the key from the current version. And vice verse,
- the data from the current version can be verified with the data from
- the previous version of the zone. The duration of the rollover phase
- and the period between rollovers should be at least the "Maximum Zone
- TTL".
-
- To be on the safe side one could make sure that the rollover phase
- lasts until the signature expiration time of the data in version 0 of
- the zone. But this date could be considerable longer than the Maximum
- Zone TTL, making the rollover a lengthly procedure.
-
- Note that in this example we assumed that the zone did not get
- modified during the rollover. New data can be introduced in the zone
- as long as it is signed with both keys.
-
-3.3.1.2 Pre-publish keyset rollover
-
- This section shows how to perform a ZSK rollover without the need to
- sign all the data in a zone twice. We recommend this method because
- it has advantages in the case of key compromises. If the old key gets
- compromised the new key is already distributed in the DNS. The zone
- administrator is then able to quickly switch to the new key and
- remove the compromised key from the zone. Another major advantage is
- that the zone size does not double, as is the case with the double
- signature ZSK rollover. A small "HOWTO" for this kind of rollover can
- be found in Appendix B.
-
- normal pre-roll roll after
-
- SOA0 SOA1 SOA2 SOA3
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 10]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11 DNSKEY11
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
- normal: Version 0 of the zone: DNSKEY 1 is a key-signing key. DNSKEY
- 10 is used to sign all the data of the zone, its the zone-signing
- key.
-
- pre-roll: DNSKEY 11 is introduced in the keyset. Note that no
- signatures are generated with this key yet, but this will not
- prevent brute force attacks on the public key. The minimum
- duration of this pre-roll phase is the time it takes for the data
- to propagate to the authoritative servers plus TTL value on the
- keyset. This would boil down to two times the Maximum Zone TTL.
-
- roll:
-
- At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign the
- data in the zone (exclusively i.e. all the signatures from DNSKEY
- 10 are removed from the zone.). DNSKEY 10 remains published in the
- keyset. This way data that was loaded into caches from version 1
- of the zone can still be verified with key sets fetched from
- version 2 of the zone.
-
- The minimum time that the keyset that includes DNSKEY 10 is to be
- published is the time that it takes for zone data from the
- previous version of the zone to expire from old caches i.e. the
- time it takes for this zone to propagate to all authoritative
- servers plus the Maximum Zone TTL value of any of the data in the
- previous version of the zone.
-
- after: DNSKEY 10 is removed from the zone. The keyset, now only
- containing DNSKEY 11 is resigned with the DNSKEY 1.
-
- The above scheme can be simplified a bit by always publishing the
- "future" key immediately after the rollover. The scheme would look
- like this (we show 2 rollovers); the future key is introduced in
- "after" as DNSKEY 12 and again a newer one, numbered 13, in "2nd
- after":
-
-
- normal roll after 2nd roll 2nd after
-
- SOA0 SOA2 SOA3 SOA4 SOA5
- RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5)
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 11]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12
- DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13
- RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY)
-
-
- Note that the key introduced after the rollover is not used for
- production yet; the private key can thus be stored in a physically
- secure manner and does not need to be 'fetched' every time a zone
- needs to be signed.
-
- This scheme has the benefit that the key that is intended for future
- use, can immediately be used during an emergency rollover under the
- assumption that it was stored in a physically secure manner.
-
-3.3.1.3 Pros and cons of the schemes
-
- A double signature rollover: The drawback of this signing scheme is
- that during the rollover the number of signatures in your zone
- doubles, which may be prohibitive if you have very big zones. An
- advantage is that it only requires three steps.
-
- Prepublish-keyset rollover: This rollover does not involve signing
- the zone data twice. Instead, just before the actual rollover the
- new key is published in the keyset and thus available for
- cryptanalysis attacks. A small disavantage is that this process
- requires four steps. Also the prepublish scheme is useless for
- KSKs as explained in Section 3.3.
-
-
-3.3.2 Key-signing key rollovers
-
- For the rollover of a key-signing key the same considerations as for
- the rollover of a zone-signing key apply. However we can use a double
- signature scheme to guarantee that old data (only the apex keyset) in
- caches can be verified with a new keyset and vice versa. Since only
- the keyset is signed with a KSK, size considerations do not apply.
-
-
- normal roll after
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2)
-
- DNSKEY1 DNSKEY1 DNSKEY2
- DNSKEY2
- DNSKEY10 DNSKEY10 DNSKEY10
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 12]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)
- RRSIG2 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
-
-4. Planning for emergency key rollover.
-
- This section deals with preparation for a possible key compromise.
- Our advice is to have a documented procedure ready for when a key
- compromise is suspected or confirmed.
-
- [Editors note: We are much in favor of a rollover tactic that keeps
- the authentication chain intact as long as possible. This has as a
- result that one has to take all the regular rollover properties into
- account.]
-
- When the private material of one of your keys is compromised it can
- be used by 'blackhats' for as long as a valid authentication chain
- exists. A authentication chain remains intact for:
-
- as long as a signature over the compromised key in the
- authentication chain is valid,
-
- as long as a parental DS RR (and signature) points to the
- compromised key,
-
- as long as the key is anchored in a resolver and is used as a
- starting point for validation. (This is the hardest to update.)
-
- While an authentication chain to your compromised key exists your
- name-space is vulnerable to abuse by the "blackhat". Zone operators
- have to make a trade off if the abuse of the compromised key is worse
- than having data in caches that cannot be validated. If the zone
- operator chooses to break the authentication chain to the compromised
- key, data in caches signed with this key can not be validated. On the
- other hand if the zone administrator chooses to take the path of a
- regular roll-over the "blackhat" can spoof data so that it appears to
- be valid, note that this kind of attack will usually be localized in
- the Internet topology.
-
-
-4.1 KSK compromise
-
- When the KSK has been compromised the parent must be notified as soon
- as possible and through secure means. The keyset of the zone should
- be resigned as soon as possible. Care must be taken to not break the
- authentication chain. The local zone can only be resigned with the
- new KSK after the parent's zone has been updated with the new KSK.
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 13]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- Before this update takes place it would be best to drop the security
- status of a zone all together: the parent removes the DS of the child
- at the next zone update. After that the child can be made secure
- again. An additional danger of a key compromise is that the
- compromised key can be used to facilitate a legitemate DNSKEY/DS and/
- or nameserver rollover at the parent. When that happens the domain
- can be in dispute. An out of band and secure notify mechanism to
- contact a parent is needed in this case.
-
-4.2 ZSK compromise
-
- Mainly because there is no parental interaction required when a ZSK
- is compromised the situation is less severe than with with a KSK
- compromise. The zone must still be resigned with a new ZSK as soon
- as possible. As this is a local operation and requires no
- communication between the parent and child this can be achieved
- fairly quickly. One has to take into account though that just as with
- a normal rollover the immediate disappearance from the old
- compromised key may lead to verification problems. The
- pre-publication scheme as discussed above minimizes that problem.
-
-4.3 Compromises of keys anchored in resolvers
-
- A key can also be pre-configured in resolvers. If DNSSEC is rolled
- out as planned the root key should be pre-configured in every secure
- aware resolver on the planet. [Editors Note: add more about
- authentication of a newly received resolver key]
-
- If that key is compromised all the resolvers should be notified of
- this fact. Zone administrators may consider setting up a mailing list
- to communicate the fact that a SEP key is about to be rolled over.
- This communication will of course need to be authenticated e.g. by
- using digital signatures.
-
-5. Parental policies.
-
-5.1 Initial key exchanges and parental policies considerations.
-
- The initial key exchange is always subject to the policies set by the
- parent (or its registry). When designing a key exchange policy one
- should take into account that the authentication and authorization
- mechanisms used during a key exchange should be as strong as the
- authentication and authorization mechanisms used for the exchange of
- delegation information between parent and child.
-
- Using the DNS itself as the source for the actual DNSKEY material
- with an off-band check on the validity of the DNSKEY has the benefit
- that it reduces the changes of operator error. A parental DNSKEY
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 14]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- download tool can make use of the SEP bit [4] to select the proper
- key from a DNSSEC keyset; thereby reducing the change that the wrong
- DNSKEY is sent. It can validate the self-signature over a key;
- thereby verifying the ownership of the private key material. Besides,
- by fetching the DNSKEY from the DNS one can be sure that the child
- will not become invisible once the parent indicates the child is
- secure by publishing the DS RR.
-
- Note: the off-band verification is still needed when the keymaterial
- is fetched by a tool. The parent can not be sure if the DNSKEY RRs
- where not spoofed.
-
-5.2 Storing keys so hashes can be regenerated
-
- When designing a registry system one should consider if the DNSKEYs
- or the corresponding DSs are stored. Storing DNSKEYs will help during
- troubleshooting while the overhead of calculating DS records from
- them is minimal.
-
- Having a out-of-band mechanism, such as a WHOIS database, to find out
- which keys are used to generate DS Resource Records for specific
- owners may also help with troubleshooting.
-
-5.3 Security lameness checks.
-
- Security lameness is defined as the event that a parent has a DS
- Resource Record that points to a non-existing DNSKEY RR. At key
- exchange a parent should make sure that the childs key is actually
- configured in the DNS before publishing a DS RR in its zone. Failure
- to do so would render the child's zone marked "BAD".
-
- Child zones should be very careful removing DNSKEY material,
- specifically SEP keys, for which a DS RR exist.
-
- Once a zone is "security lame" a fix (e.g. by removing a DS RR) will
- take time to propagate through the DNS.
-
-5.4 SIG DS validity period.
-
- Since the DS can be replayed as long as it has a valid signature a
- short signature validity period over the DS minimizes the time a
- child is vulnerable in the case of a compromise of the child's KSK.
- A signature validity period that is too short introduces the
- possibility that a zone is marked BAD in case of a configuration
- error in the signer; there may not be enough time to fix the problems
- before signatures expire. Something as mundane as weekends show the
- need for a DS signature lifetimes longer than 2 days. We recommend
- the minimum for a DS signature validity period to be about a few
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 15]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- days.
-
- The maximum signature lifetime of the DS record depends on how long
- child zones are willing to be vulnerable after a key compromise. We
- consider a signature validity period of the order of one week a good
- compromise between the operational constraints of the parent and
- minimizing damage for the child.
-
-6. Security considerations
-
- DNSSEC adds data integrity to the DNS. This document tries to assess
- considerations to operate a stable and secure DNSSEC service.
-
-7. Acknowledgments
-
- We, the folk mentioned as authors, only acted as editors. Most of the
- ideas in this draft where the result of collective efforts during
- workshops and discussions and try outs.
-
- At the risk of forgetting individuals who where the original
- contributors of the ideas we like to acknowledge people who where
- actively involved in the compilation of this document. In
- alphabetical order: Olafur Gudmundsson, Wesley Griffin, Michael
- Richardson, Scott Rose, Rick van Rein, Tim McGinnis.
-
- Kolkman and Gieben take the blame for all mistakes.
-
-Normative References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [2] Eastlake, D., "DNS Security Operational Considerations", RFC
- 2541, March 1999.
-
- [3] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key
- (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work
- in progress), February 2003.
-
-Informative References
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 16]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- 2308, March 1998.
-
- [7] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-13 (work in progress), March
- 2003.
-
- [8] Arends, R., "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in
- progress), March 2003.
-
- [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",
- The Journal of Cryptology 14 (255-293), 2001.
-
-
-Authors' Addresses
-
- Olaf M. Kolkman
- RIPE NCC
- Singel 256
- Amsterdam 1016 AB
- NL
-
- Phone: +31 20 535 4444
- EMail: olaf@ripe.net
- URI: http://www.ripe.net/
-
-
- Miek Gieben
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098 VA
- NL
-
- EMail: miek@nlnetlabs.nl
- URI: http://www.nlnetlabs.nl
-
-Appendix A. Terminology
-
- In this document there is some jargon used that is defined in other
- documents. In most cases we have not copied the text from the
- documents defining the terms but give a more elaborate explanation of
- the meaning. Note that these explanations should not be seen as
- authoritative.
-
- Private and Public Keys: DNSSEC secures the DNS through the use of
- public key cryptography. Public key cryptography is based on the
- existence of 2 keys, a public key and a private key. The public
- keys are published in the DNS by use of the DNSKEY Resource Record
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 17]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- (DNSKEY RR). Private keys are supposed to remain private i.e.
- should not be exposed to parties not-authorized to do the actual
- signing.
-
- Signer: The system that has access to the private key material and
- signs the Resource Record sets in a zone. A signer may be
- configured to sign only parts of the zone e.g. only those RRsets
- for which existing signatures are about to expire.
-
- KSK: A Key-Signing key (KSK) is a key that is used for exclusively
- signing the apex keyset. The fact that a key is a KSK is only
- relevant to the signing tool.
-
- ZSK: A Zone signing key (ZSK) is a key that is used for signing all
- data in a zone. The fact that a key is a ZSK is only relevant to
- the signing tool.
-
- BAD: [Editors Note: a reference here] A RRset in DNSSEC is marked
- "bad" when a signature of a RRset does not validate against the
- DNSKEY. Even is the key itself was not marked BAD. BAD data is not
- cached.
-
- Singing the Zone File: The term used for the event where an
- administrator joyfully signs its zone file while producing melodic
- sound patterns.
-
-
-Appendix B. Zone-signing key rollover howto
-
- Using the pre-published signature scheme and the most conservative
- method to assure oneself that data does not live in distant caches
- here follows the "HOWTO". [WES: has some comments about this]
-
- STEP 0, the preparation: Create two keys and publish them both in
- your keyset. Mark one of the keys as "active" and the other as
- "published". Use the "active" key for signing your zone data.
- Store the private part of the "published" key, preferably
- off-line.
-
- STEP 1, determine expiration: At the beginning of the rollover:
- make a note of the highest expiration time of signatures in your
- zonefile created with the current key currently marked as
- "active".
-
- Wait until the expiration time marked in STEP 1
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 18]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- STEP 2 Then start using the key that was marked as "published" to
- sign your data i.e. mark it as "active". Stop using the key that
- was marked as "active", mark it as "rolled".
-
- STEP 3: It is safe to engage in a new rollover (STEP 1) after at
- least one "signature validity period".
-
-
-Appendix C. Typographic conventions
-
- The following typographic conventions are used in this document:
-
- Key notation: A key is denoted by KEYx, where x is a number, x could
- be thought of as the key id.
-
- RRset notations: RRs are only denoted by the type all other
- information, owner, class, rdata and TTL is left out. Thus:
- example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a
- list of RRs. A example of this would be: A1,A2, specifying the
- RRset containing two A records. This could again be abreviated to
- just: A.
-
- Signature notation: Signatures are denoted as SIGx(RRset), which
- means that RRset is signed with KEYx.
-
- Zone representation: Using the above notation we have simplify the
- representation of a signed zone by leaving out all unneeded
- details such as the names and by just representing all data by
- "SOAx"
-
- SOA representation: Soa's are represented as SOA x, where x is the
- serial number.
-
- Using this notation the following zone :
-
-
- example.net. 600 IN SOA ns.example.net. ernie.example.net. (
- 10 ; serial
- 450 ; refresh (7 minutes 30 seconds)
- 600 ; retry (10 minutes)
- 345600 ; expire (4 days)
- 300 ; minimum (5 minutes)
- )
- 600 RRSIG SOA 5 2 600 20130522213204 (
- 20130422213204 14 example.net.
- cmL62SI6iAX46xGNQAdQ... )
- 600 NS a.iana-servers.net.
- 600 NS b.iana-servers.net.
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 19]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- 600 RRSIG NS 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- SO5epiJei19AjXoUpFnQ ... )
- 3600 DNSKEY 256 3 5 (
- EtRB9MP5/AvOuVO0I8XDxy0...
- ) ; key id = 14
- 3600 DNSKEY 256 3 5 (
- gsPW/Yy19GzYIY+Gnr8HABU...
- ) ; key id = 15
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 14 example.net.
- J4zCe8QX4tXVGjV4e1r9... )
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 15 example.net.
- keVDCOpsSeDReyV6O... )
- 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC
- 600 RRSIG NSEC 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- obj3HEp1GjnmhRjX... )
- a.example.net. 600 IN TXT "A label"
- 600 RRSIG TXT 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
- IkDMlRdYLmXH7QJnuF3v... )
- 600 NSEC b.example.com. TXT RRSIG NSEC
- 600 RRSIG NSEC 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
- bZMjoZ3bHjnEz0nIsPMM... )
-
- ...
-
-
- is reduced to the following represenation:
-
- SOA10
- RRSIG14(SOA10)
-
- DNSKEY14
- DNSKEY15
-
- RRSIG14(KEY)
- RRSIG15(KEY)
-
- The rest of the zone data has the same signature as the SOA record,
- i.e a RRSIG created with DNSKEY 14.
-
-Appendix D. Document Details and Changes
-
- This section is to be removed by the RFC editor if and when the
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 20]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- document is published.
-
- $Header: /var/cvs/dnssec-key/
- draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.5 2003/10/10
- 09:49:07 dnssec Exp $
-
-D.1 draft-ietf-dnsop-dnssec-operational-practices-00
-
- Submission as working group document. This document is a modified and
- updated version of draft-kolkman-dnssec-operational-practices-00.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 21]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 22]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 23]
-\f
projects / thirdparty / bind9.git / commitdiff
