+++ /dev/null
-
-
-Network Working Group B. Laurie
-Internet-Draft Nominet
-Expires: March 2, 2005 R. Loomis
- SAIC
- September 2004
-
-
-
- Requirements related to DNSSEC Signed Proof of Non-Existence
- draft-ietf-dnsext-signed-nonexistence-requirements-01
-
-
-Status of this Memo
-
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
-
- 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 2, 2005.
-
-
-Copyright Notice
-
-
- Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
- DNSSEC-bis uses the NSEC record to provide authenticated denial of
- existence of RRsets. NSEC also has the side-effect of permitting
- zone enumeration, even if zone transfers have been forbidden.
- Because some see this as a problem, this document has been assembled
- to detail the possible requirements for denial of existence A/K/A
- signed proof of non-existence.
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 1]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
-Table of Contents
-
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3
- 4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4
- 5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4
- 6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4
- 7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5
- 9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5
- 10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6
- 11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6
- 12. Non-overlap of denial records with possible zone records . . 7
- 13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7
- 14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8
- 15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8
- 16. Minimisation of Client Complexity . . . . . . . . . . . . . 8
- 17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8
- 18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8
- 19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8
- 20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8
- 21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9
- 22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9
- 23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9
- 24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9
- 25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9
- 26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
- 28. Requirements notation . . . . . . . . . . . . . . . . . . . 9
- 29. Security Considerations . . . . . . . . . . . . . . . . . . 10
- 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 30.1 Normative References . . . . . . . . . . . . . . . . . . . 10
- 30.2 Informative References . . . . . . . . . . . . . . . . . . 10
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
- Intellectual Property and Copyright Statements . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 2]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
-1. Introduction
-
-
- NSEC records allow trivial enumeration of zones - a situation that
- has existed for several years but which has recently been raised as a
- significant concern for DNSSECbis deployment in several zones.
- Alternate proposals have been made that make zone enumeration more
- difficult, and some previous proposals to modify DNSSEC had related
- requirements/desirements that are relevant to the discussion. In
- addition the original designs for NSEC/NXT records were based on
- working group discussions and the choices made were not always
- documented with context and requirements-- so some of those choices
- may need to be restated as requirements. Overall, the working group
- needs to better understand the requirements for denial of existence
- (and certain other requirements related to DNSSECbis deployment) in
- order to evaluate the proposals that may replace NSEC.
-
-
- In the remainder of this document, "NSEC++" is used as shorthand for
- "a denial of existence proof that will replace NSEC". "NSECbis" has
- also been used as shorthand for this, but we avoid that usage since
- NSECbis will not be part of DNSSECbis and therefore there might be
- some confusion.
-
-
-2. Non-purposes
-
-
- This document does not currently document the reasons why zone
- enumeration might be "bad" from a privacy, security, business, or
- other perspective--except insofar as those reasons result in
- requirements. Once the list of requirements is complete and vaguely
- coherent, the trade-offs (reducing zone enumeration will have X cost,
- while providing Y benefit) may be revisited. The editors of this
- compendium received inputs on the potential reasons why zone
- enumeration is bad (and there was significant discussion on the
- DNSEXT WG mailing list) but that information fell outside the scope
- of this document.
-
-
- Note also that this document does not assume that NSEC *must* be
- replaced with NSEC++, if the requirements can be met through other
- methods (e.g., "white lies" with the current NSEC). As is stated
- above, this document is focused on requirements collection and
- (ideally) prioritization rather than on the actual implementation.
-
-
-3. Zone Enumeration
-
-
- Authenticated denial should not permit trivial zone enumeration.
-
-
- Additional discussion: NSEC (and NXT before it) provide a linked
- list that could be "walked" to trivially enumerate all the signed
- records in a zone. This requirement is primarily (though not
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 3]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- exclusively) important for zones that either are delegation-only/
- -mostly or do not have reverse lookup (PTR) records configured, since
- enterprises that have PTR records for all A records have already
- provided a similar capability to enumerate the contents of DNS zones.
-
-
- Contributor: various
-
-
-4. Zone Enumeration II
-
-
- Zone enumeration should be at least as difficult as it would be to
- effect a dictionary attack using simple DNS queries to do the same in
- an unsecured zone.
-
-
- (Editor comment: it is not clear how to measure difficulty in this
- case. Some examples could be monetary cost, bandwidth, processing
- power or some combination of these. It has also been suggested that
- the requirement is that the graph of difficulty of enumeration vs.
- the fraction of the zone enumerated should be approximately the same
- shape in the two cases)
-
-
- Contributor: Nominet
-
-
-5. Zone Enumeration III
-
-
- Enumeration of a zone with random contents should computationally
- infeasible.
-
-
- Editor comment: this is proposed as a way of evaluating the
- effectiveness of a proposal rather than as a requirement anyone would
- actually have in practice.
-
-
- Contributor: Alex Bligh
-
-
-6. Exposure of Contents
-
-
- NSEC++ should not expose any of the contents of the zone (apart from
- the NSEC++ records themselves, of course).
-
-
- Editor comment: this is a weaker requirement than prevention of
- enumeration, but certainly any zone that satisfied this requirement
- would also satisfy the trivial prevention of enumeration requirement.
-
-
- Contributor: Ed Lewis
-
-
-7. Zone Size
-
-
- Requirement: NSEC++ should make it possible to take precautions
- against trivial zone size estimates. Since not all zone owners care
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 4]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- about others estimation of the size of a zone, it is not always
- necessary to prohibit trivial estimation of the size of the zone but
- NSEC++ should allow such measures.
-
-
- Additional Discussion: Even with proposals based on obfuscating names
- with hashes it is trivial to give very good estimates of the number
- of domains in a certain zone. Just send 10 random queries and look
- at the range between the two hash values returned in each NSEC++. As
- hash output can be assumed to follow a rectangular random
- distribution, using the mean difference between the two values, you
- can estimate the total number of records. It is probably sufficient
- to look at even one NSEC++, since the two hash values should follow a
- (I believe) Poisson distribution.
-
-
- The concern is motivated by some wording remembered from NSEC, which
- stated that NSEC MUST only be present for existing owner names in the
- zone, and MUST NOT be present for non-existing owner names. If
- similar wording were carried over to NSEC++, introducing bogus owner
- names in the hash chain (an otherwise simple solution to guard
- against trivial estimates of zone size) wouldn't be allowed.
-
-
- One simple attempt at solving this is to describe in the
- specifications how zone signer tools can add a number of random
- "junk" records.
-
-
- Editor's comment: it is interesting that obfuscating names might
- actually make it easier to estimate zone size.
-
-
- Contributor: Simon Josefsson.
-
-
-8. Single Method
-
-
- Requirement: A single NSEC++ method must be able to carry both
- old-style denial (i.e. plain labels) and whatever the new style
- looks like. Having two separate denial methods could result in
- cornercases where one method can deny the other and vice versa.
-
-
- Additional discussion: This requirement can help -bis folks to a
- smooth upgrade to -ter. First they'd change the method while the
- content is the same, then they can change content of the method.
-
-
- Contributor: Roy Arends.
-
-
-9. Empty Non-terminals
-
-
- Requirement: Empty-non-terminals (ENT) should remain empty. In
- other words, adding NSEC++ records to an existing DNS structure
- should not cause the creation of NSEC++ records (or related records)
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 5]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- at points that are otherwise ENT.
-
-
- Additional discussion: Currently NSEC complies with ENT requirement:
- b.example.com NSEC a.c.example.com implies the existence of an ENT
- with ownername c.example.com. NSEC2 breaks that requirement, since
- the ownername is entirely hashed causing the structure to disappear.
- This is why EXIST was introduced. But EXIST causes ENT to be
- non-empty-terminals. Next to the dissappearance of ENT, it causes
- (some) overhead since an EXIST record needs a SIG, NSEC2 and
- SIG(NSEC2). DNSNR honours this requirement by hashing individual
- labels instead of ownernames. However this causes very long labels.
- Truncation is a measure against very long ownernames, but that is
- controversial. There is a fair discussion of the validity of
- truncation in the DNSNR draft, but that hasn't got proper review yet.
-
-
- Contributor: Roy Arends.
-
-
- (Editor comment: it is not clear to us that an EXIST record needs an
- NSEC2 record, since it is a special purpose record only used for
- denial of existence)
-
-
-10. Prevention of Precomputed Dictionary Attacks
-
-
- Requirement: NSEC++ needs to provide a method to reduce the
- effectiveness of precomputed dictionary attacks.
-
-
- Additional Discussion: Salt is a measure against dictionary attacks.
- There are other possible measures (such as iterating hashes in
- NSEC2). The salt needs to be communicated in every response, since
- it is needed in every verification. Some have suggested to move the
- salt to a special record instead of the denial record. I think this
- is not wise. Response size has more priority over zone size. An
- extra record causes a larger response than a larger existing record.
-
-
- Contributor: Roy Arends.
-
-
- (Editor comment: the current version of NSEC2 also has the salt in
- every NSEC2 record)
-
-
-11. DNSSEC-Adoption and Zone-Growth Relationship
-
-
- Background: Currently with NSEC, when a delegation centric zone
- deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
- when the DNSSEC-adoption rate of the subzones remains low--because
- each delegation point creates at least one NSEC record and
- corresponding signature in the parent even if the child is not
- signed.
-
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 6]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- Requirements: A delegation-only (or delegation-mostly) zone that is
- signed but which has no signed child zones should initially need only
- to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
- minimal set of NSEC++ records to cover zone contents. Further,
- during the transition of a delegation-only zone from 0% signed
- children to 100% signed children, the growth in the delegation-only
- zone should be roughly proportional to the percentage of signed child
- zones.
-
-
- Additional Discussion: This is why DNSNR has the Authoritative Only
- bit. This is similar to opt-in for delegations only. This (bit) is
- currently the only method to help delegation-centric zone cope with
- zone-growth due to DNSSEC adoption. As an example, A delegation only
- zone which deploys DNSSEC with the help of this bit, needs to add
- SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No
- more than that.
-
-
- Contributor: Roy Arends.
-
-
-12. Non-overlap of denial records with possible zone records
-
-
- Requirement: NSEC++ records should in some way be differentiated
- from regular zone records, so that there is no possibility that a
- record in the zone could be duplicated by a non-existence proof
- (NSEC++) record.
-
-
- Additional discussion: This requirement is derived from a discussion
- on the DNSEXT mailing list related to copyrights and domain names.
- As was outlined there, one solution is to put NSEC++ records in a
- separate namespace, e.g.: $ORIGIN co.uk.
- 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
- delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
- ; for amazon.co.uk.
-
-
- Contributor: various
-
-
- (Editor comment: One of us still does not see why a conflict
- matters. Even if there is an apparent conflict or overlap, the
- "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
- other name _never_ appears in NSEC2 records.)
-
-
-13. Exposure of Private Keys
-
-
- Private keys associated with the public keys in the DNS should be
- exposed as little as possible. It is highly undesirable for private
- keys to be distributed to nameservers, or to otherwise be available
- in the run-time environment of nameservers.
-
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 7]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- Contributors: Nominet, Olaf Kolkman, Ed Lewis
-
-
-14. Minimisation of Zone Signing Cost
-
-
- The additional cost of creating an NSEC++ signed zone should not
- significantly exceed the cost of creating an ordinary signed zone.
-
-
- Contributor: Nominet
-
-
-15. Minimisation of Asymmetry
-
-
- Nameservers should have to do as little additional work as necessary.
- More precisely, it is desirable for any increase in cost incurred by
- the nameservers to be offset by a proportionate increase in cost to
- DNS `clients', e.g. stub and/or `full-service' resolvers.
-
-
- Contributor: Nominet
-
-
-16. Minimisation of Client Complexity
-
-
- Caching, wildcards, CNAMEs, DNAMEs should continue to work without
- adding too much complexity at the client side.
-
-
- Contributor: Olaf Kolkman
-
-
-17. Completeness
-
-
- A proof of nonexistence should be possible for all nonexistent data
- in the zone.
-
-
- Contributor: Olaf Kolkman
-
-
-18. Purity of Namespace
-
-
- The name space should not be muddied with fake names or data sets.
-
-
- Contributor: Ed Lewis
-
-
-19. Replay Attacks
-
-
- NSEC++ should not allow a replay to be used to deny existence of an
- RR that actually exists.
-
-
- Contributor: Ed Lewis
-
-
-20. Compatibility with NSEC
-
-
- NSEC++ should not introduce changes incompatible with NSEC.
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 8]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- Contributor: Ed Lewis
-
-
-21. Compatibility with NSEC II
-
-
- NSEC++ should differ from NSEC in a way that is transparent to the
- resolver or validator.
-
-
- Contributor: Ed Lewis
-
-
-22. Compatibility with NSEC III
-
-
- NSEC++ should differ from NSEC as little as possible whilst achieving
- other requirements.
-
-
- Contributor: Alex Bligh
-
-
-23. Coexistence with NSEC
-
-
- NSEC++ should be optional, allowing NSEC to be used instead.
-
-
- Contributor: Ed Lewis, Alex Bligh
-
-
-24. Coexistence with NSEC II
-
-
- NSEC++ should not impose extra work on those content with NSEC.
-
-
- Contributor: Ed Lewis
-
-
-25. Protocol Design
-
-
- A good security protocol would allow signing the nonexistence of some
- selected names without revealing anything about other names.
-
-
- Contributor: Dan Bernstein
-
-
-26. Process
-
-
- Clearly not all of these requirements can be met. Therefore the next
- phase of this document will be to either prioritise them or narrow
- them down to a non-contradictory set, which should then allow us to
- judge proposals on the basis of their fit.
-
-
-27. Acknowledgements
-
-
-28. Requirements notation
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 9]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- document are to be interpreted as described in [RFC2119].
-
-
-29. Security Considerations
-
-
- There are currently no security considerations called out in this
- draft. There will be security considerations in the choice of which
- requirements will be implemented, but there are no specific security
- requirements during the requirements collection process.
-
-
-30. References
-
-
-30.1 Normative References
-
-
- [dnssecbis-protocol]
- "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
- Month 2004.
-
-
-30.2 Informative References
-
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
- [RFC2418] Bradner, S., "IETF Working Group Guidelines and
- Procedures", BCP 25, RFC 2418, September 1998.
-
-
-
-Authors' Addresses
-
-
- Ben Laurie
- Nominet
- 17 Perryn Road
- London W3 7LR
- England
-
-
- Phone: +44 (20) 8735 0686
- EMail: ben@algroup.co.uk
-
-
-
- Rip Loomis
- Science Applications International Corporation
- 7125 Columbia Gateway Drive, Suite 300
- Columbia, MD 21046
- US
-
-
- EMail: gilbert.r.loomis@saic.com
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 10]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
-Intellectual Property Statement
-
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights 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; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
-
- Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-
-Copyright Statement
-
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 11]
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-DNS Extensions Yuji Kamite
-Internet-Draft NTT Communications
-Expires: April 15, 2005 Masaya Nakayama
- The University of Tokyo
- October 14, 2004
-
-
-
- TKEY Secret Key Renewal Mode
- draft-ietf-dnsext-tkey-renewal-mode-05
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 April 15, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004).
-
-Abstract
-
- This document defines a new mode in TKEY and proposes an atomic
- method for changing secret keys used for TSIG periodically.
- Originally, TKEY provides methods of setting up shared secrets other
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 1]
-\f
-INTERNET-DRAFT October 2004
-
-
- than manual exchange, but it cannot control timing of key renewal
- very well though it can add or delete shared keys separately. This
- proposal is a systematical key renewal procedure intended for
- preventing signing DNS messages with old and non-safe keys
- permanently.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4
- 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4
- 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5
- 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5
- 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6
- 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7
- 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7
- 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7
- 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8
- 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8
- 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
- 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10
- 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10
- 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
- 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11
- 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12
- 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13
- 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14
- 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
- 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15
- 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15
- 4.2 Authentication Methods Considerations . . . . . . . . . . 15
- 5. Special Considerations for Two Servers' Case . . . . . . . . 16
- 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16
- 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17
- 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
- 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21
- 11.2 Informative References . . . . . . . . . . . . . . . . . . 21
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
- Intellectual Property and Copyright Statements . . . . . . . . 23
-
-
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 2]
-\f
-INTERNET-DRAFT October 2004
-
-
-1. Introduction
-
- TSIG [RFC2845] provides DNS message integrity and the
- request/transaction authentication by means of message authentication
- codes (MAC). TSIG is a practical solution in view of calculation
- speed and availability. However, TSIG does not have exchanging
- mechanism of shared secret keys between server and resolver, and
- administrators might have to exchange secret keys manually. TKEY
- [RFC2930] is introduced to solve such problem and it can exchange
- secrets for TSIG via networks.
-
- In various modes of TKEY, a server and a resolver can add or delete a
- secret key be means of TKEY message exchange. However, the existing
- TKEY does not care fully about the management of keys which became
- too old, or dangerous after long time usage.
-
- It is ideal that the number of secret which a pair of hosts share
- should be limited only one, because having too many keys for the same
- purpose might not only be a burden to resolvers for managing and
- distinguishing according to servers to query, but also does not seem
- to be safe in terms of storage and protection against attackers.
- Moreover, perhaps holding old keys long time might give attackers
- chances to compromise by scrupulous calculation.
-
- Therefore, when a new shared secret is established by TKEY, the
- previous old secret should be revoked immediately. To accomplish
- this, DNS servers must support a protocol for key renewal. This
- document specifies procedure to refresh secret keys between two hosts
- which is defined within the framework of TKEY, and it is called "TKEY
- Secret Key Renewal Mode".
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
- "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-
-1.1. Defined Words
-
- * Inception Time: Beginning of the shared secret key lifetime. This
- value is determined when the key is generated.
-
- * Expiry Limit: Time limit of the key's validity. This value is
- determined when a new key is generated. After Expiry Limit, server
- and client (resolver) must not authenticate TSIG signed with the key.
- Therefore, Renewal to the next key should be carried out before
- Expiry Limit.
-
- * Partial Revocation Time: Time when server judges the key is too old
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 3]
-\f
-INTERNET-DRAFT October 2004
-
-
- and must be updated. It must be between Inception Time and Expiry
- Limit. This value is determined by server freely following its
- security policy. e.g., If the time from Inception to Partial
- Revocation is short, renewal will be carried out more often, which
- might be safer.
-
- * Revocation Time: Time when the key becomes invalid and can be
- removed. This value is not determined in advance because it is the
- actual time when revocation is completed.
-
- * Adoption Time: Time when the new key is adopted as the next key
- formally. After Adoption, the key is valid and server and client can
- generate or verify TSIG making use of it. Adoption Time also means
- the time when it becomes possible to remove the previous key, so
- Revocation and Adoption are usually done at the same time.
-
-
- Partial
- Inception Revocation Revocation Expiry Limit
- | | | |
- |----------------|- - - - - - >>|- (revoked) -|
- | | | |
- previous key | | |
- |- - - -|-------------------->> time
- | | new key
- Inception Adoption
-
-
-1.2. New Format and Assigned Numbers
-
- TSIG
- ERROR = (PartialRevoke), TBD
-
- TKEY
- Mode = (server assignment for key renewal), TBD
- Mode = (Diffie-Hellman exchange for key renewal), TBD
- Mode = (resolver assignment for key renewal), TBD
- Mode = (key adoption), TBD
-
-
-1.3. Overview of Secret Key Renewal Mode
-
- When a server receives a query from a client signed with a TSIG key,
- It always checks if the present time is within the range of usage
- duration it considers safe. If it is judged that the key is too old,
- i.e., after Partial Revocation Time, the server comes to be in
- Partial Revocation state about the key, and this key is called
- partially revoked.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 4]
-\f
-INTERNET-DRAFT October 2004
-
-
- In this state, if a client sends a normal query (e.g., question about
- A RR) other than TKEY Renewal request with TSIG signed with the old
- key, the server returns an error message to notify that the time to
- renew has come. This is called "PartialRevoke" error message. It is
- server's choice whether it returns PartialRevoke or not. If and only
- if the server is ready for changing its own key, it decides to return
- PartialRevoke.
-
- The client which got this error is able to notice that it is
- necessary to refresh the secret. To make a new shared secret, it
- sends a TKEY Renewal request, in which several keying methods are
- available. It can make use of TSIG authentication signed with the
- partially revoked key mentioned above.
-
- After new secret establishment, the client sends a TKEY Adoption
- request for renewal confirmation. This can also be authenticated with
- the partially revoked key. If this is admitted by the server, the new
- key is formally adopted, and at the same time the corresponding old
- secret is invalidated. Then the client can send the first query again
- signed with the new key.
-
- Key renewal procedure is executed based on two-phase commit
- mechanism. The first phase is the TKEY Renewal request and its
- response, which means preparatory confirmation for key update. The
- second phase is Adoption request and its response. If the server gets
- request and client receives the response successfully, they can
- finish renewal process. If any error happens and renewal process
- fails during these phases, client should roll back to the beginning
- of the first phase, and send TKEY Renewal request again. This
- rollback can be done until the Expiry Limit of the key.
-
-
-2. Shared Secret Key Renewal
-
- Suppose a server and a client agree to change their TSIG keys
- periodically. Key renewal procedure is defined between two hosts.
-
-2.1. Key Usage Time Check
-
- Whenever a server receives a query with TSIG and can find a key that
- is used for signing it, the server checks its Inception Time, Partial
- Revocation Time and Expiry Limit (this information is usually
- memorized by the server).
-
- When the present time is before Inception Time, the server MUST NOT
- verify TSIG with the key, and server acts the same way as when the
- key used by the client is not recognized. It follows [RFC2845] 4.5.1.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 5]
-\f
-INTERNET-DRAFT October 2004
-
-
- When the present time is equal to Inception Time, or between
- Inception Time and Partial Revocation Time, the behavior of the
- server is the same as when a valid key is found. It follows [RFC2845]
- 4.5.2 and 4.5.3.
-
- When the present time is the same as the Partial Revocation Time, or
- between the Partial Revocation Time and Expiry Limit, the server
- comes to be in Partial Revocation state about the TSIG key and
- behaves according to the next section.
-
- When the present time is the same as the Expiry Time or after it, the
- server MUST NOT verify TSIG with the key, and returns error messages
- in the same way as when the key used by the client is not recognized.
- It follows [RFC2845] 4.5.1.
-
-
-2.2. Partial Revocation
-
- In Partial Revocation state, we say the server has partially revoked
- the key and the key has become a "partially revoked key".
-
- If server has received a query signed with the partially revoked key
- for TKEY Renewal request (See section 2.3.) or Key Adoption request
- (See section 2.4.), then server does proper process following each
- specification. If it is for TKEY key deletion request ([RFC2930]
- 4.2), server MAY process usual deletion operation defined therein.
-
- If server receives other types of query signed with the partially
- revoked key, and both the corresponding MAC and signed TIME are
- verified, then server begins returning answer whose TSIG error code
- is "PartialRevoke" (See section 9.). Server MUST randomly but with
- increasing frequency return PartialRevoke when in the Partial
- Revocation state.
-
- Server can decide when it actually sends PartialRevoke, checking if
- it is appropriate time for renewal. Server MUST NOT return
- PartialRevoke if this is apart long lived TSIG transaction (such as
- AXFR) that started before the Partial Revocation Time.
-
- If the client receives PartialRevoke and understands it, then it MUST
- retry the query with the old key unless a new key has been adopted.
- Client SHOULD start the process to renew the TSIG key. For key
- renewal procedure, see details in Section 2.3 and 2.4.
-
- PartialRevoke period (i.e., time while server returns PartialRevoke
- randomely) SHOULD be small, say 2-5% of key lifetime. This is
- server's choice.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 6]
-\f
-INTERNET-DRAFT October 2004
-
-
- Server MUST keep track of clients ignoring PartialRevoke, thus
- indicating ignorance of this TKEY mode.
-
- PartialRevoke error messages have the role to inform clients of the
- keys' partial revocation and urge them to send TKEY Renewal requests.
- These error responses MUST be signed with those partial revoked keys
- if the queries are signed with them. They are sent only when the
- signing keys are found to be partially revoked. If the MAC of TSIG
- cannot be verified with the partially revoked keys, servers MUST NOT
- return PartialRevoke error with MAC, but MUST return another error
- such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
- words, a server informs its key's partial revocation only when the
- MAC in the received query is valid.
-
-
-2.3. Key Renewal Message Exchange
-
-2.3.1. Query for Key Renewal
-
- If a client has received a PartialRevoke error and authenticated the
- response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
- this document, we call it Renewal request, too.) to the server. The
- request MUST be signed with TSIG or SIG(0) [RFC2931] for
- authentication. If TSIG is selected, the client can sign it with the
- partial revoked key.
-
- Key Renewal can use one of several keying methods which is indicated
- in "Mode" field of TKEY RR, and its message structure is dependent on
- that method.
-
-
-2.3.2. Response for Key Renewal
-
- The server which has received Key Renewal request first tries to
- verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
- verified with the partially revoked key, the request MUST be
- authenticated.
-
- After authentication, server must check existing old key's validity.
- If the partially revoked key indicated in the request TKEY's OldName
- and OldAlgorithm field (See section 2.3.4.) does not exist at the
- server, "BADKEY" [RFC2845] is given in Error field for response. If
- any other error happens, server returns appropriate error messages
- following the specification described in section 2.5. If there are no
- errors, server returns a Key Renewal answer. This answer MUST be
- signed with TSIG or SIG(0) for authentication.
-
- When this answer is successfully returned and no error is detected by
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 7]
-\f
-INTERNET-DRAFT October 2004
-
-
- client, a new shared secret can be established. The details of
- concrete keying procedure are given in the section 2.5.
-
- Note:
- Sometimes Adoption message and new Renewal request will cross on
- the wire. In this case the newly generated key Adoption message is
- resent.
-
-
-2.3.3. Attributes of Generated Key
-
- As a result of this message exchange, client comes to know the newly
- generated key's attributes such as key's name, Inception Time and
- Expiry Limit. They are decided by the server and told to the client;
- in particular, however, once the server has decided Expiry Limit and
- returned a response, it should obey the decision as far as it can. In
- other words, they SHOULD NOT change time values for checking Expiry
- Limit in the future without any special reason, such as security
- issue like "Emergency Compulsory Revocation" described in section 8.
-
- On the other hand, Partial Revocation Time of this generated key is
- not decided based on the request, and not informed to the client. The
- server can determine any value as long as it is between Inception
- Time and Expiry Limit. However, the period from Inception to Partial
- Revocation SHOULD be fixed as the server side's configuration or be
- set the same as the corresponding old key's one.
-
- Note:
- Even if client sends Key Renewal request though the key described
- in OldName has not been partially revoked yet, server does renewal
- processes. At the moment when the server accepts such requests
- with valid authentication, it MUST forcibly consider the key is
- already partially revoked, that is, the key's Partial Revocation
- Time must be changed into the present time (i.e., the time when
- the server receives the request).
-
-
-2.3.4. TKEY RR structure
-
- TKEY RR for Key Renewal message has the structure given below. In
- principle, format and definition for each field follows [RFC2930].
- Note that each keying scheme sometimes needs different interpretation
- of RDATA field; for detail, see section 2.5.
-
- Field Type Comment
- ------- ------ -------
- NAME domain used for a new key, see below
- TYPE u_int16_t (defined in [RFC2930])
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 8]
-\f
-INTERNET-DRAFT October 2004
-
-
- CLASS u_int16_t (defined in [RFC2930])
- TTL u_int32_t (defined in [RFC2930])
- RDLEN u_int16_t (defined in [RFC2930])
- RDATA:
- Algorithm: domain algorithm for a new key
- Inception: u_int32_t about the keying material
- Expiration: u_int32_t about the keying material
- Mode: u_int16_t scheme for key agreement
- see section 9.
- Error: u_int16_t see description below
- Key Size: u_int16_t see description below
- Key Data: octet-stream
- Other Size: u_int16_t (defined in [RFC2930])
- size of other data
- Other Data: newly defined: see description below
-
-
- For "NAME" field, both non-root and root name are allowed. It may
- be used for a new key's name in the same manner as [RFC2930] 2.1.
-
- "Algorithm" specifies which algorithm is used for agreed keying
- material, which is used for identification of the next key.
-
- "Inception" and "Expiration" are used for the valid period of
- keying material. The meanings differ somewhat according to whether
- the message is request or answer, and its keying scheme.
-
- "Key Data" has different meanings according to keying schemes.
-
- "Mode" field stores the value in accordance with the keying method,
- and see section 2.5. Servers and clients supporting TKEY Renewal
- method MUST implement "Diffie-Hellman exchange for key renewal"
- scheme. All other modes are OPTIONAL.
-
- "Error" is an extended RCODE which includes "PartialRevoke" value
- too. See section 9.
-
- "Other Data" field has the structure given below. They describe
- attributes of the key to be renewed.
-
- in Other Data filed:
-
- Field Type Comment
- ------- ------ -------
- OldNAME domain name of the old key
- OldAlgorithm domain algorithm of the old key
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 9]
-\f
-INTERNET-DRAFT October 2004
-
-
- "OldName" indicates the name of the previous key (usually,
- this is partially revoked key's name that client noticed by
- PartialRevoke answer from server), and "OldAlogirthm"
- indicates its algorithm.
-
-
-2.4. Key Adoption
-
-2.4.1. Query for Key Adoption
-
- After receiving a TKEY Renewal answer, the client gets the same
- secret as the server. Then, it sends a TKEY Adoption request. The
- request's question section's QNAME field is the same as the NAME
- filed of TKEY written below. In additional section, there is one TKEY
- RR that has the structure and values described below.
-
- "NAME" field is the new key's name to be adopted which was already
- generated by Renewal message exchange. "Algorithm" is its
- algorithm. "Inception" means the key's Inception Time, and
- "Expiration" means Expiry Limit.
-
- "Mode" field is the value of "key adoption". See section 9.
-
- "Other Data" field in Adoption has the same structure as that of
- Renewal request message. "OldName" means the previous old key, and
- "OldAlogirthm" means its algorithm.
-
- Key Adoption request MUST be signed with TSIG or SIG(0) for
- authentication. The client can sign TSIG with the previous key. Note
- that until Adoption is finished, the new key is treated as invalid,
- thus it cannot be used for authentication immediately.
-
-
-2.4.2. Response for Key Adoption
-
- The server which has received Adoption request, it verifies TSIG or
- SIG(0) accompanying it. If the TSIG is signed with the partially
- revoked key and can be verified, the message MUST be authenticated.
-
- If the next new key indicated by the request TKEY's "NAME" is not
- present at the server, BADNAME [RFC2845] is given in Error field and
- the error message is returned.
-
- If the next key exists but it has not been adopted formally yet, the
- server confirms the previous key's existence indicated by the
- "OldName" and "OldAlgorithm" field. If it succeeds, the server
- executes Adoption of the next key and Revocation of the previous key.
- Response message duplicates the request's TKEY RR with NOERROR,
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 10]
-\f
-INTERNET-DRAFT October 2004
-
-
- including "OldName" and "OldAlgorithm" that indicate the revoked key.
-
- If the next key exists but it is already adopted, the server returns
- a response message regardless of the substance of the request TKEY's
- "OldName". In this response, Response TKEY RR has the same data as
- the request's one except as to its "Other Data" that is changed into
- null (i.e., "Other Size" is zero), which is intended for telling the
- client that the previous key name was ignored, and the new key is
- already available.
-
- Client sometimes has to retry Adoption request. Suppose the client
- sent request signed with the partially revoked key, but its response
- did not return successfully (e.g., due to the drop of UDP packet).
- Client will probably retry Adoption request; however, the request
- will be refused in the form of TSIG "BADKEY" error because the
- previous key was already revoked. In this case, client will
- retransmit Adoption request signed with the next key, and expect a
- response which has null "Other Data" for confirming the completion of
- renewal.
-
-
-2.5. Keying Schemes
-
- In Renewal message exchanges, there are no limitations as to which
- keying method is actually used. The specification of keying
- algorithms is independent of the general procedure of Renewal that is
- described in section 2.3.
-
- Now this document specifies three algorithms in this section, but
- other future documents can make extensions defining other methods.
-
-
-2.5.1. DH Exchange for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.1. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as keying material
- computation, are the exactly same as the specification of [RFC2930]
- 4.1.
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. KEY RR is
- the client's Diffie-Hellman public key [RFC2539].
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 11]
-\f
-INTERNET-DRAFT October 2004
-
-
- TKEY "Mode" field stores the value of "DH exchange for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
-
- Response
- The server which received this request first verifies the TSIG,
- SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
- old key's existence validity is checked, following section 2.3. If
- any incompatible DH key is found in the request, "BADKEY"
- [RFC2845] is given in Error field for response. "FORMERR" is given
- if the query included no DH KEY.
-
- If there are no errors, the server processes a response according
- to Diffie-Hellman algorithm and returns the answer. In this
- answer, there is one TKEY RR in answer section and KEY RR(s) in
- additional section.
-
- As long as no error has occurred, all values of TKEY are equal to
- that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
- Inception, Expiration, Key Size and Key Data.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client MUST use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" is set to be the time when the new key is
- actually generated or the time before it, and it will be regarded
- as Inception Time. "Expiration" is determined by the server, and
- it will be regarded as Expiry Limit.
-
- TKEY "Key Data" is used as an additional nonce, following
- [RFC2930] 4.1.
-
- The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
- the additional section and a server Diffie-Hellman KEY RR will
- also be present in the answer section, following [RFC2930] 4.1.
-
-
-2.5.2. Server Assigned Keying for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.4. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as secret encrypting
- method, are the exactly same as the specification of [RFC2930] 4.4.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 12]
-\f
-INTERNET-DRAFT October 2004
-
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. KEY RR is
- used in encrypting the response.
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
- TKEY "Mode" field stores the value of "server assignment for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is provided following the specification of
- [RFC2930] 4.4.
-
- Response
- The server which received this request first verifies the TSIG,
- SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
- old key's existence validity is checked, following section 2.3.
- "FORMERR" is given if the query specified no encryption key.
-
- If there are no errors, the server response contains one TKEY RR
- in the answer section, and echoes the KEY RR provided in the query
- in the additional information section.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client MUST use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" is set to be the time when the new key is
- actually generated or the time before it, and it will be regarded
- as Inception Time. "Expiration" is determined by the server, and
- it will be regarded as Expiry Limit.
-
- TKEY "Key Data" is the assigned keying data encrypted under the
- public key in the resolver provided KEY RR, which is the same as
- [RFC2930] 4.4.
-
-
-2.5.3. Resolver Assigned Keying for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.5. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as secret encrypting
- method, are the exactly same as the specification of [RFC2930] 4.5.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 13]
-\f
-INTERNET-DRAFT October 2004
-
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. TKEY RR
- has the encrypted keying material and KEY RR is the server public
- key used to encrypt the data.
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
- TKEY "Mode" field stores the value of "resolver assignment for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is the encrypted keying material.
-
- Response
- The server which received this request first verifies the TSIG,
- SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
- old key's existence validity is checked, following section 2.3.
- "FORMERR" is given if the server does not have the corresponding
- private key for the KEY RR that was shown sin the request.
-
- If there are no errors, the server returns a response. The
- response contains a TKEY RR in the answer section to tell the
- shared key's name and its usage time values.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client MUST use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" is set to be the time when the new key is
- actually generated or the time before it, and it will be regarded
- as Inception Time. "Expiration" is determined by the server, and
- it will be regarded as Expiry Limit.
-
-
-2.6. Considerations about Non-compliant Hosts
-
- Key Renewal requests and responses must be exchanged between hosts
- which can understand them and do proper processes. PartialRevoke
- error messages will be only ignored if they should be returned to
- non-compliant hosts.
-
- Note that server does not inform actively the necessity of renewal to
- clients, but inform it as responses invoked by client's query.
- Server needs not care whether the PartialRevoke errors has reached
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 14]
-\f
-INTERNET-DRAFT October 2004
-
-
- client or not. If client has not received yet because of any reasons
- such as packet drops, it will resend the queries, and finally will be
- able to get PartialRevoke information.
-
-
-3. Secret Storage
-
- Every server keeps all secrets and attached information, e.g.,
- Inception Time, Expiry Limit, etc. safely to be able to recover from
- unexpected stop. To accomplish this, formally adopted keys SHOULD be
- memorized not only on memory, but also be stored in the form of some
- files. It will become more secure if they are stored in ecrypted
- form.
-
-
-4. Compulsory Key Revocation
-
-4.1. Compulsory Key Revocation by Server
-
- There is a rare but possible case that although servers have already
- partially revoked keys, clients do not try to send any Renewal
- requests. If this state continues, in the future it will become the
- time of Expiry Limit. After Expiry Limit, the keys will be expired
- and completely removed, so this is called Compulsory Key Revocation
- by server.
-
- If Expiry Limit is too distant from the Partial Revocation Time, then
- even though very long time passes, clients will be able to refresh
- secrets only if they add TSIG signed with those old partially revoked
- keys into requests, which is not safe.
-
- On the other hand, if Expiry Limit is too close to Partial Revocation
- Time, perhaps clients might not be able to notice their keys' Partial
- Revocation by getting "PartialRevoke" errors.
-
- Therefore, servers should set proper Expiry Limit to their keys,
- considering both their keys' safety, and enough time for clients to
- send requests and process renewal.
-
-
-4.2. Authentication Methods Considerations
-
- It might be ideal to provide both SIG(0) and TSIG as authentication
- methods. For example:
-
- A client and a server start SIG(0) authentication at first, to
- establish TSIG shared keys by means of "Query for Diffie-Hellman
- Exchanged Keying" as described in [RFC2930] 4.1. Once they get
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 15]
-\f
-INTERNET-DRAFT October 2004
-
-
- shared secret, they keep using TSIG for queries and responses.
- After a while the server returns a "ParitalRevoke" error and they
- begin a key renewal process. Both TSIG signed with partially
- revoked keys and SIG(0) are okay for authentication, but TSIG would
- be easier to use considering calculation efficiency.
-
- Suppose now client is halted for long time with some reason.
- Because server does not execute any renewal process, it will
- finally do Compulsory Revocation. Even if client restarts and sends
- a key Renewal request, it will fail because old key is already
- deleted at server.
-
- At this moment, however, if client also uses SIG(0) as another
- authentication method, it can make a new shared key again and
- recover successfully by sending "Query for Diffie-Hellman Exchanged
- Keying" with SIG(0).
-
-
-5. Special Considerations for Two servers' Case
-
- This section refers to the case where both hosts are DNS servers
- which can act as full resolvers as well and using one shared key
- only. If one server (called Server A) wants to refresh a shared key
- (called "Key A-B"), it will await a TKEY Renewal request from the
- other server (called Server B). However, perhaps Server A wants to
- refresh the key right now.
-
- In this case, Server A is allowed to send a Renewal request to Server
- B, if Server A knows the Key A-B is too old and wants to renew it
- immediately.
-
- Note that the initiative in key renewal belongs to Server A because
- it can notice the Partial Revocation Time and decide key renewal. If
- Server B has information about Partial Revocation Time as well, it
- can also decide for itself to send Renewal request to Server A.
- However, it is not essential for both two servers have information
- about key renewal timing.
-
-5.1. To Cope with Collisions of Renewal Requests
-
- At least one of two hosts which use Key Renewal must know their key
- renewal information such as Partial Revocation Time. It is okay that
- both hosts have it.
-
- Provided that both two servers know key renewal timing information,
- there is possibility for them to begin partial revocation and sending
- Renewal requests to each other at the same time. Such collisions will
- not happen so often because Renewal requests are usually invoked when
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 16]
-\f
-INTERNET-DRAFT October 2004
-
-
- hosts want to send queries, but it is possible.
-
- When one of two servers tries to send Renewal requests, it MUST
- protect old secrets that it has partially revoked and prevent it from
- being refreshed by any requests from the other server (i.e., it must
- lock the old secret during the process of renewal). While the server
- is sending Renewal requests and waiting responses, it ignores the
- other server's Renewal requests.
-
- Therefore, servers might fail to change secrets by means of their own
- requests to others. After failure they will try to resend, but they
- should wait for random delays by the next retries. If they get any
- Renewal requests from others while they are waiting, their shared
- keys may be refreshed, then they do not need to send any Renewal
- requests now for themselves.
-
-
-6. Key Name Considerations
-
- Since both servers and clients have only to distinguish new secrets
- and old ones, keys' names do not need to be specified strictly.
- However, it is recommended that some serial number or key generation
- time be added to the name and that the names of keys between the same
- pair of hosts should have some common labels among their keys. For
- example, suppose A.example.com. and B.example.com. share the key
- "<serial number>.A.example.com.B.example.com." such as
- "10010.A.example.com.B.example.com.". After key renewal, they change
- their secret and name into "10011.A.example.com.B.example.com."
-
- Servers and clients must be able to use keys properly for each query.
- Because TSIG secret keys themselves do not have any particular IDs to
- be distinguished and would be identified by their names and
- algorithm, it must be understood correctly what keys are refreshed.
-
-
-7. Example Usage of Secret Key Renewal Mode
-
- This is an example of Renewal mode usage where a Server,
- server.example.com, and a Client, client.exmple.com have an initial
- shared secret key named "00.client.example.com.server.example.com".
-
- (1) The time values for key
- "00.client.example.com.server.example.com" was set as follows:
- Inception Time is at 1:00, Expiry Limit is at 21:00.
-
- (2) At Server, renewal time has been set: Partial Revocation Time
- is at 20:00.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 17]
-\f
-INTERNET-DRAFT October 2004
-
-
- (3) Suppose the present time is 19:55. If Client sends a query
- signed with key "00.client.example.com.server.example.com" to ask
- the IP address of "www.example.com", finally it will get a proper
- answer from Server with valid TSIG (NOERROR).
-
- (4) At 20:05. Client sends a query to ask the IP address of
- "www2.example.com". It is signed with key
- "00.client.example.com.server.example.com". Server returns an
- answer for the IP address. However, server has begun retuning
- PartialRevoke Error randomely. This answer includes valid TSIG MAC
- signed with "00.client.example.com.server.example.com", and its
- Error Code indicates PartialRevoke. Client understands that the
- current key is partially revoked.
-
- (5) At 20:06. Client sends a Renewal request to Server. This
- request is signed with key
- "00.client.example.com.server.example.com". It includes data such
- as:
-
- Question Section:
- QNAME = 01.client.example.com. (Client can set this freely)
- TYPE = TKEY
-
- Additional Section:
- 01.client.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 20:00)
- Expiration = (value meaning next day's 16:00)
- Mode = (DH exchange for key renewal)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
- Additional Section also contains a KEY RR for DH and a TSIG RR.
-
- (6) As soon as Server receives this request, it verifies TSIG. It
- is signed with the partially revoked key
- "00.client.example.com.server.example.com". and Server accepts the
- request. It creates a new key by Diffie-Hellman calculation and
- returns an answer which includes data such as:
-
- Answer Section:
- 01.client.example.com.server.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 20:00)
- Expiration = (value meaning next day's 16:00)
- Mode = (DH exchange for key renewal)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 18]
-\f
-INTERNET-DRAFT October 2004
-
-
- Answer Section also contains KEY RRs for DH.
-
- Additional Section also contains a TSIG RR.
- This response is signed with key
- "00.client.example.com.server.example.com" without error.
-
- At the same time, Server decides to set the Partial Revocation Time
- of this new key "01.client.example.com.server.example.com." as next
- day's 15:00.
-
- (7) Client gets the response and checks TSIG MAC, and calculates
- Diffie-Hellman. It will get a new key, and it has been named
- "01.client.example.com.server.example.com" by Server.
-
- (8) At 20:07. Client sends an Adoption request to Server. This
- request is signed with the previous key
- "00.client.example.com.server.example.com". It includes:
-
- Question Section:
- QNAME = 01.client.example.com.server.example.com.
- TYPE = TKEY
-
- Additional Section:
- 01.client.example.com.server.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 20:00)
- Expiration = (value meaning next day's 16:00)
- Mode = (key adoption)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
- Additional Section also contains a TSIG RR.
-
- (9) Server verifies the query's TSIG. It is signed with the
- previous key and authenticated. It returns a response whose TKEY RR
- is the same as the request's one. The response is signed with key
- "00.client.example.com.server.example.com.". As soon as the
- response is sent, Server revokes and removes the previous key. At
- the same time, key "01.client.example.com.server.example.com." is
- validated.
-
- (10) Client acknowledges the success of Adoption by receiving the
- response. Then, it retries to send an original question about
- "www2.example.com". It is signed with the adopted key
- "01.client.example.com.server.example.com", so Server authenticates
- it and returns an answer.
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 19]
-\f
-INTERNET-DRAFT October 2004
-
-
- (11) This key is used until next day's 15:00. After that, it will
- be partially revoked again.
-
-
-8. Security Considerations
-
- This document considers about how to refresh shared secret. Secret
- changed by this method is used at servers in support of TSIG
- [RFC2845].
-
- [RFC2104] says that current attacks to HMAC do not indicate a
- specific recommended frequency for key changes but periodic key
- refreshment is a fundamental security practice that helps against
- potential weaknesses of the function and keys, and limits the damage
- of an exposed key. TKEY Secret Key Renewal provides the method of
- periodical key refreshment.
-
- In TKEY Secret Key Renewal, clients need to send two requests
- (Renewal and Adoption) and spend time to finish their key renewal
- processes. Thus the usage period of secrets should be considered
- carefully based on both TKEY processing performance and security.
-
- This document specifies the procedure of periodical key renewal, but
- actually there is possibility for servers to have no choice other
- than revoking their secret keys immediately especially when the keys
- are found to be compromised by attackers. This is called "Emergency
- Compulsory Revocation". For example, suppose the original Expiry
- Limit was set at 21:00, Partial Revocation Time at 20:00 and
- Inception Time at 1:00. if at 11:00 the key is found to be
- compromised, the server sets Expiry Limit forcibly to be 11:00 or
- before it.
-
- Consequently, once Compulsory Revocation (See section 4.) is carried
- out, normal renewal process described in this document cannot be done
- any more as far as the key is concerned. However, after such
- accidents happened, the two hosts are able to establish secret keys
- and begin renewal procedure only if they have other (non-compromised)
- shared TSIG keys or safe SIG(0) keys for the authentication of
- initial secret establishment such as Diffie-Hellman Exchanged Keying.
-
-
-9. IANA Considerations
-
- IANA needs to allocate a value for "DH exchange for key renewal",
- "server assignment for key renewal", "resolver assignment for key
- renewal" and "key adoption" in the mode filed of TKEY. It also needs
- to allocate a value for "PartialRevoke" from the extended RCODE
- space.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 20]
-\f
-INTERNET-DRAFT October 2004
-
-
-10. Acknowledgements
-
- The authors would like to thank Olafur Gudmundsson, whose helpful
- input and comments contributed greatly to this document.
-
-
-11. References
-
-11.1. Normative References
-
-[RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
-[RFC2539]
- D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", RFC 2539, March 1999.
-
-[RFC2845]
- Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
- May 2000.
-
-[RFC2930]
- D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
- RFC 2930, September 2000.
-
-[RFC2931]
- D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
- )", RFC 2931, September 2000.
-
-11.2. Informative References
-
-[RFC2104]
- H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
- Authentication", RFC2104, February 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 21]
-\f
-INTERNET-DRAFT October 2004
-
-
-Authors' Addresses
-
- Yuji Kamite
- NTT Communications Corporation
- Tokyo Opera City Tower
- 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
- 163-1421, Japan
- EMail: y.kamite@ntt.com
-
-
- Masaya Nakayama
- Information Technology Center, The University of Tokyo
- 2-11-16 Yayoi, Bunkyo-ku, Tokyo
- 113-8658, Japan
- EMail: nakayama@nc.u-tokyo.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 22]
-\f
-INTERNET-DRAFT October 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights 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; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 23]
-\f
-
-
+++ /dev/null
-Network Working Group J. Ihren
-Internet-Draft Autonomica AB
-Expires: April 18, 2005 O. Kolkman
- RIPE NCC
- B. Manning
- EP.net
- October 18, 2004
-
-
-
- An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
- DNSSEC Trust Anchors.
- draft-ietf-dnsext-trustupdate-threshold-00
-
-
-Status of this Memo
-
-
- By submitting this Internet-Draft, I certify that any applicable
- patent or other IPR claims of which I am aware have been disclosed,
- and any of which I become aware will be disclosed, in accordance with
- RFC 3668.
-
-
- 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 April 18, 2005.
-
-
-Copyright Notice
-
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-
-Abstract
-
-
- The DNS Security Extensions (DNSSEC) works by validating so called
- chains of authority. The start of these chains of authority are
- usually public keys that are anchored in the DNS clients. These keys
- are known as the so called trust anchors.
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 1]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- This memo describes a method how these client trust anchors can be
- replaced using the DNS validation and querying mechanisms (in-band)
- when the key pairs used for signing by zone owner are rolled.
-
-
- This memo also describes a method to establish the validity of trust
- anchors for initial configuration, or priming, using out of band
- mechanisms.
-
-
-Table of Contents
-
-
- 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry
- Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Introduction and Background . . . . . . . . . . . . . . . . . 5
- 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5
- 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7
- 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8
- 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9
- 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10
- 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11
- 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
- 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12
- 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12
- 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12
- 3.6 Removal of trust anchors for a trust point . . . . . . . . 12
- 3.7 No need for resolver-side overlap of old and new keys . . 13
- 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14
- 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
- 4.1.1 Bootstrapping trust anchors using a priming key . . . 14
- 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15
- 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
- 6.1 Threshold-based Trust Update Security Considerations . . . 17
- 6.2 Priming Key Security Considerations . . . . . . . . . . . 17
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20
- 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
- A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
- B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23
- B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23
- B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23
- Intellectual Property and Copyright Statements . . . . . . . . 24
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 2]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-1. Terminology
-
-
- The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
- and "MAY" in this document are to be interpreted as described in
- RFC2119 [1].
-
-
- The term "zone" refers to the unit of administrative control in the
- Domain Name System. In this document "name server" denotes a DNS
- name server that is authoritative (i.e. knows all there is to know)
- for a DNS zone. A "zone owner" is the entity responsible for signing
- and publishing a zone on a name server. The terms "authentication
- chain", "bogus", "trust anchors" and "Island of Security" are defined
- in [4]. Throughout this document we use the term "resolver" to mean
- "Validating Stub Resolvers" as defined in [4].
-
-
- We use the term "security apex" as the zone for which a trust anchor
- has been configured (by validating clients) and which is therefore,
- by definition, at the root of an island of security. The
- configuration of trust anchors is a client side issue. Therefore a
- zone owner may not always know if their zone has become a security
- apex.
-
-
- A "stale anchor" is a trust anchor (a public key) that relates to a
- key that is not used for signing. Since trust anchors indicate that
- a zone is supposed to be secure a validator will mark the all data in
- an island of security as bogus when all trust anchors become stale.
-
-
- It is assumed that the reader is familiar with public key
- cryptography concepts [REF: Schneier Applied Cryptography] and is
- able to distinguish between the private and public parts of a key
- based on the context in which we use the term "key". If there is a
- possible ambiguity we will explicitly mention if a private or a
- public part of a key is used.
-
-
- The term "administrator" is used loosely throughout the text. In
- some cases an administrator is meant to be a person, in other cases
- the administrator may be a process that has been delegated certain
- responsibilities.
-
-
-1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points
-
-
- Although the DNSSEC protocol does not make a distinction between
- different keys the operational practice is that a distinction is made
- between zone signing keys and key signing keys. A key signing key is
- used to exclusively sign the DNSKEY Resource Record (RR) set at the
- apex of a zone and the zone signing keys sign all the data in the
- zone (including the DNSKEY RRset at the apex).
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 3]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- Keys that are intended to be used as the start of the authentication
- chain for a particular zone, either because they are pointed to by a
- parental DS RR or because they are configured as a trust anchor, are
- called Secure Entry Point (SEP) keys. In practice these SEP keys
- will be key signing keys.
-
-
- In order for the mechanism described herein to work the keys that are
- intended to be used as secure entry points MUST have the SEP [2] flag
- set. In the examples it is assumed that keys with the SEP flag set
- are used as key signing keys and thus exclusively sign the DNSKEY
- RRset published at the apex of the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 4]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-2. Introduction and Background
-
-
- When DNSSEC signatures are validated the resolver constructs a chain
- of authority from a pre-configured trust anchor to the DNSKEY
- Resource Record (RR), which contains the public key that validates
- the signature stored in an RRSIG RR. DNSSEC is designed so that the
- administrator of a resolver can validate data in multiple islands of
- security by configuring multiple trust anchors.
-
-
- It is expected that resolvers will have more than one trust anchor
- configured. Although there is no deployment experience it is not
- unreasonable to expect resolvers to be configured with a number of
- trust anchors that varies between order 1 and order 1000. Because
- zone owners are expected to roll their keys, trust anchors will have
- to be maintained (in the resolver end) in order not to become stale.
-
-
- Since there is no global key maintenance policy for zone owners and
- there are no mechanisms in the DNS to signal the key maintenance
- policy it may be very hard for resolvers administrators to keep their
- set of trust anchors up to date. For instance, if there is only one
- trust anchor configured and the key maintenance policy is clearly
- published, through some out of band trusted channel, then a resolver
- administrator can probably keep track of key rollovers and update the
- trust anchor manually. However, with an increasing number of trust
- anchors all rolled according to individual policies that are all
- published through different channels this soon becomes an
- unmanageable problem.
-
-
-2.1 Dangers of Stale Trust Anchors
-
-
- Whenever a SEP key at a security apex is rolled there exists a danger
- that "stale anchors" are created. A stale anchor is a trust anchor
- (i.e. a public key configured in a validating resolver) that relates
- to a private key that is no longer used for signing.
-
-
- The problem with a stale anchors is that they will (from the
- validating resolvers point of view) prove data to be false even
- though it is actually correct. This is because the data is either
- signed by a new key or is no longer signed and the resolver expects
- data to be signed by the old (now stale) key.
-
-
- This situation is arguably worse than not having a trusted key
- configured for the secure entry point, since with a stale key no
- lookup is typically possible (presuming that the default
- configuration of a validating recursive nameserver is to not give out
- data that is signed but failed to verify.
-
-
- The danger of making configured trust anchors become stale anchors
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 5]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- may be a reason for zone owners not to roll their keys. If a
- resolver is configured with many trust anchors that need manual
- maintenance it may be easy to not notice a key rollover at a security
- apex, resulting in a stale anchor.
-
-
- In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
- track key rollovers and modify the configured trust anchors
- accordingly. The mechanism is stateless and does not need protocol
- extensions. The proposed design is that this mechanism is
- implemented as a "trust updating machine" that is run entirely
- separate from the validating resolver except that the trust updater
- will have influence over the trust anchors used by the latter.
-
-
- In Section 4 we describe a method [Editors note: for now only the
- frame work and a set of requirements] to install trust anchors. This
- method can be used at first configuration or when the trust anchors
- became stale (typically due to a failure to track several rollover
- events).
-
-
- The choice for which domains trust anchors are to be configured is a
- local policy issue. So is the choice which trust anchors has
- prevalence if there are multiple chains of trust to a given piece of
- DNS data (e.g. when a parent zone and its child both have trust
- anchors configured). Both issues are out of the scope of this
- document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 6]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-3. Threshold-based Trust Anchor Rollover
-
-
-3.1 The Rollover
-
-
- When a key pair is replaced all signatures (in DNSSEC these are the
- RRSIG records) created with the old key will be replaced by new
- signatures created by the new key. Access to the new public key is
- needed to verify these signatures.
-
-
- Since zone signing keys are in "the middle" of a chain of authority
- they can be verified using the signature made by a key signing key.
- Rollover of zone signing keys is therefore transparent to validators
- and requires no action in the validator end.
-
-
- But if a key signing key is rolled a resolver can determine its
- authenticity by either following the authorization chain from the
- parents DS record, an out-of-DNS authentication mechanism or by
- relying on other trust anchors known for the zone in which the key is
- rolled.
-
-
- The threshold trust anchor rollover mechanism (or trust update),
- described below, is based on using existing trust anchors to verify a
- subset of the available signatures. This is then used as the basis
- for a decision to accept the new keys as valid trust anchors.
-
-
- Our example pseudo zone below contains a number of key signing keys
- numbered 1 through Y and two zone signing keys A and B. During a key
- rollover key 2 is replaced by key Y+1. The zone content changes
- from:
-
-
- example.com. DNSKEY key1
- example.com. DNSKEY key2
- example.com. DNSKEY key3
- ...
- example.com. DNSKEY keyY
-
-
- example.com. DNSKEY keyA
- example.com. DNSKEY keyB
-
-
- example.com. RRSIG DNSKEY ... (key1)
- example.com. RRSIG DNSKEY ... (key2)
- example.com. RRSIG DNSKEY ... (key3)
- ...
- example.com. RRSIG DNSKEY ... (keyY)
- example.com. RRSIG DNSKEY ... (keyA)
- example.com. RRSIG DNSKEY ... (keyB)
-
-
- to:
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 7]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- example.com. DNSKEY key1
- example.com. DNSKEY key3
- ...
- example.com. DNSKEY keyY
- example.com. DNSKEY keyY+1
-
-
- example.com. RRSIG DNSKEY ... (key1)
- example.com. RRSIG DNSKEY ... (key3)
- ...
- example.com. RRSIG DNSKEY ... (keyY)
- example.com. RRSIG DNSKEY ... (keyY+1)
- example.com. RRSIG DNSKEY ... (keyA)
- example.com. RRSIG DNSKEY ... (keyB)
-
-
- When the rollover becomes visible to the verifying stub resolver it
- will be able to verify the RRSIGs associated with key1, key3 ...
- keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will
- not be used for validation, since that key is previously unknown and
- therefore not trusted.
-
-
- Note that this example is simplified. Because of operational
- considerations described in [5] having a period during which the two
- key signing keys are both available is necessary.
-
-
-3.2 Threshold-based Trust Update
-
-
- The threshold-based trust update algorithm applies as follows. If
- for a particular secure entry point
- o if the DNSKEY RRset in the zone has been replaced by a more recent
- one (as determined by comparing the RRSIG inception dates)
- and
- o if at least M configured trust anchors directly verify the related
- RRSIGs over the new DNSKEY RRset
- and
- o the number of configured trust anchors that verify the related
- RRSIGs over the new DNSKEY RRset exceed a locally defined minimum
- number that should be greater than one
- then all the trust anchors for the particular secure entry point are
- replaced by the set of keys from the zones DNSKEY RRset that have the
- SEP flag set.
-
-
- The choices for the rollover acceptance policy parameter M is left to
- the administrator of the resolver. To be certain that a rollover is
- accepted up by resolvers using this mechanism zone owners should roll
- as few SEP keys at a time as possible (preferably just one). That
- way they comply to the most strict rollover acceptance policy of
- M=N-1.
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 8]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- The value of M has an upper bound, limited by the number of of SEP
- keys a zone owner publishes (i.e. N). But there is also a lower
- bound, since it will not be safe to base the trust in too few
- signatures. The corner case is M=1 when any validating RRSIG will be
- sufficient for a complete replacement of the trust anchors for that
- secure entry point. This is not a recommended configuration, since
- that will allow an attacker to initiate rollover of the trust anchors
- himself given access to just one compromised key. Hence M should in
- be strictly larger than 1 as shown by the third requirement above.
-
-
- If the rollover acceptance policy is M=1 then the result for the
- rollover in our example above should be that the local database of
- trust anchors is updated by removing key "key2" from and adding key
- "keyY+1" to the key store.
-
-
-3.3 Possible Trust Update States
-
-
- We define five states for trust anchor configuration at the client
- side.
- PRIMING: There are no trust anchors configured. There may be priming
- keys available for initial priming of trust anchors.
- IN-SYNC: The set of trust anchors configured exactly matches the set
- of SEP keys used by the zone owner to sign the zone.
- OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
- set of SEP keys used by the zone owner to sign the zone but there
- are enough SEP key in use by the zone owner that is also in the
- trust anchor configuration.
- UNSYNCABLE: There is not enough overlap between the configured trust
- anchors and the set of SEP keys used to sign the zone for the new
- set to be accepted by the validator (i.e. the number of
- signatures that verify is not sufficient).
- STALE: There is no overlap between the configured trust anchors and
- the set of SEP keys used to sign the zone. Here validation of
- data is no longer possible and hence we are in a situation where
- the trust anchors are stale.
-
-
- Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of
- the automatic trust update mechanism. The PRIMING state is where a
- validator is located before acquiring an up-to-date set of trust
- anchors. The transition from PRIMING to IN-SYNC is manual (see
- Section 4 below).
-
-
- Example: assume a secure entry point with four SEP keys and a
- validator with the policy that it will accept any update to the set
- of trust anchors as long as no more than two signatures fail to
- validate (i.e. M >= N-2) and at least two signature does validate
- (i.e. M >= 2). In this case the rollover of a single key will move
- the validator from IN-SYNC to OUT-OF-SYNC. When the trust update
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 9]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- state machine updates the trust anchors it returns to state IN-SYNC.
-
-
- If if for some reason it fails to update the trust anchors then the
- next rollover (of a different key) will move the validator from
- OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys
- that are configured as trust anchors and that is sufficient to accpt
- an automatic update of the trust anchors.
-
-
- The UNSYNCABLE state is where a validator is located if it for some
- reason fails to incorporate enough updates to the trust anchors to be
- able to accept new updates according to its local policy. In this
- example (i.e. with the policy specified above) this will either be
- because M < N-2 or M < 2, which does not suffice to authenticate a
- successful update of trust anchors.
-
-
- Continuing with the previous example where two of the four SEP keys
- have already rolled, but the validator has failed to update the set
- of trust anchors. When the third key rolls over there will only be
- one trust anchor left that can do successful validation. This is not
- sufficient to enable automatic update of the trust anchors, hence the
- new state is UNSYNCABLE. Note, however, that the remaining
- up-to-date trust anchor is still enough to do successful validation
- so the validator is still "working" from a DNSSEC point of view.
-
-
- The STALE state, finally, is where a validator ends up when it has
- zero remaining current trust anchors. This is a dangerous state,
- since the stale trust anchors will cause all validation to fail. The
- escape is to remove the stale trust anchors and thereby revert to the
- PRIMING state.
-
-
-3.4 Implementation notes
-
-
- The DNSSEC protocol specification ordains that a DNSKEY to which a DS
- record points should be self-signed. Since the keys that serve as
- trust anchors and the keys that are pointed to by DS records serve
- the same purpose, they are both secure entry points, we RECOMMEND
- that zone owners who want to facilitate the automated rollover scheme
- documented herein self-sign DNSKEYs with the SEP bit set and that
- implementation check that DNSKEYs with the SEP bit set are
- self-signed.
-
-
- In order to maintain a uniform way of determining that a keyset in
- the zone has been replaced by a more recent set the automatic trust
- update machine SHOULD only accept new DNSKEY RRsets if the
- accompanying RRSIGs show a more recent inception date than the
- present set of trust anchors. This is also needed as a safe guard
- against possible replay attacks where old updates are replayed
- "backwards" (i.e. one change at a time, but going in the wrong
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 10]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- direction, thereby luring the validator into the UNSYNCABLE and
- finally STALE states).
-
-
- In order to be resilient against failures the implementation should
- collect the DNSKEY RRsets from (other) authoritative servers if
- verification of the self signatures fails.
-
-
- The threshold-based trust update mechanism SHOULD only be applied to
- algorithms, as represented in the algorithm field in the DNSKEY/RRSIG
- [3], that the resolver is aware of. In other words the SEP keys of
- unknown algorithms should not be used when counting the number of
- available signatures (the N constant) and the SEP keys of unknown
- algorithm should not be entered as trust anchors.
-
-
- When in state UNSYNCABLE or STALE manual intervention will be needed
- to return to the IN-SYNC state. These states should be flagged. The
- most appropriate action is human audit possibly followed by
- re-priming (Section 4) the keyset (i.e. manual transfer to the
- PRIMING state through removal of the configured trust anchors).
-
-
- An implementation should regularly probe the the authoritative
- nameservers for new keys. Since there is no mechanism to publish
- rollover frequencies this document RECOMMENDS zone owners not to roll
- their key signing keys more often than once per month and resolver
- administrators to probe for key rollsovers (and apply the threshold
- criterion for acceptance of trust update) not less often than once
- per month. If the rollover frequency is higher than the probing
- frequency then trust anchors may become stale. The exact relation
- between the frequencies depends on the number of SEP keys rolled by
- the zone owner and the value M configured by the resolver
- administrator.
-
-
- In all the cases below a transaction where the threshold criterion is
- not satisfied should be considered bad (i.e. possibly spoofed or
- otherwise corrupted data). The most appropriate action is human
- audit.
-
-
- There is one case where a "bad" state may be escaped from in an
- automated fashion. This is when entering the STALE state where all
- DNSSEC validation starts to fail. If this happens it is concievable
- that it is better to completely discard the stale trust anchors
- (thereby reverting to the PRIMING state where validation is not
- possible). A local policy that automates removal of stale trust
- anchors is therefore suggested.
-
-
-3.5 Possible transactions
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 11]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-3.5.1 Single DNSKEY replaced
-
-
- This is probably the most typical transaction on the zone owners
- part. The result should be that if the threshold criterion is
- satisfied then the key store is updated by removal of the old trust
- anchor and addition of the new key as a new trust anchor. Note that
- if the DNSKEY RRset contains exactly M keys replacement of keys is
- not possible, i.e. for automatic rollover to work M must be stricly
- less than N.
-
-
-3.5.2 Addition of a new DNSKEY (no removal)
-
-
- If the threshold criterion is satisfied then the new key is added as
- a configured trust anchor. Not more than N-M keys can be added at
- once, since otherwise the algorithm will fail.
-
-
-3.5.3 Removal of old DNSKEY (no addition)
-
-
- If the threshold criterion is satisfied then the old key is removed
- from being a configured trust anchor. Note that it is not possible
- to reduce the size of the DNSKEY RRset to a size smaller than the
- minimum required value for M.
-
-
-3.5.4 Multiple DNSKEYs replaced
-
-
- Arguably it is not a good idea for the zone administrator to replace
- several keys at the same time, but from the resolver point of view
- this is exactly what will happen if the validating resolver for some
- reason failed to notice a previous rollover event.
-
-
- Not more than N-M keys can be replaced at one time or the threshold
- criterion will not be satisfied. Or, expressed another way: as long
- as the number of changed keys is less than or equal to N-M the
- validator is in state OUT-OF-SYNC. When the number of changed keys
- becomes greater than N-M the state changes to UNSYNCABLE and manual
- action is needed.
-
-
-3.6 Removal of trust anchors for a trust point
-
-
- If the parent of a secure entry point gets signed and it's trusted
- keys get configured in the key store of the validating resolver then
- the configured trust anchors for the child should be removed entirely
- unless explicitly configured (in the utility configuration) to be an
- exception.
-
-
- The reason for such a configuration would be that the resolver has a
- local policy that requires maintenance of trusted keys further down
- the tree hierarchy than strictly needed from the point of view.
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 12]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- The default action when the parent zone changes from unsigned to
- signed should be to remove the configured trust anchors for the
- child. This form of "garbage collect" will ensure that the automatic
- rollover machinery scales as DNSSEC deployment progresses.
-
-
-3.7 No need for resolver-side overlap of old and new keys
-
-
- It is worth pointing out that there is no need for the resolver to
- keep state about old keys versus new keys, beyond the requirement of
- tracking signature inception time for the covering RRSIGs as
- described in Section 3.4.
-
-
- From the resolver point of view there are only trusted and not
- trusted keys. The reason is that the zone owner needs to do proper
- maintenance of RRSIGs regardless of the resolver rollover mechanism
- and hence must ensure that no key rolled out out the DNSKEY set until
- there cannot be any RRSIGs created by this key still legally cached.
-
-
- Hence the rollover mechanism is entirely stateless with regard to the
- keys involved: as soon as the resolver (or in this case the rollover
- tracking utility) detects a change in the DNSKEY RRset (i.e. it is
- now in the state OUT-OF-SYNC) with a sufficient number of matching
- RRSIGs the configured trust anchors are immediately updated (and
- thereby the machine return to state IN-SYNC). I.e. the rollover
- machine changes states (mostly oscillating between IN-SYNC and
- OUT-OF-SYNC), but the status of the DNSSEC keys is stateless.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 13]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-4. Bootstrapping automatic rollovers
-
-
- It is expected that with the ability to automatically roll trust
- anchors at trust points will follow a diminished unwillingness to
- roll these keys, since the risks associated with stale keys are
- minimized.
-
-
- The problem of "priming" the trust anchors, or bringing them into
- sync (which could happen if a resolver is off line for a long period
- in which a set of SEP keys in a zone 'evolve' away from its trust
- anchor configuration) remains.
-
-
- For (re)priming we can rely on out of band technology and we propose
- the following framework.
-
-
-4.1 Priming Keys
-
-
- If all the trust anchors roll somewhat frequently (on the order of
- months or at most about a year) then it will not be possible to
- design a device, or a software distribution that includes trust
- anchors, that after being manufactured is put on a shelf for several
- key rollover periods before being brought into use (since no trust
- anchors that were known at the time of manufacture remain active).
-
-
- To alleviate this we propose the concept of "priming keys". Priming
- keys are ordinary DNSSEC Key Signing Keys with the characteristic
- that
- o The private part of a priming key signs the DNSKEY RRset at the
- security apex, i.e. at least one RRSIG DNSKEY is created by a
- priming key rather than by an "ordinary" trust anchor
- o the public parts of priming keys are not included in the DNSKEY
- RRset. Instead the public parts of priming keys are only
- available out-of-band.
- o The public parts of the priming keys have a validity period.
- Within this period they can be used to obtain trust anchors.
- o The priming key pairs are long lived (relative to the key rollover
- period.)
-
-
-4.1.1 Bootstrapping trust anchors using a priming key
-
-
- To install the trust anchors for a particular security apex an
- administrator of a validating resolver will need to:
- o query for the DNSKEY RRset of the zone at the security apex;
- o verify the self signatures of all DNSKEYs in the RRset;
- o verify the signature of the RRSIG made with a priming key --
- verification using one of the public priming keys that is valid at
- that moment is sufficient;
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 14]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- o create the trust anchors by extracting the DNSKEY RRs with the SEP
- flag set.
- The SEP keys with algorithms unknown to the validating resolver
- SHOULD be ignored during the creation of the trust anchors.
-
-
-4.1.2 Distribution of priming keys
-
-
- The public parts of the priming keys SHOULD be distributed
- exclusively through out-of-DNS mechanisms. The requirements for a
- distribution mechanism are:
- o it can carry the "validity" period for the priming keys;
- o it can carry the self-signature of the priming keys;
- o and it allows for verification using trust relations outside the
- DNS.
- A distribution mechanism would benefit from:
- o the availability of revocation lists;
- o the ability of carrying zone owners policy information such as
- recommended values for "M" and "N" and a rollover frequency;
- o and the technology on which is based is readily available.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 15]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-5. The Threshold Rollover Mechanism vs Priming
-
-
- There is overlap between the threshold-based trust updater and the
- Priming method. One could exclusively use the Priming method for
- maintaining the trust anchors. However the priming method probably
- relies on "non-DNS' technology and may therefore not be available for
- all devices that have a resolver.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 16]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-6. Security Considerations
-
-
-6.1 Threshold-based Trust Update Security Considerations
-
-
- A clear issue for resolvers will be how to ensure that they track all
- rollover events for the zones they have configure trust anchors for.
- Because of temporary outages validating resolvers may have missed a
- rollover of a KSK. The parameters that determine the robustness
- against failures are: the length of the period between rollovers
- during which the KSK set is stable and validating resolvers can
- actually notice the change; the number of available KSKs (i.e. N)
- and the number of signatures that may fail to validate (i.e. N-M).
-
-
- With a large N (i.e. many KSKs) and a small value of M this
- operation becomes more robust since losing one key, for whatever
- reason, will not be crucial. Unfortunately the choice for the number
- of KSKs is a local policy issue for the zone owner while the choice
- for the parameter M is a local policy issue for the resolver
- administrator.
-
-
- Higher values of M increase the resilience against attacks somewhat;
- more signatures need to verify for a rollover to be approved. On the
- other hand the number of rollover events that may pass unnoticed
- before the resolver reaches the UNSYNCABLE state goes down.
-
-
- The threshold-based trust update intentionally does not provide a
- revocation mechanism. In the case that a sufficient number of
- private keys of a zone owner are simultaneously compromised the the
- attacker may use these private keys to roll the trust anchors of (a
- subset of) the resolvers. This is obviously a bad situation but it
- is not different from most other public keys systems.
-
-
- However, it is important to point out that since any reasonable trust
- anchor rollover policy (in validating resolvers) will require more
- than one RRSIG to validate this proposal does provide security
- concious zone administrators with the option of not storing the
- individual private keys in the same location and thereby decreasing
- the likelihood of simultaneous compromise.
-
-
-6.2 Priming Key Security Considerations
-
-
- Since priming keys are not included in the DNSKEY RR set they are
- less sensitive to packet size constraints and can be chosen
- relatively large. The private parts are only needed to sign the
- DNSKEY RR set during the validity period of the particular priming
- key pair. Note that the private part of the priming key is used each
- time when a DNSKEY RRset has to be resigned. In practice there is
- therefore little difference between the usage pattern of the private
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 17]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- part of key signing keys and priming keys.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 18]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-7. IANA Considerations
-
-
- NONE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 19]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-8. References
-
-
-8.1 Normative References
-
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-
- [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
- (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
- RFC 3757, May 2004.
-
-
- [3] Arends, R., "Resource Records for the DNS Security Extensions",
- draft-ietf-dnsext-dnssec-records-10 (work in progress),
- September 2004.
-
-
-8.2 Informative References
-
-
- [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
- "DNS Security Introduction and Requirements",
- draft-ietf-dnsext-dnssec-intro-12 (work in progress), September
- 2004.
-
-
- [5] Kolkman, O., "DNSSEC Operational Practices",
- draft-ietf-dnsop-dnssec-operational-practices-01 (work in
- progress), May 2004.
-
-
- [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
- Public Key Infrastructure Certificate and CRL Profile", RFC
- 2459, January 1999.
-
-
-
-Authors' Addresses
-
-
- Johan Ihren
- Autonomica AB
- Bellmansgatan 30
- Stockholm SE-118 47
- Sweden
-
-
- EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 20]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
- 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/
-
-
-
- Bill Manning
- EP.net
- Marina del Rey, CA 90295
- USA
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 21]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-Appendix A. Acknowledgments
-
-
- The present design for in-band automatic rollovers of DNSSEC trust
- anchors is the result of many conversations and it is no longer
- possible to remember exactly who contributed what.
-
-
- In addition we've also had appreciated help from (in no particular
- order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
- Larson and Mark Kosters.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 22]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-Appendix B. Document History
-
-
- This appendix will be removed if and when the document is submitted
- to the RFC editor.
-
-
- The version you are reading is tagged as $Revision: 1.1 $.
-
-
- Text between square brackets, other than references, are editorial
- comments and will be removed.
-
-
-B.1 prior to version 00
-
-
- This draft was initially published as a personal submission under the
- name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.
-
-
- Kolkman documented the ideas provided by Ihren and Manning. In the
- process of documenting (and prototyping) Kolkman changed some of the
- details of the M-N algorithms working. Ihren did not have a chance
- to review the draft before Kolkman posted;
-
-
- Kolkman takes responsibilities for omissions, fuzzy definitions and
- mistakes.
-
-
-B.2 version 00
- o The name of the draft was changed as a result of the draft being
- adopted as a working group document.
- o A small section on the concept of stale trust anchors was added.
- o The different possible states are more clearly defined, including
- examples of transitions between states.
- o The terminology is changed throughout the document. The old term
- "M-N" is replaced by "threshold" (more or less). Also the
- interpretation of the constants M and N is significantly
- simplified to bring the usage more in line with "standard"
- threshold terminlogy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 23]
-Internet-Draft DNSSEC Threshold-based Trust Update October 2004
-
-
-
-Intellectual Property Statement
-
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights 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; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
-
- Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-
-Copyright Statement
-
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Ihren, et al. Expires April 18, 2005 [Page 24]
\ No newline at end of file
+++ /dev/null
-
-DNS Operations WG A. Durand
-Internet-Draft SUN Microsystems, Inc.
-Expires: April 24, 2005 J. Ihren
- Autonomica
- P. Savola
- CSC/FUNET
- October 24, 2004
-
-
-
- Operational Considerations and Issues with IPv6 DNS
- draft-ietf-dnsop-ipv6-dns-issues-10.txt
-
-
-Status of this Memo
-
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
-
- 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 April 24, 2005.
-
-
-Copyright Notice
-
-
- Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
- This memo presents operational considerations and issues with IPv6
- Domain Name System (DNS), including a summary of special IPv6
- addresses, documentation of known DNS implementation misbehaviour,
- recommendations and considerations on how to perform DNS naming for
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 1]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- service provisioning and for DNS resolver IPv6 support,
- considerations for DNS updates for both the forward and reverse
- trees, and miscellaneous issues. This memo is aimed to include a
- summary of information about IPv6 DNS considerations for those who
- have experience with IPv4 DNS.
-
-
-Table of Contents
-
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4
- 1.2 Independence of DNS Transport and DNS Records . . . . . . 4
- 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5
- 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5
- 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5
- 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6
- 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6
- 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6
- 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6
- 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7
- 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7
- 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7
- 4. Recommendations for Service Provisioning using DNS . . . . . . 8
- 4.1 Use of Service Names instead of Node Names . . . . . . . . 8
- 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8
- 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9
- 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10
- 4.4.1 Description of Additional Data Scenarios . . . . . . . 10
- 4.4.2 Which Additional Data to Keep, If Any? . . . . . . . . 11
- 4.4.3 Discussion of the Problems . . . . . . . . . . . . . . 12
- 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 13
- 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 14
- 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 15
- 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 15
- 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 16
- 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 17
- 6. Considerations about Forward DNS Updating . . . . . . . . . . 17
- 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17
- 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 18
- 7. Considerations about Reverse DNS Updating . . . . . . . . . . 19
- 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 19
- 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 20
- 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 20
- 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 21
- 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 22
- 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 23
- 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 23
- 8.2 Renumbering Procedures and Applications' Use of DNS . . . 23
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 2]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- 10. Security Considerations . . . . . . . . . . . . . . . . . . 24
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
- 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 24
- 11.2 Informative References . . . . . . . . . . . . . . . . . . . 26
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
- A. Site-local Addressing Considerations for DNS . . . . . . . . . 29
- Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 3]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-1. Introduction
-
-
- This memo presents operational considerations and issues with IPv6
- DNS; it is meant to be an extensive summary and a list of pointers
- for more information about IPv6 DNS considerations for those with
- experience with IPv4 DNS.
-
-
- The purpose of this document is to give information about various
- issues and considerations related to DNS operations with IPv6; it is
- not meant to be a normative specification or standard for IPv6 DNS.
-
-
- The first section gives a brief overview of how IPv6 addresses and
- names are represented in the DNS, how transport protocols and
- resource records (don't) relate, and what IPv4/IPv6 name space
- fragmentation means and how to avoid it; all of these are described
- at more length in other documents.
-
-
- The second section summarizes the special IPv6 address types and how
- they relate to DNS. The third section describes observed DNS
- implementation misbehaviours which have a varying effect on the use
- of IPv6 records with DNS. The fourth section lists recommendations
- and considerations for provisioning services with DNS. The fifth
- section in turn looks at recommendations and considerations about
- providing IPv6 support in the resolvers. The sixth and seventh
- sections describe considerations with forward and reverse DNS
- updates, respectively. The eighth section introduces several
- miscellaneous IPv6 issues relating to DNS for which no better place
- has been found in this memo. Appendix A looks briefly at the
- requirements for site-local addressing.
-
-
-1.1 Representing IPv6 Addresses in DNS Records
-
-
- In the forward zones, IPv6 addresses are represented using AAAA
- records. In the reverse zones, IPv6 address are represented using
- PTR records in the nibble format under the ip6.arpa. tree. See
- [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
- for background information.
-
-
- In particular one should note that the use of A6 records in the
- forward tree or Bitlabels in the reverse tree is not recommended
- [RFC3363]. Using DNAME records is not recommended in the reverse
- tree in conjunction with A6 records; the document did not mean to
- take a stance on any other use of DNAME records [RFC3364].
-
-
-1.2 Independence of DNS Transport and DNS Records
-
-
- DNS has been designed to present a single, globally unique name space
- [RFC2826]. This property should be maintained, as described here and
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 4]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- in Section 1.3.
-
-
- The IP version used to transport the DNS queries and responses is
- independent of the records being queried: AAAA records can be queried
- over IPv4, and A records over IPv6. The DNS servers must not make
- any assumptions about what data to return for Answer and Authority
- sections based on the underlying transport used in a query.
-
-
- However, there is some debate whether the addresses in Additional
- section could be selected or filtered using hints obtained from which
- transport was being used; this has some obvious problems because in
- many cases the transport protocol does not correlate with the
- requests, and because a "bad" answer is in a way worse than no answer
- at all (consider the case where the client is led to believe that a
- name received in the additional record does not have any AAAA records
- at all).
-
-
- As stated in [RFC3596]:
-
-
- The IP protocol version used for querying resource records is
- independent of the protocol version of the resource records; e.g.,
- IPv4 transport can be used to query IPv6 records and vice versa.
-
-
-
-1.3 Avoiding IPv4/IPv6 Name Space Fragmentation
-
-
- To avoid the DNS name space from fragmenting into parts where some
- parts of DNS are only visible using IPv4 (or IPv6) transport, the
- recommendation is to always keep at least one authoritative server
- IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
- See DNS IPv6 transport guidelines [RFC3901] for more information.
-
-
-1.4 Query Type '*' and A/AAAA Records
-
-
- QTYPE=* is typically only used for debugging or management purposes;
- it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
- any available RRsets, not *all* the RRsets, because the caches do not
- necessarily have all the RRsets and have no way of guaranteeing that
- they have all the RRsets. Therefore, to get both A and AAAA records
- reliably, two separate queries must be made.
-
-
-2. DNS Considerations about Special IPv6 Addresses
-
-
- There are a couple of IPv6 address types which are somewhat special;
- these are considered here.
-
-
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 5]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-2.1 Limited-scope Addresses
-
-
- The IPv6 addressing architecture [RFC3513] includes two kinds of
- local-use addresses: link-local (fe80::/10) and site-local
- (fec0::/10). The site-local addresses have been deprecated
- [RFC3879], and are only discussed in Appendix A.
-
-
- Link-local addresses should never be published in DNS (whether in
- forward or reverse tree), because they have only local (to the
- connected link) significance
- [I-D.ietf-dnsop-dontpublish-unreachable].
-
-
-2.2 Temporary Addresses
-
-
- Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
- "privacy addresses") use a random number as the interface identifier.
- Having DNS AAAA records that are updated to always contain the
- current value of a node's temporary address would defeat the purpose
- of the mechanism and is not recommended. However, it would still be
- possible to return a non-identifiable name (e.g., the IPv6 address in
- hexadecimal format), as described in [RFC3041].
-
-
-2.3 6to4 Addresses
-
-
- 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
- a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
-
-
- If the reverse DNS population would be desirable (see Section 7.1 for
- applicability), there are a number of possible ways to do so
- [I-D.moore-6to4-dns], some more applicable than the others.
-
-
- The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
- autonomous reverse-delegation system that anyone being capable of
- communicating using a specific 6to4 address would be able to set up a
- reverse delegation to the corresponding 6to4 prefix. This could be
- deployed by e.g., Regional Internet Registries (RIRs). This is a
- practical solution, but may have some scalability concerns.
-
-
-2.4 Other Transition Mechanisms
-
-
- 6to4, above, is mentioned as a case of an IPv6 transition mechanism
- requiring special considerations. In general, mechanisms which
- include a special prefix may need a custom solution; otherwise, for
- example when IPv4 address is embedded as the suffix or not embedded
- at all, special solutions are likely not needed. This is why only
- 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.
-
-
- Note that it does not seem feasible to provide reverse DNS with
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 6]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- another automatic tunneling mechanism, Teredo; this is because the
- IPv6 address is based on the IPv4 address and UDP port of the current
- NAT mapping which is likely to be relatively short-lived.
-
-
-3. Observed DNS Implementation Misbehaviour
-
-
- Several classes of misbehaviour in DNS servers, load-balancers and
- resolvers have been observed. Most of these are rather generic, not
- only applicable to IPv6 -- but in some cases, the consequences of
- this misbehaviour are extremely severe in IPv6 environments and
- deserve to be mentioned.
-
-
-3.1 Misbehaviour of DNS Servers and Load-balancers
-
-
- There are several classes of misbehaviour in certain DNS servers and
- load-balancers which have been noticed and documented
- [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations
- silently drop queries for unimplemented DNS records types, or provide
- wrong answers to such queries (instead of a proper negative reply).
- While typically these issues are not limited to AAAA records, the
- problems are aggravated by the fact that AAAA records are being
- queried instead of (mainly) A records.
-
-
- The problems are serious because when looking up a DNS name, typical
- getaddrinfo() implementations, with AF_UNSPEC hint given, first try
- to query the AAAA records of the name, and after receiving a
- response, query the A records. This is done in a serial fashion --
- if the first query is never responded to (instead of properly
- returning a negative answer), significant timeouts will occur.
-
-
- In consequence, this is an enormous problem for IPv6 deployments, and
- in some cases, IPv6 support in the software has even been disabled
- due to these problems.
-
-
- The solution is to fix or retire those misbehaving implementations,
- but that is likely not going to be effective. There are some
- possible ways to mitigate the problem, e.g., by performing the
- lookups somewhat in parallel and reducing the timeout as long as at
- least one answer has been received; but such methods remain to be
- investigated; slightly more on this is included in Section 5.
-
-
-3.2 Misbehaviour of DNS Resolvers
-
-
- Several classes of misbehaviour have also been noticed in DNS
- resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem
- to directly impair IPv6 use, and are only referred to for
- completeness.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 7]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-4. Recommendations for Service Provisioning using DNS
-
-
- When names are added in the DNS to facilitate a service, there are
- several general guidelines to consider to be able to do it as
- smoothly as possible.
-
-
-4.1 Use of Service Names instead of Node Names
-
-
- It makes sense to keep logically separate services by a node separate
- in the DNS, due to a number of reasons, for example:
-
-
- o It allows more flexibility and ease for migration of (only a part
- of) services from one node to another,
-
-
- o It allows configuring different properties (e.g., TTL) for each
- service, and
-
-
- o It allows deciding separately for each service whether to publish
- the IPv6 addresses or not (in cases if some services are more
- IPv6-ready than others).
-
-
- Using SRV records [RFC2782] would avoid these problems.
- Unfortunately, those are not sufficiently widely used to be
- applicable in most cases. Hence an operation technique is to use
- service names instead of node names (or, "hostnames"). This
- operational technique is not specific to IPv6, but required to
- understand the considerations described in Section 4.2 and Section
- 4.3.
-
-
- For example, assume a node named "pobox.example.com" provides both
- SMTP and IMAP service. Instead of configuring the MX records to
- point at "pobox.example.com", and configuring the mail clients to
- look up the mail via IMAP from "pobox.example.com", one could use
- e.g., "smtp.example.com" for SMTP (for both message submission and
- mail relaying between SMTP servers) and "imap.example.com" for IMAP.
- Note that in the specific case of SMTP relaying, the server itself
- must typically also be configured to know all its names to ensure
- loops do not occur. DNS can provide a layer of indirection between
- service names and where the service actually is, and using which
- addresses. (Obviously, when wanting to reach a specific node, one
- should use the hostname rather than a service name.)
-
-
-4.2 Separate vs the Same Service Names for IPv4 and IPv6
-
-
- The service naming can be achieved in basically two ways: when a
- service is named "service.example.com" for IPv4, the IPv6-enabled
- service could be either added to "service.example.com", or added
- separately under a different name, e.g., in a sub-domain, like,
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 8]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- "service.ipv6.example.com".
-
-
- These two methods have different characteristics. Using a different
- name allows for easier service piloting, minimizing the disturbance
- to the "regular" users of IPv4 service; however, the service would
- not be used transparently, without the user/application explicitly
- finding it and asking for it -- which would be a disadvantage in most
- cases. When the different name is under a sub-domain, if the
- services are deployed within a restricted network (e.g., inside an
- enterprise), it's possible to prefer them transparently, at least to
- a degree, by modifying the DNS search path; however, this is a
- suboptimal solution. Using the same service name is the "long-term"
- solution, but may degrade performance for those clients whose IPv6
- performance is lower than IPv4, or does not work as well (see Section
- 4.3 for more).
-
-
- In most cases, it makes sense to pilot or test a service using
- separate service names, and move to the use of the same name when
- confident enough that the service level will not degrade for the
- users unaware of IPv6.
-
-
-4.3 Adding the Records Only when Fully IPv6-enabled
-
-
- The recommendation is that AAAA records for a service should not be
- added to the DNS until all of following are true:
-
-
- 1. The address is assigned to the interface on the node.
-
-
- 2. The address is configured on the interface.
-
-
- 3. The interface is on a link which is connected to the IPv6
- infrastructure.
-
-
- In addition, if the AAAA record is added for the node, instead of
- service as recommended, all the services of the node should be
- IPv6-enabled prior to adding the resource record.
-
-
- For example, if an IPv6 node is isolated from an IPv6 perspective
- (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
- that it should not have an address in the DNS.
-
-
- Consider the case of two dual-stack nodes, which both have IPv6
- enabled, but the server does not have (global) IPv6 connectivity. As
- the client looks up the server's name, only A records are returned
- (if the recommendations above are followed), and no IPv6
- communication, which would have been unsuccessful, is even attempted.
-
-
- The issues are not always so black-and-white. Usually it's important
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 9]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- if the service offered using both protocols is of roughly equal
- quality, using the appropriate metrics for the service (e.g.,
- latency, throughput, low packet loss, general reliability, etc.) --
- this is typically very important especially for interactive or
- real-time services. In many cases, the quality of IPv6 connectivity
- may not yet be equal to that of IPv4, at least globally -- this has
- to be taken into consideration when enabling services
- [I-D.savola-v6ops-6bone-mess].
-
-
-4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
-
-
- DNS responses do not always fit in a single UDP packet. We'll
- examine the cases which happen when this is due to too much data in
- the Additional Section.
-
-
-4.4.1 Description of Additional Data Scenarios
-
-
- There are two kinds of additional data:
-
-
- 1. "critical" additional data; this must be included in all
- scenarios, with all the RRsets, and
-
-
- 2. "courtesy" additional data; this could be sent in full, with only
- a few RRsets, or with no RRsets, and can be fetched separately as
- well, but at the cost of additional queries.
-
-
- The responding server can algorithmically determine which type the
- additional data is by checking whether it's at or below a zone cut.
-
-
- Only those additional data records (even if sometimes carelessly
- termed "glue") are considered "critical" or real "glue" if and only
- if they meet the abovementioned condition, as specified in Section
- 4.2.1 of [RFC1034].
-
-
- Remember that resource record sets (RRsets) are never "broken up", so
- if a name has 4 A records and 5 AAAA records, you can either return
- all 9, all 4 A records, all 5 AAAA records or nothing. In
- particular, notice that for the "critical" additional data getting
- all the RRsets can be critical.
-
-
- In particular, [RFC2181] specifies (in Section 9) that:
-
-
- a. if all the "critical" RRsets do not fit, the sender should set
- the TC bit, and the recipient should discard the whole response
- and retry using mechanism allowing larger responses such as TCP.
-
-
- b. "courtesy" additional data should not cause the setting of TC
- bit, but instead all the non-fitting additional data RRsets
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 10]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- should be removed.
-
-
- An example of the "courtesy" additional data is A/AAAA records in
- conjunction of MX records is shown in Section 4.5; an example of the
- "critical" additional data is shown below (where getting both the A
- and AAAA RRsets is critical):
-
-
- child.example.com. IN NS ns.child.example.com.
- ns.child.example.com. IN A 192.0.2.1
- ns.child.example.com. IN AAAA 2001:db8::1
-
-
- When there is too much courtesy additional data, at least the
- non-fitting RRsets should be removed [RFC2181]; however, as the
- additional data is not critical, even all of it could be safely
- removed.
-
-
- When there is too much critical additional data, TC bit will have to
- be set, and the recipient should ignore the response and retry using
- TCP; if some data were to be left in the UDP response, the issue is
- which data could be retained.
-
-
- Failing to discard the response with TC bit set leads to a protocol
- problem. Omitting only some of the RRsets if all would not fit leads
- to a performance problem. These are discussed in Section 4.4.3.
-
-
-4.4.2 Which Additional Data to Keep, If Any?
-
-
- If the implementation decides to keep as much data (whether
- "critical" or "courtesy") as possible in the UDP responses, it might
- be tempting to use the transport of the DNS query as a hint in either
- of these cases: return the AAAA records if the query was done over
- IPv6, or return the A records if the query was done over IPv4.
- However, this breaks the model of independence of DNS transport and
- resource records, as noted in Section 1.2.
-
-
- With courtesy additional data, as long as enough RRsets will be
- removed so that TC will not be set, it is allowed to send as many
- complete RRsets as the implementations prefers. However, the
- implementations are also free to omit all such RRsets, even if
- complete. Removing all the RRsets if some would not fit obviates a
- performance problem, which would require the users to issue second
- queries to obtain consistent information.
-
-
- With critical additional data, the alternatives are either returning
- nothing (and absolutely requiring a retry with TCP) or returning
- something (working also in the case if the recipient does not discard
- the response and retry using TCP) in addition to setting the TC bit.
- If the process for selecting "something" from the critical data would
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 11]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- otherwise be practically "flipping the coin" between A and AAAA
- records, it could be argued that if one looked at the transport of
- the query, it would have a larger possibility of being right than
- just 50/50. In other words, if the returned critical additional data
- would have to be selected somehow, using something more sophisticated
- than a random process would seem justifiable.
-
-
- That is, leaving in some intelligently selected critical additional
- data is a tradeoff between creating an optimization for those
- resolvers which ignore the "should discard" recommendation, and a
- causing a protocol problem by propagating inconsistent information
- about "critical" records in the caches.
-
-
- Similarly, leaving in the complete courtesy additional data RRsets
- instead of removing all the RRsets is a performance tradeoff as
- described in the next section.
-
-
-4.4.3 Discussion of the Problems
-
-
- As noted above, the temptation for omitting only some of the
- additional data based on the transport of the query could be
- problematic. In particular, there appears to be little justification
- for doing so in the case of "courtesy" data.
-
-
- For courtesy additional data, this causes a performance problem as
- this requires that the clients issue re-query for the potentially
- omitted RRsets. For critical additional data, this causes a
- potential protocol problem if the response is not discarded and the
- query not re-tried with TCP, as the nameservers might be reachable
- only through the omitted RRsets.
-
-
- If an implementation would look at the transport used for the query,
- it is worth remembering that often the host using the records is
- different from the node requesting them from the authoritative DNS
- server (or even a caching resolver). So, whichever version the
- requestor (e.g., a recursive server in the middle) uses makes no
- difference to the ultimate user of the records, whose transport
- capabilities might differ from those of the requestor. This might
- result in e.g., inappropriately returning A records to an IPv6-only
- node, going through a translation, or opening up another IP-level
- session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
- Therefore, at least in many scenarios, it would be very useful if the
- information returned would be consistent and complete -- or if that
- is not feasible, return no misleading information but rather leave it
- to the client to query again.
-
-
- The problem of too much additional data seems to be an operational
- one: the zone administrator entering too many records which will be
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 12]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- returned either truncated (or missing some RRsets, depending on
- implementations) to the users. A protocol fix for this is using
- EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
- pushing up the relevant threshold. Further, DNS server
- implementations should rather omit courtesy additional data
- completely rather than including only some RRsets [RFC2181]. An
- operational fix for this is having the DNS server implementations
- return a warning when the administrators create zones which would
- result in too much additional data being returned. Further, DNS
- server implementations should warn of or disallow such zone
- configurations which are recursive or otherwise difficult to manage
- by the protocol.
-
-
- Additionally, to avoid the case where an application would not get an
- address at all due to some of "courtesy" additional data being
- omitted, the resolvers should be able to query the specific records
- of the desired protocol, not just rely on getting all the required
- RRsets in the additional section.
-
-
-4.5 The Use of TTL for IPv4 and IPv6 RRs
-
-
- In the previous section, we discussed a danger with queries,
- potentially leading to omitting RRsets from the additional section;
- this could happen to both critical and "courtesy" additional data
- (however, both of these are recommended against in [RFC2181]). This
- section discusses another problem with courtesy additional data,
- leading to omitting RRsets in cached data, highlighted in the
- IPv4/IPv6 environment.
-
-
- The behaviour of DNS caching when different TTL values are used for
- different RRsets of the same name requires explicit discussion. For
- example, let's consider a part of a zone:
-
-
- example.com. 300 IN MX foo.example.com.
- foo.example.com. 300 IN A 192.0.2.1
- foo.example.com. 100 IN AAAA 2001:db8::1
-
-
- When a caching resolver asks for the MX record of example.com, it
- gets back "foo.example.com". It may also get back either one or both
- of the A and AAAA records in the additional section. So, there are
- three cases about returning records for the MX in the additional
- section:
-
-
- 1. We get back no A or AAAA RRsets: this is the simplest case,
- because then we have to query which information is required
- explicitly, guaranteeing that we get all the information we're
- interested in.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 13]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- 2. We get back all the RRsets: this is an optimization as there is
- no need to perform more queries, causing lower latency. However,
- it is impossible to guarantee that in fact we would always get
- back all the records (the only way to ensure that is to send a
- AAAA query for the name after getting the cached reply with A
- records or vice versa).
-
-
- 3. We only get back A or AAAA RRsets even if both existed: this is
- indistinguishable from the previous case, and may have
- performance problems at least in certain environments as
- described in the previous section.
-
-
- As the third case was considered in the previous section, we assume
- we get back both A and AAAA records of foo.example.com, or the stub
- resolver explicitly asks, in two separate queries, both A and AAAA
- records.
-
-
- After 100 seconds, the AAAA record is removed from the cache(s)
- because its TTL expired. It could be argued to be useful for the
- caching resolvers to discard the A record when the shorter TTL (in
- this case, for the AAAA record) expires; this would avoid the
- situation where there would be a window of 200 seconds when
- incomplete information is returned from the cache. Further argument
- for discarding is that in the normal operation, the TTL values are so
- high that very likely the incurred additional queries would not be
- noticeable, compared to the obtained performance optimization. The
- behaviour in this scenario is unspecified.
-
-
- To simplify the situation, it might help to use the same TTL for all
- the resource record sets referring to the same name, unless there is
- a particular reason for not doing so. However, there are some
- scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
- a different strategy is preferable.
-
-
- Thus, applications that use the response should not rely on a
- particular TTL configuration. For example, even if an application
- gets a response that only has the A record in the example described
- above, it should be still aware that there could be a AAAA record for
- "foo.example.com". That is, the application should try to fetch the
- missing records itself if it needs the record.
-
-
-4.6 IPv6 Transport Guidelines for DNS Servers
-
-
- As described in Section 1.3 and [RFC3901], there should continue to
- be at least one authoritative IPv4 DNS server for every zone, even if
- the zone has only IPv6 records. (Note that obviously, having more
- servers with robust connectivity would be preferable, but this is the
- minimum recommendation; also see [RFC2182].)
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 14]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-5. Recommendations for DNS Resolver IPv6 Support
-
-
- When IPv6 is enabled on a node, there are several things to consider
- to ensure that the process is as smooth as possible.
-
-
-5.1 DNS Lookups May Query IPv6 Records Prematurely
-
-
- The system library that implements the getaddrinfo() function for
- looking up names is a critical piece when considering the robustness
- of enabling IPv6; it may come in basically three flavours:
-
-
- 1. The system library does not know whether IPv6 has been enabled in
- the kernel of the operating system: it may start looking up AAAA
- records with getaddrinfo() and AF_UNSPEC hint when the system is
- upgraded to a system library version which supports IPv6.
-
-
- 2. The system library might start to perform IPv6 queries with
- getaddrinfo() only when IPv6 has been enabled in the kernel.
- However, this does not guarantee that there exists any useful
- IPv6 connectivity (e.g., the node could be isolated from the
- other IPv6 networks, only having link-local addresses).
-
-
- 3. The system library might implement a toggle which would apply
- some heuristics to the "IPv6-readiness" of the node before
- starting to perform queries; for example, it could check whether
- only link-local IPv6 address(es) exists, or if at least one
- global IPv6 address exists.
-
-
- First, let us consider generic implications of unnecessary queries
- for AAAA records: when looking up all the records in the DNS, AAAA
- records are typically tried first, and then A records. These are
- done in serial, and the A query is not performed until a response is
- received to the AAAA query. Considering the misbehaviour of DNS
- servers and load-balancers, as described in Section 3.1, the look-up
- delay for AAAA may incur additional unnecessary latency, and
- introduce a component of unreliability.
-
-
- One option here could be to do the queries partially in parallel; for
- example, if the final response to the AAAA query is not received in
- 0.5 seconds, start performing the A query while waiting for the
- result (immediate parallelism might be unoptimal, at least without
- information sharing between the look-up threads, as that would
- probably lead to duplicate non-cached delegation chain lookups).
-
-
- An additional concern is the address selection, which may, in some
- circumstances, prefer AAAA records over A records even when the node
- does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
- In some cases, the implementation may attempt to connect or send a
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 15]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
- incurring very long protocol timeouts, instead of quickly failing
- back to IPv4.
-
-
- Now, we can consider the issues specific to each of the three
- possibilities:
-
-
- In the first case, the node performs a number of completely useless
- DNS lookups as it will not be able to use the returned AAAA records
- anyway. (The only exception is where the application desires to know
- what's in the DNS, but not use the result for communication.) One
- should be able to disable these unnecessary queries, for both latency
- and reliability reasons. However, as IPv6 has not been enabled, the
- connections to IPv6 addresses fail immediately, and if the
- application is programmed properly, the application can fall
- gracefully back to IPv4 [I-D.ietf-v6ops-application-transition].
-
-
- The second case is similar to the first, except it happens to a
- smaller set of nodes when IPv6 has been enabled but connectivity has
- not been provided yet; similar considerations apply, with the
- exception that IPv6 records, when returned, will be actually tried
- first which may typically lead to long timeouts.
-
-
- The third case is a bit more complex: optimizing away the DNS lookups
- with only link-locals is probably safe (but may be desirable with
- different lookup services which getaddrinfo() may support), as the
- link-locals are typically automatically generated when IPv6 is
- enabled, and do not indicate any form of IPv6 connectivity. That is,
- performing DNS lookups only when a non-link-local address has been
- configured on any interface could be beneficial -- this would be an
- indication that either the address has been configured either from a
- router advertisement, DHCPv6 [RFC3315], or manually. Each would
- indicate at least some form of IPv6 connectivity, even though there
- would not be guarantees of it.
-
-
- These issues should be analyzed at more depth, and the fixes found
- consensus on, perhaps in a separate document.
-
-
-5.2 Obtaining a List of DNS Recursive Resolvers
-
-
- In scenarios where DHCPv6 is available, a host can discover a list of
- DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
- option [RFC3646]. This option can be passed to a host through a
- subset of DHCPv6 [RFC3736].
-
-
- The IETF is considering the development of alternative mechanisms for
- obtaining the list of DNS recursive name servers when DHCPv6 is
- unavailable or inappropriate. No decision about taking on this
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 16]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- development work has been reached as of this writing (Aug 2004)
- [I-D.ietf-dnsop-ipv6-dns-configuration].
-
-
- In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
- under consideration for development include the use of well-known
- addresses [I-D.ohta-preconfigured-dns] and the use of Router
- Advertisements to convey the information
- [I-D.jeong-dnsop-ipv6-dns-discovery].
-
-
- Note that even though IPv6 DNS resolver discovery is a recommended
- procedure, it is not required for dual-stack nodes in dual-stack
- networks as IPv6 DNS records can be queried over IPv4 as well as
- IPv6. Obviously, nodes which are meant to function without manual
- configuration in IPv6-only networks must implement the DNS resolver
- discovery function.
-
-
-5.3 IPv6 Transport Guidelines for Resolvers
-
-
- As described in Section 1.3 and [RFC3901], the recursive resolvers
- should be IPv4-only or dual-stack to be able to reach any IPv4-only
- DNS server. Note that this requirement is also fulfilled by an
- IPv6-only stub resolver pointing to a dual-stack recursive DNS
- resolver.
-
-
-6. Considerations about Forward DNS Updating
-
-
- While the topic how to enable updating the forward DNS, i.e., the
- mapping from names to the correct new addresses, is not specific to
- IPv6, it should be considered especially due to the advent of
- Stateless Address Autoconfiguration [RFC2462].
-
-
- Typically forward DNS updates are more manageable than doing them in
- the reverse DNS, because the updater can often be assumed to "own" a
- certain DNS name -- and we can create a form of security relationship
- with the DNS name and the node which is allowed to update it to point
- to a new address.
-
-
- A more complex form of DNS updates -- adding a whole new name into a
- DNS zone, instead of updating an existing name -- is considered out
- of scope for this memo as it could require zone-wide authentication.
- Adding a new name in the forward zone is a problem which is still
- being explored with IPv4, and IPv6 does not seem to add much new in
- that area.
-
-
-6.1 Manual or Custom DNS Updates
-
-
- The DNS mappings can also be maintained by hand, in a semi-automatic
- fashion or by running non-standardized protocols. These are not
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 17]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- considered at more length in this memo.
-
-
-6.2 Dynamic DNS
-
-
- Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized
- mechanism for dynamically updating the DNS. It works equally well
- with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
- address configuration. It is important to consider how each of these
- behave if IP address-based authentication, instead of stronger
- mechanisms [RFC3007], was used in the updates.
-
-
- 1. manual addresses are static and can be configured
-
-
- 2. DHCPv6 addresses could be reasonably static or dynamic, depending
- on the deployment, and could or could not be configured on the
- DNS server for the long term
-
-
- 3. SLAAC addresses are typically stable for a long time, but could
- require work to be configured and maintained.
-
-
- As relying on IP addresses for Dynamic DNS is rather insecure at
- best, stronger authentication should always be used; however, this
- requires that the authorization keying will be explicitly configured
- using unspecified operational methods.
-
-
- Note that with DHCP it is also possible that the DHCP server updates
- the DNS, not the host. The host might only indicate in the DHCP
- exchange which hostname it would prefer, and the DHCP server would
- make the appropriate updates. Nonetheless, while this makes setting
- up a secure channel between the updater and the DNS server easier, it
- does not help much with "content" security, i.e., whether the
- hostname was acceptable -- if the DNS server does not include
- policies, they must be included in the DHCP server (e.g., a regular
- host should not be able to state that its name is "www.example.com").
- DHCP-initiated DDNS updates have been extensively described in
- [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
- [I-D.ietf-dnsext-dhcid-rr].
-
-
- The nodes must somehow be configured with the information about the
- servers where they will attempt to update their addresses, sufficient
- security material for authenticating themselves to the server, and
- the hostname they will be updating. Unless otherwise configured, the
- first could be obtained by looking up the authoritative name servers
- for the hostname; the second must be configured explicitly unless one
- chooses to trust the IP address-based authentication (not a good
- idea); and lastly, the nodename is typically pre-configured somehow
- on the node, e.g., at install time.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 18]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- Care should be observed when updating the addresses not to use longer
- TTLs for addresses than are preferred lifetimes for the addresses, so
- that if the node is renumbered in a managed fashion, the amount of
- stale DNS information is kept to the minimum. That is, if the
- preferred lifetime of an address expires, the TTL of the record needs
- be modified unless it was already done before the expiration. For
- better flexibility, the DNS TTL should be much shorter (e.g., a half
- or a third) than the lifetime of an address; that way, the node can
- start lowering the DNS TTL if it seems like the address has not been
- renewed/refreshed in a while. Some discussion on how an
- administrator could manage the DNS TTL is included in
- [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to
- (smart) hosts as well.
-
-
-7. Considerations about Reverse DNS Updating
-
-
- Updating the reverse DNS zone may be difficult because of the split
- authority over an address. However, first we have to consider the
- applicability of reverse DNS in the first place.
-
-
-7.1 Applicability of Reverse DNS
-
-
- Today, some applications use reverse DNS to either look up some hints
- about the topological information associated with an address (e.g.
- resolving web server access logs), or as a weak form of a security
- check, to get a feel whether the user's network administrator has
- "authorized" the use of the address (on the premises that adding a
- reverse record for an address would signal some form of
- authorization).
-
-
- One additional, maybe slightly more useful usage is ensuring that the
- reverse and forward DNS contents match (by looking up the pointer to
- the name by the IP address from the reverse tree, and ensuring that a
- record under the name in the forward tree points to the IP address)
- and correspond to a configured name or domain. As a security check,
- it is typically accompanied by other mechanisms, such as a
- user/password login; the main purpose of the reverse+forward DNS
- check is to weed out the majority of unauthorized users, and if
- someone managed to bypass the checks, he would still need to
- authenticate "properly".
-
-
- It may also be desirable to store IPsec keying material corresponding
- to an IP address to the reverse DNS, as justified and described in
- [I-D.ietf-ipseckey-rr].
-
-
- It is not clear whether it makes sense to require or recommend that
- reverse DNS records be updated. In many cases, it would just make
- more sense to use proper mechanisms for security (or topological
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 19]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- information lookup) in the first place. At minimum, the applications
- which use it as a generic authorization (in the sense that a record
- exists at all) should be modified as soon as possible to avoid such
- lookups completely.
-
-
- The applicability is discussed at more length in
- [I-D.ietf-dnsop-inaddr-required].
-
-
-7.2 Manual or Custom DNS Updates
-
-
- Reverse DNS can of course be updated using manual or custom methods.
- These are not further described here, except for one special case.
-
-
- One way to deploy reverse DNS would be to use wildcard records, for
- example, by configuring one name for a subnet (/64) or a site (/48).
- As a concrete example, a site (or the site's ISP) could configure the
- reverses of the prefix 2001:db8:f00::/48 to point to one name using a
- wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
- site.example.com." Naturally, such a name could not be verified from
- the forward DNS, but would at least provide some form of "topological
- information" or "weak authorization" if that is really considered to
- be useful. Note that this is not actually updating the DNS as such,
- as the whole point is to avoid DNS updates completely by manually
- configuring a generic name.
-
-
-7.3 DDNS with Stateless Address Autoconfiguration
-
-
- Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
- some regard, while being more difficult in another, as described
- below.
-
-
- The address space administrator decides whether the hosts are trusted
- to update their reverse DNS records or not. If they are trusted and
- deployed at the same site (e.g., not across the Internet), a simple
- address-based authorization is typically sufficient (i.e., check that
- the DNS update is done from the same IP address as the record being
- updated); stronger security can also be used [RFC3007]. If they
- aren't allowed to update the reverses, no update can occur. However,
- such address-based update authorization operationally requires that
- ingress filtering [RFC3704] has been set up at the border of the site
- where the updates occur, and as close to the updater as possible.
-
-
- Address-based authorization is simpler with reverse DNS (as there is
- a connection between the record and the address) than with forward
- DNS. However, when a stronger form of security is used, forward DNS
- updates are simpler to manage because the host can be assumed to have
- an association with the domain. Note that the user may roam to
- different networks, and does not necessarily have any association
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 20]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- with the owner of that address space -- so, assuming stronger form of
- authorization for reverse DNS updates than an address association is
- generally unfeasible.
-
-
- Moreover, the reverse zones must be cleaned up by an unspecified
- janitorial process: the node does not typically know a priori that it
- will be disconnected, and cannot send a DNS update using the correct
- source address to remove a record.
-
-
- A problem with defining the clean-up process is that it is difficult
- to ensure that a specific IP address and the corresponding record are
- no longer being used. Considering the huge address space, and the
- unlikelihood of collision within 64 bits of the interface
- identifiers, a process which would remove the record after no traffic
- has been seen from a node in a long period of time (e.g., a month or
- year) might be one possible approach.
-
-
- To insert or update the record, the node must discover the DNS server
- to send the update to somehow, similar to as discussed in Section
- 6.2. One way to automate this is looking up the DNS server
- authoritative (e.g., through SOA record) for the IP address being
- updated, but the security material (unless the IP address-based
- authorization is trusted) must also be established by some other
- means.
-
-
- One should note that Cryptographically Generated Addresses
- [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of
- treatment. CGAs are addresses where the interface identifier is
- calculated from a public key, a modifier (used as a nonce), the
- subnet prefix, and other data. Depending on the usage profile, CGAs
- might or might not be changed periodically due to e.g., privacy
- reasons. As the CGA address is not predicatable, a reverse record
- can only reasonably be inserted in the DNS by the node which
- generates the address.
-
-
-7.4 DDNS with DHCP
-
-
- With DHCPv4, the reverse DNS name is typically already inserted to
- the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One
- can assume similar practice may become commonplace with DHCPv6 as
- well; all such mappings would be pre-configured, and would require no
- updating.
-
-
- If a more explicit control is required, similar considerations as
- with SLAAC apply, except for the fact that typically one must update
- a reverse DNS record instead of inserting one (if an address
- assignment policy that reassigns disused addresses is adopted) and
- updating a record seems like a slightly more difficult thing to
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 21]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- secure. However, it is yet uncertain how DHCPv6 is going to be used
- for address assignment.
-
-
- Note that when using DHCP, either the host or the DHCP server could
- perform the DNS updates; see the implications in Section 6.2.
-
-
- If disused addresses were to be reassigned, host-based DDNS reverse
- updates would need policy considerations for DNS record modification,
- as noted above. On the other hand, if disused address were not to be
- assigned, host-based DNS reverse updates would have similar
- considerations as SLAAC in Section 7.3. Server-based updates have
- similar properties except that the janitorial process could be
- integrated with DHCP address assignment.
-
-
-7.5 DDNS with Dynamic Prefix Delegation
-
-
- In cases where a prefix, instead of an address, is being used and
- updated, one should consider what is the location of the server where
- DDNS updates are made. That is, where the DNS server is located:
-
-
- 1. At the same organization as the prefix delegator.
-
-
- 2. At the site where the prefixes are delegated to. In this case,
- the authority of the DNS reverse zone corresponding to the
- delegated prefix is also delegated to the site.
-
-
- 3. Elsewhere; this implies a relationship between the site and where
- DNS server is located, and such a relationship should be rather
- straightforward to secure as well. Like in the previous case,
- the authority of the DNS reverse zone is also delegated.
-
-
- In the first case, managing the reverse DNS (delegation) is simpler
- as the DNS server and the prefix delegator are in the same
- administrative domain (as there is no need to delegate anything at
- all); alternatively, the prefix delegator might forgo DDNS reverse
- capability altogether, and use e.g., wildcard records (as described
- in Section 7.2). In the other cases, it can be slighly more
- difficult, particularly as the site will have to configure the DNS
- server to be authoritative for the delegated reverse zone, implying
- automatic configuration of the DNS server -- as the prefix may be
- dynamic.
-
-
- Managing the DDNS reverse updates is typically simple in the second
- case, as the updated server is located at the local site, and
- arguably IP address-based authentication could be sufficient (or if
- not, setting up security relationships would be simpler). As there
- is an explicit (security) relationship between the parties in the
- third case, setting up the security relationships to allow reverse
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 22]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- DDNS updates should be rather straightforward as well (but IP
- address-based authentication might not be acceptable). In the first
- case, however, setting up and managing such relationships might be a
- lot more difficult.
-
-
-8. Miscellaneous DNS Considerations
-
-
- This section describes miscellaneous considerations about DNS which
- seem related to IPv6, for which no better place has been found in
- this document.
-
-
-8.1 NAT-PT with DNS-ALG
-
-
- The DNS-ALG component of NAT-PT mangles A records to look like AAAA
- records to the IPv6-only nodes. Numerous problems have been
- identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues].
- This is a strong reason not to use NAT-PT in the first place.
-
-
-8.2 Renumbering Procedures and Applications' Use of DNS
-
-
- One of the most difficult problems of systematic IP address
- renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
- an application which looks up a DNS name disregards information such
- as TTL, and uses the result obtained from DNS as long as it happens
- to be stored in the memory of the application. For applications
- which run for a long time, this could be days, weeks or even months;
- some applications may be clever enough to organize the data
- structures and functions in such a manner that look-ups get refreshed
- now and then.
-
-
- While the issue appears to have a clear solution, "fix the
- applications", practically this is not reasonable immediate advice;
- the TTL information is not typically available in the APIs and
- libraries (so, the advice becomes "fix the applications, APIs and
- libraries"), and a lot more analysis is needed on how to practically
- go about to achieve the ultimate goal of avoiding using the names
- longer than expected.
-
-
-9. Acknowledgements
-
-
- Some recommendations (Section 4.3, Section 5.1) about IPv6 service
- provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
- Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided
- useful feedback and improvements. Scott Rose, Rob Austein, Masataka
- Ohta, and Mark Andrews helped in clarifying the issues regarding
- additional data and the use of TTL. Jefsey Morfin, Ralph Droms,
- Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
- Rob Austein provided useful feedback during the WG last call. Thomas
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 23]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- Narten provided extensive feedback during the IESG evaluation.
-
-
-10. Security Considerations
-
-
- This document reviews the operational procedures for IPv6 DNS
- operations and does not have security considerations in itself.
-
-
- However, it is worth noting that in particular with Dynamic DNS
- Updates, security models based on the source address validation are
- very weak and cannot be recommended -- they could only be considered
- in the environments where ingress filtering [RFC3704] has been
- deployed. On the other hand, it should be noted that setting up an
- authorization mechanism (e.g., a shared secret, or public-private
- keys) between a node and the DNS server has to be done manually, and
- may require quite a bit of time and expertise.
-
-
- To re-emphasize which was already stated, the reverse+forward DNS
- check provides very weak security at best, and the only
- (questionable) security-related use for them may be in conjunction
- with other mechanisms when authenticating a user.
-
-
-11. References
-
-
-11.1 Normative References
-
-
- [I-D.ietf-dnsop-ipv6-dns-configuration]
- Jeong, J., "IPv6 Host Configuration of DNS Server
- Information Approaches",
- draft-ietf-dnsop-ipv6-dns-configuration-04 (work in
- progress), September 2004.
-
-
- [I-D.ietf-dnsop-misbehavior-against-aaaa]
- Morishita, Y. and T. Jinmei, "Common Misbehavior against
- DNS Queries for IPv6 Addresses",
- draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in
- progress), April 2004.
-
-
- [I-D.ietf-v6ops-application-transition]
- Shin, M., "Application Aspects of IPv6 Transition",
- draft-ietf-v6ops-application-transition-03 (work in
- progress), June 2004.
-
-
- [I-D.ietf-v6ops-renumbering-procedure]
- Baker, F., Lear, E. and R. Droms, "Procedures for
- Renumbering an IPv6 Network without a Flag Day",
- draft-ietf-v6ops-renumbering-procedure-01 (work in
- progress), July 2004.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 24]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
-
- [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.
-
-
- [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
- and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
- July 1997.
-
-
- [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC 2462, December 1998.
-
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
-
- [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
- Stateless Address Autoconfiguration in IPv6", RFC 3041,
- January 2001.
-
-
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
- via IPv4 Clouds", RFC 3056, February 2001.
-
-
- [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
- August 2001.
-
-
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
- M. Carney, "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
-
- [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T.
- Hain, "Representing Internet Protocol version 6 (IPv6)
- Addresses in the Domain Name System (DNS)", RFC 3363,
- August 2002.
-
-
- [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
- Support for Internet Protocol version 6 (IPv6)", RFC 3364,
- August 2002.
-
-
- [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
- (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 25]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
- Extensions to Support IP Version 6", RFC 3596, October
- 2003.
-
-
- [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
- Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
- December 2003.
-
-
- [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
- (DHCP) Service for IPv6", RFC 3736, April 2004.
-
-
- [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
- Addresses", RFC 3879, September 2004.
-
-
- [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
- Guidelines", BCP 91, RFC 3901, September 2004.
-
-
-11.2 Informative References
-
-
- [I-D.durand-v6ops-natpt-dns-alg-issues]
- Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
- draft-durand-v6ops-natpt-dns-alg-issues-00 (work in
- progress), February 2003.
-
-
- [I-D.huitema-v6ops-teredo]
- Huitema, C., "Teredo: Tunneling IPv6 over UDP through
- NATs", draft-huitema-v6ops-teredo-02 (work in progress),
- June 2004.
-
-
- [I-D.huston-6to4-reverse-dns]
- Huston, G., "6to4 Reverse DNS Delegation",
- draft-huston-6to4-reverse-dns-03 (work in progress),
- October 2004.
-
-
- [I-D.ietf-dhc-ddns-resolution]
- Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
- Clients", draft-ietf-dhc-ddns-resolution-08 (work in
- progress), October 2004.
-
-
- [I-D.ietf-dhc-fqdn-option]
- Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
- draft-ietf-dhc-fqdn-option-07 (work in progress), July
- 2004.
-
-
- [I-D.ietf-dnsext-dhcid-rr]
- Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for
- encoding DHCP information (DHCID RR)",
- draft-ietf-dnsext-dhcid-rr-08 (work in progress), July
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 26]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- 2004.
-
-
- [I-D.ietf-dnsop-bad-dns-res]
- Larson, M. and P. Barber, "Observed DNS Resolution
- Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in
- progress), July 2004.
-
-
- [I-D.ietf-dnsop-dontpublish-unreachable]
- Hazel, P., "IP Addresses that should never appear in the
- public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
- (work in progress), February 2002.
-
-
- [I-D.ietf-dnsop-inaddr-required]
- Senie, D., "Requiring DNS IN-ADDR Mapping",
- draft-ietf-dnsop-inaddr-required-05 (work in progress),
- April 2004.
-
-
- [I-D.ietf-ipseckey-rr]
- Richardson, M., "A method for storing IPsec keying
- material in DNS", draft-ietf-ipseckey-rr-11 (work in
- progress), July 2004.
-
-
- [I-D.ietf-ipv6-unique-local-addr]
- Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
- Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in
- progress), September 2004.
-
-
- [I-D.ietf-send-cga]
- Aura, T., "Cryptographically Generated Addresses (CGA)",
- draft-ietf-send-cga-06 (work in progress), April 2004.
-
-
- [I-D.ietf-v6ops-3gpp-analysis]
- Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
- Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
- progress), May 2004.
-
-
- [I-D.ietf-v6ops-mech-v2]
- Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
- for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06
- (work in progress), September 2004.
-
-
- [I-D.ietf-v6ops-onlinkassumption]
- Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
- On-Link Assumption Considered Harmful",
- draft-ietf-v6ops-onlinkassumption-02 (work in progress),
- May 2004.
-
-
- [I-D.ietf-v6ops-v6onbydefault]
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 27]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack
- IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
- (work in progress), July 2004.
-
-
- [I-D.jeong-dnsop-ipv6-dns-discovery]
- Jeong, J., "IPv6 DNS Discovery based on Router
- Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02
- (work in progress), July 2004.
-
-
- [I-D.moore-6to4-dns]
- Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
- in progress), October 2002.
-
-
- [I-D.ohta-preconfigured-dns]
- Ohta, M., "Preconfigured DNS Server Addresses",
- draft-ohta-preconfigured-dns-01 (work in progress),
- February 2004.
-
-
- [I-D.savola-v6ops-6bone-mess]
- Savola, P., "Moving from 6bone to IPv6 Internet",
- draft-savola-v6ops-6bone-mess-01 (work in progress),
- November 2002.
-
-
- [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
- Translation - Protocol Translation (NAT-PT)", RFC 2766,
- February 2000.
-
-
- [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
-
- [RFC2826] Internet Architecture Board, "IAB Technical Comment on the
- Unique DNS Root", RFC 2826, May 2000.
-
-
- [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
- Networks", BCP 84, RFC 3704, March 2004.
-
-
-
-Authors' Addresses
-
-
- Alain Durand
- SUN Microsystems, Inc.
- 17 Network circle UMPL17-202
- Menlo Park, CA 94025
- USA
-
-
- EMail: Alain.Durand@sun.com
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 28]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- Johan Ihren
- Autonomica
- Bellmansgatan 30
- SE-118 47 Stockholm
- Sweden
-
-
- EMail: johani@autonomica.se
-
-
-
- Pekka Savola
- CSC/FUNET
- Espoo
- Finland
-
-
- EMail: psavola@funet.fi
-
-
-Appendix A. Site-local Addressing Considerations for DNS
-
-
- As site-local addressing has been deprecated, the considerations for
- site-local addressing are discussed briefly here. Unique local
- addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed
- as a replacement, but being work-in-progress, it is not considered
- further.
-
-
- The interactions with DNS come in two flavors: forward and reverse
- DNS.
-
-
- To actually use site-local addresses within a site, this implies the
- deployment of a "split-faced" or a fragmented DNS name space, for the
- zones internal to the site, and the outsiders' view to it. The
- procedures to achieve this are not elaborated here. The implication
- is that site-local addresses must not be published in the public DNS.
-
-
- To faciliate reverse DNS (if desired) with site-local addresses, the
- stub resolvers must look for DNS information from the local DNS
- servers, not e.g. starting from the root servers, so that the
- site-local information may be provided locally. Note that the
- experience of private addresses in IPv4 has shown that the root
- servers get loaded for requests for private address lookups in any
- case.
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 29]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-Intellectual Property Statement
-
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights 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; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
-
- Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM 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.
-
-
-
-Copyright Statement
-
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 30]
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-Network Working Group O. Kolkman
-Request for Comments: 3757 RIPE NCC
-Updates: 3755, 2535 J. Schlyter
-Category: Standards Track NIC-SE
- E. Lewis
- ARIN
- April 2004
-
-
- Domain Name System KEY (DNSKEY) Resource Record (RR)
- Secure Entry Point (SEP) Flag
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- With the Delegation Signer (DS) resource record (RR), the concept of
- a public key acting as a secure entry point (SEP) has been
- introduced. During exchanges of public keys with the parent there is
- a need to differentiate SEP keys from other public keys in the Domain
- Name System KEY (DNSKEY) resource record set. A flag bit in the
- DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
- The flag bit is intended to assist in operational procedures to
- correctly generate DS resource records, or to indicate what DNSKEYs
- are intended for static configuration. The flag bit is not to be
- used in the DNS verification protocol. This document updates RFC
- 2535 and RFC 3755.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Standard Track [Page 1]
-\f
-RFC 3757 DNSKEY RR SEP Flag April 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4
- 3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4
- 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
- 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
- 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
- 7. Internationalization Considerations. . . . . . . . . . . . . . 6
- 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
- 9.2. Informative References . . . . . . . . . . . . . . . . . 6
- 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
- 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
-
-1. Introduction
-
- "All keys are equal but some keys are more equal than others" [6].
-
- With the definition of the Delegation Signer Resource Record (DS RR)
- [5], it has become important to differentiate between the keys in the
- DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
- other keys in the DNSKEY RR set. We refer to these public keys as
- Secure Entry Point (SEP) keys. A SEP key either used to generate a
- DS RR or is distributed to resolvers that use the key as the root of
- a trusted subtree [3].
-
- In early deployment tests, the use of two (kinds of) key pairs for
- each zone has been prevalent. For one kind of key pair the private
- key is used to sign just the zone's DNSKEY resource record (RR) set.
- Its public key is intended to be referenced by a DS RR at the parent
- or configured statically in a resolver. The private key of the other
- kind of key pair is used to sign the rest of the zone's data sets.
- The former key pair is called a key-signing key (KSK) and the latter
- is called a zone-signing key (ZSK). In practice there have been
- usually one of each kind of key pair, but there will be multiples of
- each at times.
-
- It should be noted that division of keys pairs into KSK's and ZSK's
- is not mandatory in any definition of DNSSEC, not even with the
- introduction of the DS RR. But, in testing, this distinction has
- been helpful when designing key roll over (key super-cession)
- schemes. Given that the distinction has proven helpful, the labels
- KSK and ZSK have begun to stick.
-
-
-
-
-
-
-Kolkman, et al. Standard Track [Page 2]
-\f
-RFC 3757 DNSKEY RR SEP Flag April 2004
-
-
- There is a need to differentiate the public keys for the key pairs
- that are used for key signing from keys that are not used key signing
- (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
- be sent for generating DS RRs, which DNSKEYs are to be distributed to
- resolvers, and which keys are fed to the signer application at the
- appropriate time.
-
- In other words, the SEP bit provides an in-band method to communicate
- a DNSKEY RR's intended use to third parties. As an example we
- present 3 use cases in which the bit is useful:
-
- The parent is a registry, the parent and the child use secured DNS
- queries and responses, with a preexisting trust-relation, or plain
- DNS over a secured channel to exchange the child's DNSKEY RR sets.
- Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
- bit can be used to isolate the DNSKEYs for which a DS RR needs to
- be created.
-
- An administrator has configured a DNSKEY as root for a trusted
- subtree into security aware resolver. Using a special purpose
- tool that queries for the KEY RRs from that domain's apex, the
- administrator will be able to notice the roll over of the trusted
- anchor by a change of the subset of KEY RRs with the DS flag set.
-
- A signer might use the SEP bit on the public key to determine
- which private key to use to exclusively sign the DNSKEY RRset and
- which private key to use to sign the other RRsets in the zone.
-
- As demonstrated in the above examples it is important to be able to
- differentiate the SEP keys from the other keys in a DNSKEY RR set in
- the flow between signer and (parental) key-collector and in the flow
- between the signer and the resolver configuration. The SEP flag is
- to be of no interest to the flow between the verifier and the
- authoritative data store.
-
- The reason for the term "SEP" is a result of the observation that the
- distinction between KSK and ZSK key pairs is made by the signer, a
- key pair could be used as both a KSK and a ZSK at the same time. To
- be clear, the term SEP was coined to lessen the confusion caused by
- the overlap. (Once this label was applied, it had the side effect of
- removing the temptation to have both a KSK flag bit and a ZSK flag
- bit.)
-
- The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
- "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
- interpreted as described in BCP 14, RFC 2119 [1].
-
-
-
-
-
-Kolkman, et al. Standard Track [Page 3]
-\f
-RFC 3757 DNSKEY RR SEP Flag April 2004
-
-
-2. The Secure Entry Point (SEP) Flag
-
- 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 |S| protocol | algorithm |
- | |E| | |
- | |P| | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
- / public key /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- DNSKEY RR Format
- This document assigns the 15th bit in the flags field as the secure
- entry point (SEP) bit. If the bit is set to 1 the key is intended to
- be used as secure entry point key. One SHOULD NOT assign special
- meaning to the key if the bit is set to 0. Operators can recognize
- the secure entry point key by the even or odd-ness of the decimal
- representation of the flag field.
-
-3. DNSSEC Protocol Changes
-
- The bit MUST NOT be used during the resolving and verification
- process. The SEP flag is only used to provide a hint about the
- different administrative properties of the key and therefore the use
- of the SEP flag does not change the DNS resolution protocol or the
- resolution process.
-
-4. Operational Guidelines
-
- The SEP bit is set by the key-pair-generator and MAY be used by the
- zone signer to decide whether the public part of the key pair is to
- be prepared for input to a DS RR generation function. The SEP bit is
- recommended to be set (to 1) whenever the public key of the key pair
- will be distributed to the parent zone to build the authentication
- chain or if the public key is to be distributed for static
- configuration in verifiers.
-
- When a key pair is created, the operator needs to indicate whether
- the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within
- the data that is used to compute the 'key tag field' in the SIG RR,
- changing the SEP bit will change the identity of the key within DNS.
- In other words, once a key is used to generate signatures, the
- setting of the SEP bit is to remain constant. If not, a verifier
- will not be able to find the relevant KEY RR.
-
-
-
-
-Kolkman, et al. Standard Track [Page 4]
-\f
-RFC 3757 DNSKEY RR SEP Flag April 2004
-
-
- When signing a zone, it is intended that the key(s) with the SEP bit
- set (if such keys exist) are used to sign the KEY RR set of the zone.
- The same key can be used to sign the rest of the zone data too. It
- is conceivable that not all keys with a SEP bit set will sign the
- DNSKEY RR set, such keys might be pending retirement or not yet in
- use.
-
- When verifying a RR set, the SEP bit is not intended to play a role.
- How the key is used by the verifier is not intended to be a
- consideration at key creation time.
-
- Although the SEP flag provides a hint on which public key is to be
- used as trusted root, administrators can choose to ignore the fact
- that a DNSKEY has its SEP bit set or not when configuring a trusted
- root for their resolvers.
-
- Using the SEP flag a key roll over can be automated. The parent can
- use an existing trust relation to verify DNSKEY RR sets in which a
- new DNSKEY RR with the SEP flag appears.
-
-5. Security Considerations
-
- As stated in Section 3 the flag is not to be used in the resolution
- protocol or to determine the security status of a key. The flag is
- to be used for administrative purposes only.
-
- No trust in a key should be inferred from this flag - trust MUST be
- inferred from an existing chain of trust or an out-of-band exchange.
-
- Since this flag might be used for automating public key exchanges, we
- think the following consideration is in place.
-
- Automated mechanisms for roll over of the DS RR might be vulnerable
- to a class of replay attacks. This might happen after a public key
- exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
- SEP flag set, is sent to the parent. The parent verifies the DNSKEY
- RR set with the existing trust relation and creates the new DS RR
- from the DNSKEY RR that the current DS RR is not pointing to. This
- key exchange might be replayed. Parents are encouraged to implement
- a replay defense. A simple defense can be based on a registry of
- keys that have been used to generate DS RRs during the most recent
- roll over. These same considerations apply to entities that
- configure keys in resolvers.
-
-
-
-
-
-
-
-
-Kolkman, et al. Standard Track [Page 5]
-\f
-RFC 3757 DNSKEY RR SEP Flag April 2004
-
-
-6. IANA Considerations
-
- IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
- Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
-
-7. Internationalization Considerations
-
- Although SEP is a popular acronym in many different languages, there
- are no internationalization considerations.
-
-8. Acknowledgments
-
- The ideas documented in this document are inspired by communications
- we had with numerous people and ideas published by other folk. Among
- others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
- Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
- have contributed ideas and provided feedback.
-
- This document saw the light during a workshop on DNSSEC operations
- hosted by USC/ISI in August 2002.
-
-9. References
-
-9.1. Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [3] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
- (DS)", RFC 3755, April 2004.
-
-9.2. Informative References
-
- [5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
- RFC 3658, December 2003.
-
- [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
- Story", ISBN 0151002177 (50th anniversary edition), April 1996.
-
-
-
-
-
-
-
-Kolkman, et al. Standard Track [Page 6]
-\f
-RFC 3757 DNSKEY RR SEP Flag April 2004
-
-
-10. 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/
-
-
- Jakob Schlyter
- NIC-SE
- Box 5774
- SE-114 87 Stockholm
- Sweden
-
- EMail: jakob@nic.se
- URI: http://www.nic.se/
-
-
- Edward P. Lewis
- ARIN
- 3635 Concorde Parkway Suite 200
- Chantilly, VA 20151
- US
-
- Phone: +1 703 227 9854
- EMail: edlewis@arin.net
- URI: http://www.arin.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Standard Track [Page 7]
-\f
-RFC 3757 DNSKEY RR SEP Flag April 2004
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78 and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
- INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights 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; nor does it
- represent that it has made any independent effort to identify any
- such rights. Information on the procedures with respect to
- rights in RFC documents can be found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
- specification can be obtained from the IETF on-line IPR repository
- at http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention
- any copyrights, patents or patent applications, or other
- proprietary rights that may cover technology that may be required
- to implement this standard. Please address the information to the
- IETF at ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Standard Track [Page 8]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group A. Durand
-Request for Comments: 3901 SUN Microsystems, Inc.
-BCP: 91 J. Ihren
-Category: Best Current Practice Autonomica
- September 2004
-
-
- DNS IPv6 Transport Operational Guidelines
-
-Status of this Memo
-
- This document specifies an Internet Best Current Practices for the
- Internet Community, and requests discussion and suggestions for
- improvements. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004).
-
-Abstract
-
- This memo provides guidelines and Best Current Practice for operating
- DNS in a world where queries and responses are carried in a mixed
- environment of IPv4 and IPv6 networks.
-
-1. Introduction to the Problem of Name Space Fragmentation:
- following the referral chain
-
- A resolver that tries to look up a name starts out at the root, and
- follows referrals until it is referred to a name server that is
- authoritative for the name. If somewhere down the chain of referrals
- it is referred to a name server that is only accessible over a
- transport which the resolver cannot use, the resolver is unable to
- finish the task.
-
- When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
- only a matter of time until this starts to happen. The complete DNS
- hierarchy then starts to fragment into a graph where authoritative
- name servers for certain nodes are only accessible over a certain
- transport. The concern is that a resolver using only a particular
- version of IP and querying information about another node using the
- same version of IP can not do it because somewhere in the chain of
- servers accessed during the resolution process, one or more of them
- will only be accessible with the other version of IP.
-
- With all DNS data only available over IPv4 transport everything is
- simple. IPv4 resolvers can use the intended mechanism of following
- referrals from the root and down while IPv6 resolvers have to work
-
-
-
-Durand & Ihren Best Current Practice [Page 1]
-\f
-RFC 3901 DNS IPv6 Transport Guidelines September 2004
-
-
- through a "translator", i.e., they have to use a recursive name
- server on a so-called "dual stack" host as a "forwarder" since they
- cannot access the DNS data directly.
-
- With all DNS data only available over IPv6 transport everything would
- be equally simple, with the exception of IPv4 recursive name servers
- having to switch to a forwarding configuration.
-
- However, the second situation will not arise in the foreseeable
- future. Instead, the transition will be from IPv4 only to a mixture
- of IPv4 and IPv6, with three categories of DNS data depending on
- whether the information is available only over IPv4 transport, only
- over IPv6 or both.
-
- Having DNS data available on both transports is the best situation.
- The major question is how to ensure that it becomes the norm as
- quickly as possible. However, while it is obvious that some DNS data
- will only be available over v4 transport for a long time it is also
- obvious that it is important to avoid fragmenting the name space
- available to IPv4 only hosts. For example, during transition it is
- not acceptable to break the name space that we presently have
- available for IPv4-only hosts.
-
-2. Terminology
-
- The phrase "IPv4 name server" indicates a name server available over
- IPv4 transport. It does not imply anything about what DNS [1,2] data
- is served. Likewise, "IPv6 [4,5,6] name server" indicates a name
- server available over IPv6 transport. The phrase "dual-stack name
- server" indicates a name server that is actually configured to run
- both protocols, IPv4 and IPv6, and not merely a server running on a
- system capable of running both but actually configured to run only
- one.
-
-3. Policy Based Avoidance of Name Space Fragmentation
-
- Today there are only a few DNS "zones" on the public Internet that
- are available over IPv6 transport, and most of them can be regarded
- as "experimental". However, as soon as the root and top level
- domains are available over IPv6 transport, it is reasonable to expect
- that it will become more common to have zones served by IPv6 servers.
-
- Having those zones served only by IPv6-only name server would not be
- a good development, since this will fragment the previously
- unfragmented IPv4 name space and there are strong reasons to find a
- mechanism to avoid it.
-
-
-
-
-
-Durand & Ihren Best Current Practice [Page 2]
-\f
-RFC 3901 DNS IPv6 Transport Guidelines September 2004
-
-
- The recommended approach to maintain name space continuity is to use
- administrative policies, as described in the next section.
-
-4. DNS IPv6 Transport recommended Guidelines
-
- In order to preserve name space continuity, the following
- administrative policies are recommended:
-
- - every recursive name server SHOULD be either IPv4-only or dual
- stack,
-
- This rules out IPv6-only recursive servers. However, one might
- design configurations where a chain of IPv6-only name server
- forward queries to a set of dual stack recursive name server
- actually performing those recursive queries.
-
- - every DNS zone SHOULD be served by at least one IPv4-reachable
- authoritative name server.
-
- This rules out DNS zones served only by IPv6-only authoritative
- name servers.
-
- Note: zone validation processes SHOULD ensure that there is at least
- one IPv4 address record available for the name servers of any child
- delegations within the zone.
-
-5. Security Considerations
-
- The guidelines described in this memo introduce no new security
- considerations into the DNS protocol or associated operational
- scenarios.
-
-6. Acknowledgment
-
- This document is the result of many conversations that happened in
- the DNS community at IETF and elsewhere since 2001. During that
- period of time, a number of Internet drafts have been published to
- clarify various aspects of the issues at stake. This document
- focuses on the conclusion of those discussions.
-
- The authors would like to acknowledge the role of Pekka Savola in his
- thorough review of the document.
-
-
-
-
-
-
-
-
-
-Durand & Ihren Best Current Practice [Page 3]
-\f
-RFC 3901 DNS IPv6 Transport Guidelines September 2004
-
-
-7. Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
- 9, RFC 2026, October 1996.
-
- [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
- Specification", RFC 2460, December 1998.
-
- [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
- Addressing Architecture", RFC 3513, April 2003.
-
- [6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
- Extensions to Support IP Version 6", RFC 3596, October 2003.
-
-8. Authors' Addresses
-
- Alain Durand
- SUN Microsystems, Inc
- 17 Network circle UMPK17-202
- Menlo Park, CA, 94025
- USA
-
- EMail: Alain.Durand@sun.com
-
-
- Johan Ihren
- Autonomica
- Bellmansgatan 30
- SE-118 47 Stockholm
- Sweden
-
- EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand & Ihren Best Current Practice [Page 4]
-\f
-RFC 3901 DNS IPv6 Transport Guidelines September 2004
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2004).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
- INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights 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; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the IETF's procedures with respect to rights in IETF Documents can
- be found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Durand & Ihren Best Current Practice [Page 5]
-\f
projects / thirdparty / bind9.git / commitdiff
