+++ /dev/null
-
-
-
-DNSEXT D. Blacka
-Internet-Draft VeriSign, Inc.
-Intended status: Standards Track April 7, 2006
-Expires: October 9, 2006
-
-
- DNSSEC Experiments
- draft-ietf-dnsext-dnssec-experiments-03
-
-Status of this Memo
-
- 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 becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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 October 9, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 1]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Abstract
-
- This document describes a methodology for deploying alternate, non-
- backwards-compatible, DNSSEC methodologies in an experimental fashion
- without disrupting the deployment of standard DNSSEC.
-
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8
- 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9
- 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
- 10.2. Informative References . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 2]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system (RFC 1035
- [5]) and the DNS security extensions ([2], [3], and [4] is assumed.
-
- The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 3]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-2. Overview
-
- Historically, experimentation with DNSSEC alternatives has been a
- problematic endeavor. There has typically been a desire to both
- introduce non-backwards-compatible changes to DNSSEC and to try these
- changes on real zones in the public DNS. This creates a problem when
- the change to DNSSEC would make all or part of the zone using those
- changes appear bogus (bad) or otherwise broken to existing security-
- aware resolvers.
-
- This document describes a standard methodology for setting up DNSSEC
- experiments. This methodology addresses the issue of co-existence
- with standard DNSSEC and DNS by using unknown algorithm identifiers
- to hide the experimental DNSSEC protocol modifications from standard
- security-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 4]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-3. Experiments
-
- When discussing DNSSEC experiments, it is necessary to classify these
- experiments into two broad categories:
-
- Backwards-Compatible: describes experimental changes that, while not
- strictly adhering to the DNSSEC standard, are nonetheless
- interoperable with clients and servers that do implement the
- DNSSEC standard.
-
- Non-Backwards-Compatible: describes experiments that would cause a
- standard security-aware resolver to (incorrectly) determine that
- all or part of a zone is bogus, or to otherwise not interoperate
- with standard DNSSEC clients and servers.
-
- Not included in these terms are experiments with the core DNS
- protocol itself.
-
- The methodology described in this document is not necessary for
- backwards-compatible experiments, although it certainly may be used
- if desired.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 5]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-4. Method
-
- The core of the methodology is the use of strictly unknown algorithm
- identifiers when signing the experimental zone, and more importantly,
- having only unknown algorithm identifiers in the DS records for the
- delegation to the zone at the parent.
-
- This technique works because of the way DNSSEC-compliant validators
- are expected to work in the presence of a DS set with only unknown
- algorithm identifiers. From [4], Section 5.2:
-
- If the validator does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
- And further:
-
- If the resolver does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver will not be able to
- verify the authentication path to the child zone. In this case,
- the resolver SHOULD treat the child zone as if it were unsigned.
-
- While this behavior isn't strictly mandatory (as marked by MUST), it
- is likely that a validator would implement this behavior, or, more to
- the point, it would handle this situation in a safe way (see below
- (Section 6).)
-
- Because we are talking about experiments, it is RECOMMENDED that
- private algorithm numbers be used (see [3], appendix A.1.1. Note
- that secure handling of private algorithms requires special handing
- by the validator logic. See [6] for further details.) Normally,
- instead of actually inventing new signing algorithms, the recommended
- path is to create alternate algorithm identifiers that are aliases
- for the existing, known algorithms. While, strictly speaking, it is
- only necessary to create an alternate identifier for the mandatory
- algorithms, it is suggested that all optional defined algorithms be
- aliased as well.
-
- It is RECOMMENDED that for a particular DNSSEC experiment, a
- particular domain name base is chosen for all new algorithms, then
- the algorithm number (or name) is prepended to it. For example, for
- experiment A, the base name of "dnssec-experiment-a.example.com" is
- chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
- defined to be "3.dnssec-experiment-a.example.com" and
- "5.dnssec-experiment-a.example.com". However, any unique identifier
-
-
-
-Blacka Expires October 9, 2006 [Page 6]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
- will suffice.
-
- Using this method, resolvers (or, more specifically, DNSSEC
- validators) essentially indicate their ability to understand the
- DNSSEC experiment's semantics by understanding what the new algorithm
- identifiers signify.
-
- This method creates two classes of security-aware servers and
- resolvers: servers and resolvers that are aware of the experiment
- (and thus recognize the experiment's algorithm identifiers and
- experimental semantics), and servers and resolvers that are unaware
- of the experiment.
-
- This method also precludes any zone from being both in an experiment
- and in a classic DNSSEC island of security. That is, a zone is
- either in an experiment and only experimentally validatable, or it is
- not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 7]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-5. Defining an Experiment
-
- The DNSSEC experiment MUST define the particular set of (previously
- unknown) algorithm identifiers that identify the experiment, and
- define what each unknown algorithm identifier means. Typically,
- unless the experiment is actually experimenting with a new DNSSEC
- algorithm, this will be a mapping of private algorithm identifiers to
- existing, known algorithms.
-
- Normally the experiment will choose a DNS name as the algorithm
- identifier base. This DNS name SHOULD be under the control of the
- authors of the experiment. Then the experiment will define a mapping
- between known mandatory and optional algorithms into this private
- algorithm identifier space. Alternately, the experiment MAY use the
- OID private algorithm space instead (using algorithm number 254), or
- MAY choose non-private algorithm numbers, although this would require
- an IANA allocation.
-
- For example, an experiment might specify in its description the DNS
- name "dnssec-experiment-a.example.com" as the base name, and declare
- that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
- algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
- alias of DNSSEC algorithm 5 (RSASHA1).
-
- Resolvers MUST only recognize the experiment's semantics when present
- in a zone signed by one or more of these algorithm identifiers. This
- is necessary to isolate the semantics of one experiment from any
- others that the resolver might understand.
-
- In general, resolvers involved in the experiment are expected to
- understand both standard DNSSEC and the defined experimental DNSSEC
- protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 8]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-6. Considerations
-
- There are a number of considerations with using this methodology.
-
- 1. Under some circumstances, it may be that the experiment will not
- be sufficiently masked by this technique and may cause resolution
- problem for resolvers not aware of the experiment. For instance,
- the resolver may look at a non-validatable response and conclude
- that the response is bogus, either due to local policy or
- implementation details. This is not expected to be a common
- case, however.
-
- 2. It will not be possible for security-aware resolvers unaware of
- the experiment to build a chain of trust through an experimental
- zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 9]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-7. Use in Non-Experiments
-
- This general methodology MAY be used for non-backwards compatible
- DNSSEC protocol changes that start out as or become standards. In
- this case:
-
- o The protocol change SHOULD use public IANA allocated algorithm
- identifiers instead of private algorithm identifiers. This will
- help identify the protocol change as a standard, rather than an
- experiment.
-
- o Resolvers MAY recognize the protocol change in zones not signed
- (or not solely signed) using the new algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 10]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-8. Security Considerations
-
- Zones using this methodology will be considered insecure by all
- resolvers except those aware of the experiment. It is not generally
- possible to create a secure delegation from an experimental zone that
- will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 11]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-9. IANA Considerations
-
- This document has no IANA actions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 12]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-10. References
-
-10.1. Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
-10.2. Informative References
-
- [5] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [6] Austein, R. and S. Weiler, "Clarifications and Implementation
- Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
- (work in progress), January 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 13]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Author's Address
-
- David Blacka
- VeriSign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- Email: davidb@verisign.com
- URI: http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 14]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- 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.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 15]
-\f
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Bernard Aboba
-INTERNET-DRAFT Dave Thaler
-Category: Standards Track Levon Esibov
-<draft-ietf-dnsext-mdns-46.txt> Microsoft Corporation
-16 April 2006
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
- 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 becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- 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 October 15, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2006.
-
-Abstract
-
- The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
- name resolution in scenarios in which conventional DNS name
- resolution is not possible. LLMNR supports all current and future
- DNS formats, types and classes, while operating on a separate port
- from DNS, and with a distinct resolver cache. Since LLMNR only
- operates on the local link, it cannot be considered a substitute for
- DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name Resolution Using LLMNR ........................... 4
- 2.1 LLMNR Packet Format ............................. 5
- 2.2 Sender Behavior ................................. 8
- 2.3 Responder Behavior .............................. 8
- 2.4 Unicast Queries and Responses ................... 11
- 2.5 Off-link Detection .............................. 11
- 2.6 Responder Responsibilities ...................... 12
- 2.7 Retransmission and Jitter ....................... 13
- 2.8 DNS TTL ......................................... 14
- 2.9 Use of the Authority and Additional Sections .... 14
-3. Usage model ........................................... 15
- 3.1 LLMNR Configuration ............................. 16
-4. Conflict Resolution ................................... 18
- 4.1 Uniqueness Verification ......................... 18
- 4.2 Conflict Detection and Defense .................. 19
- 4.3 Considerations for Multiple Interfaces .......... 20
- 4.4 API issues ...................................... 22
-5. Security Considerations ............................... 22
- 5.1 Denial of Service ............................... 22
- 5.2 Spoofing ...............,........................ 23
- 5.3 Authentication .................................. 24
- 5.4 Cache and Port Separation ....................... 24
-6. IANA considerations ................................... 25
-7. Constants ............................................. 25
-8. References ............................................ 26
- 8.1 Normative References ............................ 26
- 8.2 Informative References .......................... 26
-Acknowledgments .............................................. 28
-Authors' Addresses ........................................... 28
-Intellectual Property Statement .............................. 29
-Disclaimer of Validity ....................................... 29
-Copyright Statement .......................................... 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which is based on the DNS packet format and supports all current and
- future DNS formats, types and classes. LLMNR operates on a separate
- port from the Domain Name System (DNS), with a distinct resolver
- cache.
-
- Since LLMNR only operates on the local link, it cannot be considered
- a substitute for DNS. Link-scope multicast addresses are used to
- prevent propagation of LLMNR traffic across routers, potentially
- flooding the network. LLMNR queries can also be sent to a unicast
- address, as described in Section 2.4.
-
- Propagation of LLMNR packets on the local link is considered
- sufficient to enable name resolution in small networks. In such
- networks, if a network has a gateway, then typically the network is
- able to provide DNS server configuration. Configuration issues are
- discussed in Section 3.1.
-
- In the future, it may be desirable to consider use of multicast name
- resolution with multicast scopes beyond the link-scope. This could
- occur if LLMNR deployment is successful, the need arises for
- multicast name resolution beyond the link-scope, or multicast routing
- becomes ubiquitous. For example, expanded support for multicast name
- resolution might be required for mobile ad-hoc networks.
-
- Once we have experience in LLMNR deployment in terms of
- administrative issues, usability and impact on the network, it will
- be possible to reevaluate which multicast scopes are appropriate for
- use with multicast name resolution. IPv4 administratively scoped
- multicast usage is specified in "Administratively Scoped IP
- Multicast" [RFC2365].
-
- Service discovery in general, as well as discovery of DNS servers
- using LLMNR in particular, is outside of the scope of this document,
- as is name resolution over non-multicast capable media.
-
-1.1. Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
- and "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1.2. Terminology
-
- This document assumes familiarity with DNS terminology defined in
- [RFC1035]. Other terminology used in this document includes:
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An LLMNR responder considers one of its addresses reachable over a
- link if it will respond to an ARP or Neighbor Discovery query for
- that address received on that link.
-
-Responder
- A host that listens to LLMNR queries, and responds to those for
- which it is authoritative.
-
-Sender
- A host that sends an LLMNR query.
-
-UNIQUE
- There are some scenarios when multiple responders may respond to
- the same query. There are other scenarios when only one responder
- may respond to a query. Names for which only a single responder is
- anticipated are referred to as UNIQUE. Name uniqueness is
- configured on the responder, and therefore uniqueness verification
- is the responder's responsibility.
-
-2. Name Resolution Using LLMNR
-
- LLMNR queries are sent to and received on port 5355. The IPv4 link-
- scope multicast address a given responder listens to, and to which a
- sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
- address a given responder listens to, and to which a sender sends all
- queries, is FF02:0:0:0:0:0:1:3.
-
- Typically a host is configured as both an LLMNR sender and a
- responder. A host MAY be configured as a sender, but not a
- responder. However, a host configured as a responder MUST act as a
- sender, if only to verify the uniqueness of names as described in
- Section 4. This document does not specify how names are chosen or
- configured. This may occur via any mechanism, including DHCPv4
- [RFC2131] or DHCPv6 [RFC3315].
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] An LLMNR sender sends an LLMNR query to the link-scope
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- multicast address(es), unless a unicast query is indicated,
- as specified in Section 2.4.
-
- [b] A responder responds to this query only if it is authoritative
- for the name in the query. A responder responds to a
- multicast query by sending a unicast UDP response to the sender.
- Unicast queries are responded to as indicated in Section 2.4.
-
- [c] Upon reception of the response, the sender processes it.
-
- The sections that follow provide further details on sender and
- responder behavior.
-
-2.1. LLMNR Packet Format
-
- LLMNR is based on the DNS packet format defined in [RFC1035] Section
- 4 for both queries and responses. LLMNR implementations SHOULD send
- UDP queries and responses only as large as are known to be
- permissible without causing fragmentation. When in doubt a maximum
- packet size of 512 octets SHOULD be used. LLMNR implementations MUST
- accept UDP queries and responses as large as the smaller of the link
- MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
- octets for the header, VLAN tag and CRC).
-
-2.1.1. LLMNR Header Format
-
- LLMNR queries and responses utilize the DNS header format defined in
- [RFC1035] with exceptions noted below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value. For advice on generation of pseudo-random values, please
- consult [RFC1750].
-
-QR Query/Response. A one bit field, which if set indicates that the
- message is an LLMNR response; if clear then the message is an LLMNR
- query.
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-C Conflict. When set within a request, the 'C'onflict bit indicates
- that a sender has received multiple LLMNR responses to this query.
- In an LLMNR response, if the name is considered UNIQUE, then the
- 'C' bit is clear, otherwise it is set. LLMNR senders do not
- retransmit queries with the 'C' bit set. Responders MUST NOT
- respond to LLMNR queries with the 'C' bit set, but may start the
- uniqueness verification process, as described in Section 4.2.
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set in an LLMNR response,
- then the sender SHOULD resend the LLMNR query over TCP using the
- unicast address of the responder as the destination address. If
- the sender receives a response to the TCP query, then it SHOULD
- discard the UDP response with the TC bit set. See [RFC2181] and
- Section 2.4 of this specification for further discussion of the TC
- bit.
-
-T Tentative. The 'T'entative bit is set in a response if the
- responder is authoritative for the name, but has not yet verified
- the uniqueness of the name. A responder MUST ignore the 'T' bit in
- a query, if set. A response with the 'T' bit set is silently
- discarded by the sender, except if it is a uniqueness query, in
- which case a conflict has been detected and a responder MUST
- resolve the conflict as described in Section 4.1.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the sender MUST set RCODE to zero;
- the responder ignores the RCODE and assumes it to be zero. The
- response to a multicast LLMNR query MUST have RCODE set to zero. A
- sender MUST silently discard an LLMNR response with a non-zero
- RCODE sent in response to a multicast query.
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferable to not
- sending a response, since it enables errors to be diagnosed. This
- may be required, for example, when an LLMNR query includes a TSIG
- RR in the additional section, and the responder encounters a
- problem that requires returning a non-zero RCODE. TSIG error
- conditions defined in [RFC2845] include a TSIG RR in an
- unacceptable position (RCODE=1) or a TSIG RR which does not
- validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)).
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9. LLMNR
- responders MUST silently discard LLMNR queries with NSCOUNT not
- equal to zero.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender Behavior
-
- A sender MAY send an LLMNR query for any legal resource record type
- (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
- As described in Section 2.4, a sender MAY also send a unicast query.
-
- The sender MUST anticipate receiving no replies to some LLMNR
- queries, in the event that no responders are available within the
- link-scope. If no response is received, a resolver treats it as a
- response that the name does not exist (RCODE=3 is returned). A
- sender can handle duplicate responses by discarding responses with a
- source IP address and ID field that duplicate a response already
- received.
-
- When multiple valid LLMNR responses are received with the 'C' bit
- set, they SHOULD be concatenated and treated in the same manner that
- multiple RRs received from the same DNS server would be. However,
- responses with the 'C' bit set SHOULD NOT be concatenated with
- responses with the 'C' bit clear; instead, only the responses with
- the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
- received along with error response(s), then the error responses are
- silently discarded.
-
- Since the responder may order the RRs in the response so as to
- indicate preference, the sender SHOULD preserve ordering in the
- response to the querying application.
-
-2.3. Responder Behavior
-
- An LLMNR response MUST be sent to the sender via unicast.
-
- Upon configuring an IP address, responders typically will synthesize
- corresponding A, AAAA and PTR RRs so as to be able to respond to
- LLMNR queries for these RRs. An SOA RR is synthesized only when a
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responder has another RR in addition to the SOA RR; the SOA RR MUST
- NOT be the only RR that a responder has. However, in general whether
- RRs are manually or automatically created is an implementation
- decision.
-
- For example, a host configured to have computer name "host1" and to
- be a member of the "example.com" domain, and with IPv4 address
- 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
- authoritative for the following records:
-
- host1. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- host1.example.com. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- 1.2.0.192.in-addr.arpa. IN PTR host1.
- IN PTR host1.example.com.
-
- 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
- ip6.arpa IN PTR host1. (line split for formatting reasons)
- IN PTR host1.example.com.
-
- An LLMNR responder might be further manually configured with the name
- of a local mail server with an MX RR included in the "host1." and
- "host1.example.com." records.
-
- In responding to queries:
-
-[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
- address(es) defined in Section 2, and on TCP port 5355 on the
- unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses MUST always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups, with the exception of queries with the 'C' bit
- set, which do not elicit a response.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[e] Responders MUST NOT respond using data from the LLMNR or DNS
- resolver cache.
-
-[f] If a DNS server is running on a host that supports LLMNR, the DNS
- server MUST respond to LLMNR queries only for the RRSets relating
- to the host on which the server is running, but MUST NOT respond
- for other records for which the server is authoritative. DNS
- servers also MUST NOT send LLMNR queries in order to resolve DNS
- queries.
-
-[g] If a responder is authoritative for a name, it MUST respond with
- RCODE=0 and an empty answer section, if the type of query does not
- match a RR that the responder has.
-
- As an example, a host configured to respond to LLMNR queries for the
- name "foo.example.com." is authoritative for the name
- "foo.example.com.". On receiving an LLMNR query for an A RR with the
- name "foo.example.com." the host authoritatively responds with A
- RR(s) that contain IP address(es) in the RDATA of the resource
- record. If the responder has a AAAA RR, but no A RR, and an A RR
- query is received, the responder would respond with RCODE=0 and an
- empty answer section.
-
- In conventional DNS terminology a DNS server authoritative for a zone
- is authoritative for all the domain names under the zone apex except
- for the branches delegated into separate zones. Contrary to
- conventional DNS terminology, an LLMNR responder is authoritative
- only for the zone apex.
-
- For example the host "foo.example.com." is not authoritative for the
- name "child.foo.example.com." unless the host is configured with
- multiple names, including "foo.example.com." and
- "child.foo.example.com.". As a result, "foo.example.com." cannot
- reply to an LLMNR query for "child.foo.example.com." with RCODE=3
- (authoritative name error). The purpose of limiting the name
- authority scope of a responder is to prevent complications that could
- be caused by coexistence of two or more hosts with the names
- representing child and parent (or grandparent) nodes in the DNS tree,
- for example, "foo.example.com." and "child.foo.example.com.".
-
- Without the restriction on authority an LLMNR query for an A resource
- record for the name "child.foo.example.com." would result in two
- authoritative responses: RCODE=3 (authoritative name error) received
- from "foo.example.com.", and a requested A record - from
- "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
- hosts could perform a dynamic update of the parent (or grandparent)
- zone with a delegation to a child zone; for example a host
- "child.foo.example.com." could send a dynamic update for the NS and
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- glue A record to "foo.example.com.". However, this approach
- significantly complicates implementation of LLMNR and would not be
- acceptable for lightweight hosts.
-
-2.4. Unicast Queries and Responses
-
- Unicast queries SHOULD be sent when:
-
- [a] A sender repeats a query after it received a response
- with the TC bit set to the previous LLMNR multicast query, or
-
- [b] The sender queries for a PTR RR of a fully formed IP address
- within the "in-addr.arpa" or "ip6.arpa" zones.
-
- Unicast LLMNR queries MUST be done using TCP and the responses MUST
- be sent using the same TCP connection as the query. Senders MUST
- support sending TCP queries, and responders MUST support listening
- for TCP queries. If the sender of a TCP query receives a response to
- that query not using TCP, the response MUST be silently discarded.
-
- Unicast UDP queries MUST be silently discarded.
-
- A unicast PTR RR query for an off-link address will not elicit a
- response, but instead an ICMP TTL or Hop Limit exceeded message will
- be received. An implementation receiving an ICMP message in response
- to a TCP connection setup attempt can return immediately, treating
- this as a response that no such name exists (RCODE=3 is returned).
- An implementation that cannot process ICMP messages MAY send
- multicast UDP queries for PTR RRs. Since TCP implementations will
- not retransmit prior to RTOmin, a considerable period will elapse
- before TCP retransmits multiple times, resulting in a long timeout
- for TCP PTR RR queries sent to an off-link destination.
-
-2.5. "Off link" Detection
-
- A sender MUST select a source address for LLMNR queries that is
- assigned on the interface on which the query is sent. The
- destination address of an LLMNR query MUST be a link-scope multicast
- address or a unicast address.
-
- A responder MUST select a source address for responses that is
- assigned on the interface on which the query was received. The
- destination address of an LLMNR response MUST be a unicast address.
-
- On receiving an LLMNR query, the responder MUST check whether it was
- sent to a LLMNR multicast addresses defined in Section 2. If it was
- sent to another multicast address, then the query MUST be silently
- discarded.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- Section 2.4 discusses use of TCP for LLMNR queries and responses. In
- composing an LLMNR query using TCP, the sender MUST set the Hop Limit
- field in the IPv6 header and the TTL field in the IPv4 header of the
- response to one (1). The responder SHOULD set the TTL or Hop Limit
- settings on the TCP listen socket to one (1) so that SYN-ACK packets
- will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
- prevents an incoming connection from off-link since the sender will
- not receive a SYN-ACK from the responder.
-
- For UDP queries and responses, the Hop Limit field in the IPv6 header
- and the TTL field in the IPV4 header MAY be set to any value.
- However, it is RECOMMENDED that the value 255 be used for
- compatibility with early implementations of [RFC3927].
-
- Implementation note:
-
- In the sockets API for IPv4 [POSIX], the IP_TTL and
- IP_MULTICAST_TTL socket options are used to set the TTL of
- outgoing unicast and multicast packets. The IP_RECVTTL socket
- option is available on some platforms to retrieve the IPv4 TTL of
- received packets with recvmsg(). [RFC2292] specifies similar
- options for setting and retrieving the IPv6 Hop Limit.
-
-2.6. Responder Responsibilities
-
- It is the responsibility of the responder to ensure that RRs returned
- in LLMNR responses MUST only include values that are valid on the
- local interface, such as IPv4 or IPv6 addresses valid on the local
- link or names defended using the mechanism described in Section 4.
- IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
- addresses are defined in [RFC2373]. In particular:
-
- [a] If a link-scope IPv6 address is returned in a AAAA RR,
- that address MUST be valid on the local link over which
- LLMNR is used.
-
- [b] If an IPv4 address is returned, it MUST be reachable
- through the link over which LLMNR is used.
-
- [c] If a name is returned (for example in a CNAME, MX
- or SRV RR), the name MUST be resolvable on the local
- link over which LLMNR is used.
-
- Where multiple addresses represent valid responses to a query, the
- order in which the addresses are returned is as follows:
-
- [d] If the source address of the query is a link-scope address,
- then the responder SHOULD include a link-scope address first
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- in the response, if available.
-
- [e] If the source address of the query is a routable address,
- then the responder MUST include a routable address first
- in the response, if available.
-
-2.7. Retransmission and Jitter
-
- An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
- when to retransmit an LLMNR query. An LLMNR sender SHOULD either
- estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
- high initial timeout. Suggested constants are described in Section
- 7.
-
- If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
- then a sender SHOULD repeat the transmission of the query in order to
- assure that it was received by a host capable of responding to it.
- An LLMNR query SHOULD NOT be sent more than three times.
-
- Where LLMNR queries are sent using TCP, retransmission is handled by
- the transport layer. Queries with the 'C' bit set MUST be sent using
- multicast UDP and MUST NOT be retransmitted.
-
- An LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
- has been received, or if it is necessary to collect all potential
- responses, such as if a uniqueness verification query is being made.
- Otherwise an LLMNR sender SHOULD consider a multicast query answered
- after the first response is received, if that response has the 'C'
- bit clear.
-
- However, if the first response has the 'C' bit set, then the sender
- SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect
- all possible responses. When multiple valid answers are received,
- they may first be concatenated, and then treated in the same manner
- that multiple RRs received from the same DNS server would. A unicast
- query sender considers the query answered after the first response is
- received.
-
- Since it is possible for a response with the 'C' bit clear to be
- followed by a response with the 'C' bit set, an LLMNR sender SHOULD
- be prepared to process additional responses for the purposes of
- conflict detection, even after it has considered a query answered.
-
- In order to avoid synchronization, the transmission of each LLMNR
- query and response SHOULD delayed by a time randomly selected from
- the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responders responding with names which they have previously
- determined to be UNIQUE (see Section 4 for details).
-
-2.8. DNS TTL
-
- The responder should insert a pre-configured TTL value in the records
- returned in an LLMNR response. A default value of 30 seconds is
- RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
- networks), the TTL value may need to be reduced.
-
- Due to the TTL minimalization necessary when caching an RRset, all
- TTLs in an RRset MUST be set to the same value.
-
-2.9. Use of the Authority and Additional Sections
-
- Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
- concept of delegation. In LLMNR, the NS resource record type may be
- stored and queried for like any other type, but it has no special
- delegation semantics as it does in the DNS. Responders MAY have NS
- records associated with the names for which they are authoritative,
- but they SHOULD NOT include these NS records in the authority
- sections of responses.
-
- Responders SHOULD insert an SOA record into the authority section of
- a negative response, to facilitate negative caching as specified in
- [RFC2308]. The TTL of this record is set from the minimum of the
- MINIMUM field of the SOA record and the TTL of the SOA itself, and
- indicates how long a resolver may cache the negative answer. The
- owner name of the SOA record (MNAME) MUST be set to the query name.
- The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
- by senders. Negative responses without SOA records SHOULD NOT be
- cached.
-
- In LLMNR, the additional section is primarily intended for use by
- EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
- senders MAY only include pseudo RR-types in the additional section of
- a query; unless the 'C' bit is set, responders MUST ignore the
- additional section of queries containing other RR types.
-
- In queries where the 'C' bit is set, the sender SHOULD include the
- conflicting RRs in the additional section. Since conflict
- notifications are advisory, responders SHOULD log information from
- the additional section, but otherwise MUST ignore the additional
- section.
-
- Senders MUST NOT cache RRs from the authority or additional section
- of a response as answers, though they may be used for other purposes
- such as negative caching.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-3. Usage Model
-
- LLMNR is a peer-to-peer name resolution protocol that is not intended
- as a replacement for DNS; rather, it enables name resolution in
- scenarios in which conventional DNS name resolution is not possible.
- This includes situations in which hosts are not configured with the
- address of a DNS server; where the DNS server is unavailable or
- unreachable; where there is no DNS server authoritative for the name
- of a host, or where the authoritative DNS server does not have the
- desired RRs.
-
- By default, an LLMNR sender SHOULD send LLMNR queries only for
- single-label names. In order to reduce unnecessary DNS queries, stub
- resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS
- queries for single-label names. An LLMNR sender SHOULD NOT be
- enabled to send a query for any name, except where security
- mechanisms (described in Section 5.3) can be utilized.
-
- Regardless of whether security mechanisms can be utilized, LLMNR
- queries SHOULD NOT be sent unless one of the following conditions are
- met:
-
- [1] No manual or automatic DNS configuration has been performed.
- If DNS server address(es) have been configured, a
- host SHOULD attempt to reach DNS servers over all protocols
- on which DNS server address(es) are configured, prior to sending
- LLMNR queries. For dual stack hosts configured with DNS server
- address(es) for one protocol but not another, this implies that
- DNS queries SHOULD be sent over the protocol configured with
- a DNS server, prior to sending LLMNR queries.
-
- [2] All attempts to resolve the name via DNS on all interfaces
- have failed after exhausting the searchlist. This can occur
- because DNS servers did not respond, or because they
- responded to DNS queries with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section. Where a
- single resolver call generates DNS queries for A and AAAA RRs,
- an implementation MAY choose not to send LLMNR queries if any
- of the DNS queries is successful. An LLMNR query SHOULD only
- be sent for the originally requested name; a searchlist
- is not used to form additional LLMNR queries.
-
- Since LLMNR is a secondary name resolution mechanism, its usage is in
- part determined by the behavior of DNS implementations. In general,
- robust DNS resolver implementations are more likely to avoid
- unnecessary LLMNR queries.
-
- As noted in [DNSPerf], even when DNS servers are configured, a
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- significant fraction of DNS queries do not receive a response, or
- result in negative responses due to missing inverse mappings or NS
- records that point to nonexistent or inappropriate hosts. This has
- the potential to result in a large number of unnecessary LLMNR
- queries.
-
- [RFC1536] describes common DNS implementation errors and fixes. If
- the proposed fixes are implemented, unnecessary LLMNR queries will be
- reduced substantially, and so implementation of [RFC1536] is
- recommended.
-
- For example, [RFC1536] Section 1 describes issues with retransmission
- and recommends implementation of a retransmission policy based on
- round trip estimates, with exponential back-off. [RFC1536] Section 4
- describes issues with failover, and recommends that resolvers try
- another server when they don't receive a response to a query. These
- policies are likely to avoid unnecessary LLMNR queries.
-
- [RFC1536] Section 3 describes zero answer bugs, which if addressed
- will also reduce unnecessary LLMNR queries.
-
- [RFC1536] Section 6 describes name error bugs and recommended
- searchlist processing that will reduce unnecessary RCODE=3
- (authoritative name) errors, thereby also reducing unnecessary LLMNR
- queries.
-
- If error responses are received from both DNS and LLMNR, then the
- lowest RCODE value should be returned. For example, if either DNS or
- LLMNR receives a response with RCODE=0, then this should returned to
- the caller.
-
-3.1. LLMNR Configuration
-
- LLMNR usage MAY be configured manually or automatically on a per
- interface basis. By default, LLMNR responders SHOULD be enabled on
- all interfaces, at all times. Enabling LLMNR for use in situations
- where a DNS server has been configured will result in a change in
- default behavior without a simultaneous update to configuration
- information. Where this is considered undesirable, LLMNR SHOULD NOT
- be enabled by default, so that hosts will neither listen on the link-
- scope multicast address, nor will they send queries to that address.
-
- Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
- possible for a dual stack host to be configured with the address of a
- DNS server over IPv4, while remaining unconfigured with a DNS server
- suitable for use over IPv6.
-
- In these situations, a dual stack host will send AAAA queries to the
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- configured DNS server over IPv4. However, an IPv6-only host
- unconfigured with a DNS server suitable for use over IPv6 will be
- unable to resolve names using DNS. Automatic IPv6 DNS configuration
- mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
- deployed, and not all DNS servers support IPv6. Therefore lack of
- IPv6 DNS configuration may be a common problem in the short term, and
- LLMNR may prove useful in enabling link-local name resolution over
- IPv6.
-
- Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
- IPv6-only hosts may not be configured with a DNS server. Where there
- is no DNS server authoritative for the name of a host or the
- authoritative DNS server does not support dynamic client update over
- IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
- be able to do DNS dynamic update, and other hosts will not be able to
- resolve its name.
-
- For example, if the configured DNS server responds to a AAAA RR query
- sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
- RCODE=0 and an empty answer section, then a AAAA RR query sent using
- LLMNR over IPv6 may be successful in resolving the name of an
- IPv6-only host on the local link.
-
- Similarly, if a DHCPv4 server is available providing DNS server
- configuration, and DNS server(s) exist which are authoritative for
- the A RRs of local hosts and support either dynamic client update
- over IPv4 or DHCPv4-based dynamic update, then the names of local
- IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
- DNS server is authoritative for the names of local hosts, or the
- authoritative DNS server(s) do not support dynamic update, then LLMNR
- enables linklocal name resolution over IPv4.
-
- Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
- configure LLMNR on an interface. The LLMNR Enable Option, described
- in [LLMNREnable], can be used to explicitly enable or disable use of
- LLMNR on an interface. The LLMNR Enable Option does not determine
- whether or in which order DNS itself is used for name resolution.
- The order in which various name resolution mechanisms should be used
- can be specified using the Name Service Search Option (NSSO) for DHCP
- [RFC2937], using the LLMNR Enable Option code carried in the NSSO
- data.
-
- It is possible that DNS configuration mechanisms will go in and out
- of service. In these circumstances, it is possible for hosts within
- an administrative domain to be inconsistent in their DNS
- configuration.
-
- For example, where DHCP is used for configuring DNS servers, one or
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- more DHCP servers can fail. As a result, hosts configured prior to
- the outage will be configured with a DNS server, while hosts
- configured after the outage will not. Alternatively, it is possible
- for the DNS configuration mechanism to continue functioning while
- configured DNS servers fail.
-
- An outage in the DNS configuration mechanism may result in hosts
- continuing to use LLMNR even once the outage is repaired. Since
- LLMNR only enables linklocal name resolution, this represents a
- degradation in capabilities. As a result, hosts without a configured
- DNS server may wish to periodically attempt to obtain DNS
- configuration if permitted by the configuration mechanism in use. In
- the absence of other guidance, a default retry interval of one (1)
- minute is RECOMMENDED.
-
-4. Conflict Resolution
-
- By default, a responder SHOULD be configured to behave as though its
- name is UNIQUE on each interface on which LLMNR is enabled. However,
- it is also possible to configure multiple responders to be
- authoritative for the same name. For example, multiple responders
- MAY respond to a query for an A or AAAA type record for a cluster
- name (assigned to multiple hosts in the cluster).
-
- To detect duplicate use of a name, an administrator can use a name
- resolution utility which employs LLMNR and lists both responses and
- responders. This would allow an administrator to diagnose behavior
- and potentially to intervene and reconfigure LLMNR responders who
- should not be configured to respond to the same name.
-
-4.1. Uniqueness Verification
-
- Prior to sending an LLMNR response with the 'T' bit clear, a
- responder configured with a UNIQUE name MUST verify that there is no
- other host within the scope of LLMNR query propagation that is
- authoritative for the same name on that interface.
-
- Once a responder has verified that its name is UNIQUE, if it receives
- an LLMNR query for that name, with the 'C' bit clear, it MUST
- respond, with the 'T' bit clear. Prior to verifying that its name is
- UNIQUE, a responder MUST set the 'T' bit in responses.
-
- Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive
- during sleep)
- - is configured to respond to LLMNR queries on an interface
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- enabled for transmission and reception of IP traffic
- - is configured to respond to LLMNR queries using additional
- UNIQUE resource records
- - verifies the acquisition of a new IP address and configuration
- on an interface
-
- To verify uniqueness, a responder MUST send an LLMNR query with the
- 'C' bit clear, over all protocols on which it responds to LLMNR
- queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
- uniqueness of a name by sending a query for the name with type='ANY'.
-
- If no response is received, the sender retransmits the query, as
- specified in Section 2.7. If a response is received, the sender MUST
- check if the source address matches the address of any of its
- interfaces; if so, then the response is not considered a conflict,
- since it originates from the sender. To avoid triggering conflict
- detection, a responder that detects that it is connected to the same
- link on multiple interfaces SHOULD set the 'C' bit in responses.
-
- If a response is received with the 'T' bit clear, the responder MUST
- NOT use the name in response to LLMNR queries received over any
- protocol (IPv4 or IPv6). If a response is received with the 'T' bit
- set, the responder MUST check if the source IP address in the
- response, interpreted as an unsigned integer, is less than the source
- IP address in the query. If so, the responder MUST NOT use the name
- in response to LLMNR queries received over any protocol (IPv4 or
- IPv6). For the purpose of uniqueness verification, the contents of
- the answer section in a response is irrelevant.
-
- Periodically carrying out uniqueness verification in an attempt to
- detect name conflicts is not necessary, wastes network bandwidth, and
- may actually be detrimental. For example, if network links are
- joined only briefly, and are separated again before any new
- communication is initiated, temporary conflicts are benign and no
- forced reconfiguration is required. LLMNR responders SHOULD NOT
- periodically attempt uniqueness verification.
-
-4.2. Conflict Detection and Defense
-
- Hosts on disjoint network links may configure the same name for use
- with LLMNR. If these separate network links are later joined or
- bridged together, then there may be multiple hosts which are now on
- the same link, trying to use the same name.
-
- In order to enable ongoing detection of name conflicts, when an LLMNR
- sender receives multiple LLMNR responses to a query, it MUST check if
- the 'C' bit is clear in any of the responses. If so, the sender
- SHOULD send another query for the same name, type and class, this
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- time with the 'C' bit set, with the potentially conflicting resource
- records included in the additional section.
-
- Queries with the 'C' bit set are considered advisory and responders
- MUST verify the existence of a conflict before acting on it. A
- responder receiving a query with the 'C' bit set MUST NOT respond.
-
- If the query is for a UNIQUE name, then the responder MUST send its
- own query for the same name, type and class, with the 'C' bit clear.
- If a response is received, the sender MUST check if the source
- address matches the address of any of its interfaces; if so, then the
- response is not considered a conflict, since it originates from the
- sender. To avoid triggering conflict detection, a responder that
- detects that it is connected to the same link on multiple interfaces
- SHOULD set the 'C' bit in responses.
-
- An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
- log them. Upon detecting a conflict, an LLMNR responder MUST
- immediately stop using the conflicting name in response to LLMNR
- queries received over any supported protocol, if the source IP
- address in the response, interpreted as an unsigned integer, is less
- than the source IP address in the uniqueness verification query.
-
- After stopping the use of a name, the responder MAY elect to
- configure a new name. However, since name reconfiguration may be
- disruptive, this is not required, and a responder may have been
- configured to respond to multiple names so that alternative names may
- already be available. A host that has stopped the use of a name may
- attempt uniqueness verification again after the expiration of the TTL
- of the conflicting response.
-
-4.3. Considerations for Multiple Interfaces
-
- A multi-homed host may elect to configure LLMNR on only one of its
- active interfaces. In many situations this will be adequate.
- However, should a host need to configure LLMNR on more than one of
- its active interfaces, there are some additional precautions it MUST
- take. Implementers who are not planning to support LLMNR on multiple
- interfaces simultaneously may skip this section.
-
- Where a host is configured to issue LLMNR queries on more than one
- interface, each interface maintains its own independent LLMNR
- resolver cache, containing the responses to LLMNR queries.
-
- A multi-homed host checks the uniqueness of UNIQUE records as
- described in Section 4. The situation is illustrated in figure 1.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
- In this situation, the multi-homed myhost will probe for, and defend,
- its host name on both interfaces. A conflict will be detected on one
- interface, but not the other. The multi-homed myhost will not be
- able to respond with a host RR for "myhost" on the interface on the
- right (see Figure 1). The multi-homed host may, however, be
- configured to use the "myhost" name on the interface on the left.
-
- Since names are only unique per-link, hosts on different links could
- be using the same name. If an LLMNR client sends requests over
- multiple interfaces, and receives replies from more than one, the
- result returned to the client is defined by the implementation. The
- situation is illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
- If host myhost is configured to use LLMNR on both interfaces, it will
- send LLMNR queries on both interfaces. When host myhost sends a
- query for the host RR for name "A" it will receive a response from
- hosts on both interfaces.
-
- Host myhost cannot distinguish between the situation shown in Figure
- 2, and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
- This illustrates that the proposed name conflict resolution mechanism
- does not support detection or resolution of conflicts between hosts
- on different links. This problem can also occur with DNS when a
- multi-homed host is connected to two different networks with
- separated name spaces. It is not the intent of this document to
- address the issue of uniqueness of names within DNS.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-4.4. API Issues
-
- [RFC2553] provides an API which can partially solve the name
- ambiguity problem for applications written to use this API, since the
- sockaddr_in6 structure exposes the scope within which each scoped
- address exists, and this structure can be used for both IPv4 (using
- v4-mapped IPv6 addresses) and IPv6 addresses.
-
- Following the example in Figure 2, an application on 'myhost' issues
- the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
- ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
- interfaces and the resolver library will return a list containing
- multiple addrinfo structures, each with an associated sockaddr_in6
- structure. This list will thus contain the IPv4 and IPv6 addresses
- of both hosts responding to the name 'A'. Link-local addresses will
- have a sin6_scope_id value that disambiguates which interface is used
- to reach the address. Of course, to the application, Figures 2 and 3
- are still indistinguishable, but this API allows the application to
- communicate successfully with any address in the list.
-
-5. Security Considerations
-
- LLMNR is a peer-to-peer name resolution protocol designed for use on
- the local link. While LLMNR limits the vulnerability of responders
- to off-link senders, it is possible for an off-link responder to
- reach a sender.
-
- In scenarios such as public "hotspots" attackers can be present on
- the same link. These threats are most serious in wireless networks
- such as 802.11, since attackers on a wired network will require
- physical access to the network, while wireless attackers may mount
- attacks from a distance. Link-layer security such as [IEEE-802.11i]
- can be of assistance against these threats if it is available.
-
- This section details security measures available to mitigate threats
- from on and off-link attackers.
-
-5.1. Denial of Service
-
- Attackers may take advantage of LLMNR conflict detection by
- allocating the same name, denying service to other LLMNR responders
- and possibly allowing an attacker to receive packets destined for
- other hosts. By logging conflicts, LLMNR responders can provide
- forensic evidence of these attacks.
-
- An attacker may spoof LLMNR queries from a victim's address in order
- to mount a denial of service attack. Responders setting the IPv6 Hop
- Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- response may be able to reach the victim across the Internet.
-
- While LLMNR responders only respond to queries for which they are
- authoritative and LLMNR does not provide wildcard query support, an
- LLMNR response may be larger than the query, and an attacker can
- generate multiple responses to a query for a name used by multiple
- responders. A sender may protect itself against unsolicited
- responses by silently discarding them as rapidly as possible.
-
-5.2. Spoofing
-
- LLMNR is designed to prevent reception of queries sent by an off-link
- attacker. LLMNR requires that responders receiving UDP queries check
- that they are sent to a link-scope multicast address. However, it is
- possible that some routers may not properly implement link-scope
- multicast, or that link-scope multicast addresses may leak into the
- multicast routing system. To prevent successful setup of TCP
- connections by an off-link sender, responders receiving a TCP SYN
- reply with a TCP SYN-ACK with TTL set to one (1).
-
- While it is difficult for an off-link attacker to send an LLMNR query
- to a responder, it is possible for an off-link attacker to spoof a
- response to a query (such as an A or AAAA query for a popular
- Internet host), and by using a TTL or Hop Limit field larger than one
- (1), for the forged response to reach the LLMNR sender. Since the
- forged response will only be accepted if it contains a matching ID
- field, choosing a pseudo-random ID field within queries provides some
- protection against off-link responders.
-
- Since LLMNR queries can be sent when DNS server(s) do not respond, an
- attacker can execute a denial of service attack on the DNS server(s)
- and then poison the LLMNR cache by responding to an LLMNR query with
- incorrect information. As noted in "Threat Analysis of the Domain
- Name System (DNS)" [RFC3833] these threats also exist with DNS, since
- DNS response spoofing tools are available that can allow an attacker
- to respond to a query more quickly than a distant DNS server.
- However, while switched networks or link layer security may make it
- difficult for an on-link attacker to snoop unicast DNS queries,
- multicast LLMNR queries are propagated to all hosts on the link,
- making it possible for an on-link attacker to spoof LLMNR responses
- without having to guess the value of the ID field in the query.
-
- Since LLMNR queries are sent and responded to on the local-link, an
- attacker will need to respond more quickly to provide its own
- response prior to arrival of the response from a legitimate
- responder. If an LLMNR query is sent for an off-link host, spoofing
- a response in a timely way is not difficult, since a legitimate
- response will never be received.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- This vulnerability can be reduced by limiting use of LLMNR to
- resolution of single-label names as described in Section 3, or by
- implementation of authentication (see Section 5.3).
-
-5.3. Authentication
-
- LLMNR is a peer-to-peer name resolution protocol, and as a result,
- it is often deployed in situations where no trust model can be
- assumed. Where a pre-arranged security configuration is possible,
- the following security mechanisms may be used:
-
-[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
- [RFC2931] security mechanisms. "DNS Name Service based on Secure
- Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
- the use of TSIG to secure LLMNR, based on group keys. While group
- keys can be used to demonstrate membership in a group, they do not
- protect against forgery by an attacker that is a member of the
- group.
-
-[b] IPsec ESP with a null-transform MAY be used to authenticate unicast
- LLMNR queries and responses or LLMNR responses to multicast
- queries. In a small network without a certificate authority, this
- can be most easily accomplished through configuration of a group
- pre-shared key for trusted hosts. As with TSIG, this does not
- protect against forgery by an attacker with access to the group
- pre-shared key.
-
-[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to
- support DNSSEC, LLMNR implementations MAY be configured with trust
- anchors, or they MAY make use of keys obtained from DNS queries.
- Since LLMNR does not support "delegated trust" (CD or AD bits),
- LLMNR implementations cannot make use of DNSSEC unless they are
- DNSSEC-aware and support validation. Unlike approaches [a] or [b],
- DNSSEC permits a responder to demonstrate ownership of a name, not
- just membership within a trusted group. As a result, it enables
- protection against forgery.
-
-5.4. Cache and Port Separation
-
- In order to prevent responses to LLMNR queries from polluting the DNS
- cache, LLMNR implementations MUST use a distinct, isolated cache for
- LLMNR on each interface. The use of separate caches is most
- effective when LLMNR is used as a name resolution mechanism of last
- resort, since this minimizes the opportunities for poisoning the
- LLMNR cache, and decreases reliance on it.
-
- LLMNR operates on a separate port from DNS, reducing the likelihood
- that a DNS server will unintentionally respond to an LLMNR query.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- If LLMNR is given higher priority than DNS among the enabled name
- resolution mechanisms, a denial of service attack on the DNS server
- would not be necessary in order to poison the LLMNR cache, since
- LLMNR queries would be sent even when the DNS server is available.
- In addition, the LLMNR cache, once poisoned, would take precedence
- over the DNS cache, eliminating the benefits of cache separation. As
- a result, LLMNR SHOULD NOT be used as a primary name resolution
- mechanism.
-
-6. IANA Considerations
-
- LLMNR requires allocation of port 5355 for both TCP and UDP.
-
- LLMNR requires allocation of link-scope multicast IPv4 address
- 224.0.0.252, as well as link-scope multicast IPv6 address
- FF02:0:0:0:0:0:1:3.
-
- This specification creates two new name spaces: the LLMNR namespace
- and the reserved bits in the LLMNR header. The reserved bits in the
- LLMNR header are allocated by IETF Consensus, in accordance with BCP
- 26 [RFC2434].
-
- In order to to avoid creating any new administrative procedures,
- administration of the LLMNR namespace will piggyback on the
- administration of the DNS namespace.
-
- The rights to use a fully qualified domain name (FQDN) within LLMNR
- are obtained coincident with acquiring the rights to use that name
- within DNS. Those wishing to use a FQDN within LLMNR should first
- acquire the rights to use the corresponding FQDN within DNS. Using a
- FQDN within LLMNR without ownership of the corresponding name in DNS
- creates the possibility of conflict and therefore is discouraged.
-
- LLMNR responders may self-allocate a name within the single-label
- name space, first defined in [RFC1001]. Since single-label names are
- not unique, no registration process is required.
-
-7. Constants
-
- The following timing constants are used in this protocol; they are
- not intended to be user configurable.
-
- JITTER_INTERVAL 100 ms
- LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
- 100 ms (IEEE 802 media, including IEEE 802.11)
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-8. References
-
-8.1. Normative References
-
-[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS
- Service on a TCP/UDP Transport: Concepts and Methods", RFC
- 1001, March 1987.
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
-8.2. Informative References
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
- Caching", IEEE/ACM Transactions on Networking, Volume 10,
- Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- Internet draft (work in progress), draft-ietf-ipv6-dns-
- discovery-07.txt, October 2002.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 26]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[IEEE-802.11i]
- Institute of Electrical and Electronics Engineers, "Supplement
- to Standard for Telecommunications and Information Exchange
- Between Systems - LAN/MAN Specific Requirements - Part 11:
- Wireless LAN Medium Access Control (MAC) and Physical Layer
- (PHY) Specifications: Specification for Enhanced Security",
- IEEE 802.11i, July 2004.
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
- Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
- Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
- 2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 27]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirement", RFC 4033, March
- 2005.
-
-Acknowledgments
-
- This work builds upon original work done on multicast DNS by Bill
- Manning and Bill Woodcock. Bill Manning's work was funded under
- DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
- their contribution to the current specification. Constructive input
- has also been received from Mark Andrews, Rob Austein, Randy Bush,
- Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
- Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
- Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
- Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
- St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 706 6605
- EMail: bernarda@microsoft.com
-
- Dave Thaler
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 703 8835
- EMail: dthaler@microsoft.com
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 28]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-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 (2006). 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.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 29]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 30]
-
-
-
+++ /dev/null
-
-INTERNET-DRAFT DSA Information in the DNS
-OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
- DSA Keying and Signature Information in the DNS
- --- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- 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 becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- 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/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
- The standard method of encoding US Government Digital Signature
- Algorithm keying and signature information for use in the Domain Name
- System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DSA Keying Information..................................3
- 3. DSA Signature Information...............................4
- 4. Performance Considerations..............................4
- 5. Security Considerations.................................5
- 6. IANA Considerations.....................................5
- Copyright, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative References.....................................7
-
- Author's Address...........................................8
- Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additional work is underway which would
- require the storage of keying and signature information in the DNS.
-
- This document describes how to encode US Government Digital Signature
- Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
- US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
- When DSA public keys are stored in the DNS, the structure of the
- relevant part of the RDATA part of the RR being used is the fields
- listed below in the order given.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- Field Size
- ----- ----
- T 1 octet
- Q 20 octets
- P 64 + T*8 octets
- G 64 + T*8 octets
- Y 64 + T*8 octets
-
- As described in [FIPS 186-2] and [Schneier], T is a key size
- parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
- is greater than 8 is reserved and the remainder of the data may have
- a different format in that case.) Q is a prime number selected at
- key generation time such that 2**159 < Q < 2**160. Thus Q is always
- 20 octets long and, as with all other fields, is stored in "big-
- endian" network order. P, G, and Y are calculated as directed by the
- [FIPS 186-2] key generation algorithm [Schneier]. P is in the range
- 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
- and Y are quantities modulo P and so can be up to the same length as
- P and are allocated fixed size fields with the same number of octets
- as P.
-
- During the key generation process, a random number X must be
- generated such that 1 <= X <= Q-1. X is the private key and is used
- in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
- The portion of the RDATA area used for US Digital Signature Algorithm
- signature information is shown below with fields in the order they
- are listed and the contents of each multi-octet field in "big-endian"
- network order.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- First, the data signed must be determined. Then the following steps
- are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
- specified in the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate a random K such that 0 < K < Q.
-
- R = ( G**K mod P ) mod Q
-
- S = ( K**(-1) * (hash + X*R) ) mod Q
-
- For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
- 3174].
-
- Since Q is 160 bits long, R and S can not be larger than 20 octets,
- which is the space allocated.
-
- T is copied from the public key. It is not logically necessary in
- the SIG but is present so that values of T > 8 can more conveniently
- be used as an escape for extended versions of DSA or other algorithms
- as later standardized.
-
-
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA [RFC
- 3110] and DSA. With sufficient pre-computation, signature generation
- with DSA is faster than RSA. Key generation is also faster for DSA.
- However, signature verification is an order of magnitude slower than
- RSA when the RSA public exponent is chosen to be small, as is
- recommended for some applications.
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying and/or signature
- inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
- current DSA standard may limit the security of DSA. For particular
- applications, implementors are encouraged to consider the range of
- available algorithms and key sizes.
-
- DSA assumes the ability to frequently generate high quality random
- numbers. See [random] for guidance. DSA is designed so that if
- biased rather than random numbers are used, high bandwidth covert
- channels are possible. See [Schneier] and more recent research. The
- leakage of an entire DSA private key in only two DSA signatures has
- been demonstrated. DSA provides security only if trusted
- implementations, including trusted random number generation, are
- used.
-
-
-
-6. IANA Considerations
-
- Allocation of meaning to values of the T parameter that are not
- defined herein (i.e., > 8 ) requires an IETF standards actions. It
- is intended that values unallocated herein be used to cover future
- extensions of the DSS standard.
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). 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.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- 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.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Normative References
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, 27 January 2000.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative References
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, 11/01/1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, 11/01/1987.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS)", D. Eastlake 3rd. May 2001.
-
- [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
- Jones, September 2001.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [Schneier] - "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C" (second edition), Bruce Schneier,
- 1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Labortories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554(w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2006.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
-
-
- Storage of Diffie-Hellman Keying Information in the DNS
- ------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
-
-
-
-Status of This Document
-
- 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 becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- 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/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for encoding Diffie-Hellman keys in the Domain
- Name System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
- Part of the format for Diffie-Hellman keys and the description
- thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
- and Hemma Prafullchandra. In addition, the following persons
- provided useful comments that were incorporated into the predecessor
- of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 1.1 About This Document....................................3
- 1.2 About Diffie-Hellman...................................3
- 2. Encoding Diffie-Hellman Keying Information..............4
- 3. Performance Considerations..............................5
- 4. IANA Considerations.....................................5
- 5. Security Considerations.................................5
- Copyright, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative Refences.......................................7
-
- Author's Address...........................................8
- Expiration and File Name...................................8
-
- Appendix A: Well known prime/generator pairs...............9
- A.1. Well-Known Group 1: A 768 bit prime..................9
- A.2. Well-Known Group 2: A 1024 bit prime.................9
- A.3. Well-Known Group 3: A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- similar information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additonal work is underway which would use
- the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
- This document describes how to store Diffie-Hellman keys in the DNS.
- Familiarity with the Diffie-Hellman key exchange algorithm is assumed
- [Schneier, RFC 2631].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119.
-
-
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Thus Diffie-
- Hellman is inherently a key agreement algorithm. As a result, no
- format is defined for Diffie-Hellman "signature information". For
- example, assume that two parties have local secrets "i" and "j".
- Assume they each respectively calculate X and Y as follows:
-
- X = g**i ( mod p )
-
- Y = g**j ( mod p )
-
- They exchange these quantities and then each calculates a Z as
- follows:
-
- Zi = Y**i ( mod p )
-
- Zj = X**j ( mod p )
-
- Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
- secret between the two parties that an adversary who does not know i
- or j will not be able to learn from the exchanged messages (unless
- the adversary can derive i or j by performing a discrete logarithm
- mod p which is hard for strong p and g).
-
- The private key for each party is their secret i (or j). The public
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- key is the pair p and g, which is the same for both parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
- in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
- When Diffie-Hellman keys appear within the RDATA portion of a RR,
- they are encoded as shown below.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | KEY flags | protocol | algorithm=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | prime length (or flag) | prime (p) (or special) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / prime (p) (variable length) | generator length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | generator (g) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | public value length | public value (variable length)/
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / public value (g^i mod p) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Prime length is the length of the Diffie-Hellman prime (p) in bytes
- if it is 16 or greater. Prime contains the binary representation of
- the Diffie-Hellman prime with most significant byte first (i.e., in
- network order). If "prime length" field is 1 or 2, then the "prime"
- field is actually an unsigned index into a table of 65,536
- prime/generator pairs and the generator length SHOULD be zero. See
- Appedix A for defined table entries and Section 4 for information on
- allocating additional table entries. The meaning of a zero or 3
- through 15 value for "prime length" is reserved.
-
- Generator length is the length of the generator (g) in bytes.
- Generator is the binary representation of generator with most
- significant byte first. PublicValueLen is the Length of the Public
- Value (g**i (mod p)) in bytes. PublicValue is the binary
- representation of the DH public value with most significant byte
- first.
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient. But
- it is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying information consistent
- with adequate security.
-
-
-
-4. IANA Considerations
-
- Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
- an IETF consensus as defined in [RFC 2434].
-
- Well known prime/generator pairs number 0x0000 through 0x07FF can
- only be assigned by an IETF standards action. [RFC 2539], the
- Proposed Standard predecessor of this document, assigned 0x0001
- through 0x0002. This document additionally assigns 0x0003. Pairs
- number 0s0800 through 0xBFFF can be assigned based on RFC
- documentation. Pairs number 0xC000 through 0xFFFF are available for
- private use and are not centrally coordinated. Use of such private
- pairs outside of a closed environment may result in conflicts and/or
- security failures.
-
-
-
-5. Security Considerations
-
- Keying information retrieved from the DNS should not be trusted
- unless (1) it has been securely obtained from a secure resolver or
- independently verified by the user and (2) this secure resolver and
- secure obtainment or independent verification conform to security
- policies acceptable to the user. As with all cryptographic
- algorithms, evaluating the necessary strength of the key is important
- and dependent on security policy.
-
- In addition, the usual Diffie-Hellman key strength considerations
- apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
- SHOULD be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). 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.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- 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.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Normative References
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
- in RFCs", T. Narten, H. Alvestrand, October 1998.
-
- [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
- 1999.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative Refences
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, November 1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, November 1987.
-
- [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
- and Sons.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2006.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
- These numbers are copied from the IPSEC effort where the derivation
- of these values is more fully explained and additional information is
- available. Richard Schroeppel performed all the mathematical and
- computational work for this appendix.
-
-
-
-A.1. Well-Known Group 1: A 768 bit prime
-
- The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
- decimal value is
- 155251809230070893513091813125848175563133404943451431320235
- 119490296623994910210725866945387659164244291000768028886422
- 915080371891804634263272761303128298374438082089019628850917
- 0691316593175367469551763119843371637221007210577919
-
- Prime modulus: Length (32 bit words): 24, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2: A 1024 bit prime
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its decimal value is
- 179769313486231590770839156793787453197860296048756011706444
- 423684197180216158519368947833795864925541502180565485980503
- 646440548199239100050792877003355816639229553136239076508735
- 759914822574862575007425302077447712589550957937778424442426
- 617334727629299387668709205606050270810842907692932019128194
- 467627007
-
- Prime modulus: Length (32 bit words): 32, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
- FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3: A 1536 bit prime
-
- The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
- Its decimal value is
- 241031242692103258855207602219756607485695054850245994265411
- 694195810883168261222889009385826134161467322714147790401219
- 650364895705058263194273070680500922306273474534107340669624
- 601458936165977404102716924945320037872943417032584377865919
- 814376319377685986952408894019557734611984354530154704374720
- 774996976375008430892633929555996888245787241299381012913029
- 459299994792636526405928464720973038494721168143446471443848
- 8520940127459844288859336526896320919633919
-
- Prime modulus Length (32 bit words): 48, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
- C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
- 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
- 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S. Josefsson
-Request for Comments: 4398 March 2006
-Obsoletes: 2538
-Category: Standards Track
-
-
- Storing Certificates in the Domain Name System (DNS)
-
-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 (2006).
-
-Abstract
-
- Cryptographic public keys are frequently published, and their
- authenticity is demonstrated by certificates. A CERT resource record
- (RR) is defined so that such certificates and related certificate
- revocation lists can be stored in the Domain Name System (DNS).
-
- This document obsoletes RFC 2538.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 1]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
-Table of Contents
-
- 1. Introduction ....................................................3
- 2. The CERT Resource Record ........................................3
- 2.1. Certificate Type Values ....................................4
- 2.2. Text Representation of CERT RRs ............................6
- 2.3. X.509 OIDs .................................................6
- 3. Appropriate Owner Names for CERT RRs ............................7
- 3.1. Content-Based X.509 CERT RR Names ..........................8
- 3.2. Purpose-Based X.509 CERT RR Names ..........................9
- 3.3. Content-Based OpenPGP CERT RR Names ........................9
- 3.4. Purpose-Based OpenPGP CERT RR Names .......................10
- 3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
- 4. Performance Considerations .....................................11
- 5. Contributors ...................................................11
- 6. Acknowledgements ...............................................11
- 7. Security Considerations ........................................12
- 8. IANA Considerations ............................................12
- 9. Changes since RFC 2538 .........................................13
- 10. References ....................................................14
- 10.1. Normative References .....................................14
- 10.2. Informative References ...................................15
- Appendix A. Copying Conditions ...................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 2]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
-1. Introduction
-
- Public keys are frequently published in the form of a certificate,
- and their authenticity is commonly demonstrated by certificates and
- related certificate revocation lists (CRLs). A certificate is a
- binding, through a cryptographic digital signature, of a public key,
- a validity interval and/or conditions, and identity, authorization,
- or other information. A certificate revocation list is a list of
- certificates that are revoked, and of incidental information, all
- signed by the signer (issuer) of the revoked certificates. Examples
- are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
- certificates/revocations used by OpenPGP software.
-
- Section 2 specifies a CERT resource record (RR) for the storage of
- certificates in the Domain Name System [1] [2].
-
- Section 3 discusses appropriate owner names for CERT RRs.
-
- Sections 4, 7, and 8 cover performance, security, and IANA
- considerations, respectively.
-
- Section 9 explains the changes in this document compared to RFC 2538.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [3].
-
-2. The CERT Resource Record
-
- The CERT resource record (RR) has the structure given below. Its RR
- type code is 37.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | type | key tag |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | algorithm | /
- +---------------+ certificate or CRL /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
- The type field is the certificate type as defined in Section 2.1
- below.
-
- The key tag field is the 16-bit value computed for the key embedded
- in the certificate, using the RRSIG Key Tag algorithm described in
- Appendix B of [12]. This field is used as an efficiency measure to
-
-
-
-Josefsson Standards Track [Page 3]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
- pick which CERT RRs may be applicable to a particular key. The key
- tag can be calculated for the key in question, and then only CERT RRs
- with the same key tag need to be examined. Note that two different
- keys can have the same key tag. However, the key MUST be transformed
- to the format it would have as the public key portion of a DNSKEY RR
- before the key tag is computed. This is only possible if the key is
- applicable to an algorithm and complies to limits (such as key size)
- defined for DNS security. If it is not, the algorithm field MUST be
- zero and the tag field is meaningless and SHOULD be zero.
-
- The algorithm field has the same meaning as the algorithm field in
- DNSKEY and RRSIG RRs [12], except that a zero algorithm field
- indicates that the algorithm is unknown to a secure DNS, which may
- simply be the result of the algorithm not having been standardized
- for DNSSEC [11].
-
-2.1. Certificate Type Values
-
- The following values are defined or reserved:
-
- Value Mnemonic Certificate Type
- ----- -------- ----------------
- 0 Reserved
- 1 PKIX X.509 as per PKIX
- 2 SPKI SPKI certificate
- 3 PGP OpenPGP packet
- 4 IPKIX The URL of an X.509 data object
- 5 ISPKI The URL of an SPKI certificate
- 6 IPGP The fingerprint and URL of an OpenPGP packet
- 7 ACPKIX Attribute Certificate
- 8 IACPKIX The URL of an Attribute Certificate
- 9-252 Available for IANA assignment
- 253 URI URI private
- 254 OID OID private
- 255 Reserved
- 256-65279 Available for IANA assignment
- 65280-65534 Experimental
- 65535 Reserved
-
- These values represent the initial content of the IANA registry; see
- Section 8.
-
- The PKIX type is reserved to indicate an X.509 certificate conforming
- to the profile defined by the IETF PKIX working group [8]. The
- certificate section will start with a one-octet unsigned OID length
- and then an X.500 OID indicating the nature of the remainder of the
-
-
-
-
-
-Josefsson Standards Track [Page 4]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
- certificate section (see Section 2.3, below). (NOTE: X.509
- certificates do not include their X.500 directory-type-designating
- OID as a prefix.)
-
- The SPKI and ISPKI types are reserved to indicate the SPKI
- certificate format [15], for use when the SPKI documents are moved
- from experimental status. The format for these two CERT RR types
- will need to be specified later.
-
- The PGP type indicates an OpenPGP packet as described in [5] and its
- extensions and successors. This is used to transfer public key
- material and revocation signatures. The data is binary and MUST NOT
- be encoded into an ASCII armor. An implementation SHOULD process
- transferable public keys as described in Section 10.1 of [5], but it
- MAY handle additional OpenPGP packets.
-
- The ACPKIX type indicates an Attribute Certificate format [9].
-
- The IPKIX and IACPKIX types indicate a URL that will serve the
- content that would have been in the "certificate, CRL, or URL" field
- of the corresponding type (PKIX or ACPKIX, respectively).
-
- The IPGP type contains both an OpenPGP fingerprint for the key in
- question, as well as a URL. The certificate portion of the IPGP CERT
- RR is defined as a one-octet fingerprint length, followed by the
- OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is
- calculated as defined in RFC 2440 [5]. A zero-length fingerprint or
- a zero-length URL are legal, and indicate URL-only IPGP data or
- fingerprint-only IPGP data, respectively. A zero-length fingerprint
- and a zero-length URL are meaningless and invalid.
-
- The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
- These types MUST be used when the content is too large to fit in the
- CERT RR and MAY be used at the implementer's discretion. They SHOULD
- NOT be used where the DNS message is 512 octets or smaller and could
- thus be expected to fit a UDP packet.
-
- The URI private type indicates a certificate format defined by an
- absolute URI. The certificate portion of the CERT RR MUST begin with
- a null-terminated URI [10], and the data after the null is the
- private format certificate itself. The URI SHOULD be such that a
- retrieval from it will lead to documentation on the format of the
- certificate. Recognition of private certificate types need not be
- based on URI equality but can use various forms of pattern matching
- so that, for example, subtype or version information can also be
- encoded into the URI.
-
-
-
-
-
-Josefsson Standards Track [Page 5]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
- The OID private type indicates a private format certificate specified
- by an ISO OID prefix. The certificate section will start with a
- one-octet unsigned OID length and then a BER-encoded OID indicating
- the nature of the remainder of the certificate section. This can be
- an X.509 certificate format or some other format. X.509 certificates
- that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
- type, not the OID private type. Recognition of private certificate
- types need not be based on OID equality but can use various forms of
- pattern matching such as OID prefix.
-
-2.2. Text Representation of CERT RRs
-
- The RDATA portion of a CERT RR has the type field as an unsigned
- decimal integer or as a mnemonic symbol as listed in Section 2.1,
- above.
-
- The key tag field is represented as an unsigned decimal integer.
-
- The algorithm field is represented as an unsigned decimal integer or
- a mnemonic symbol as listed in [12].
-
- The certificate/CRL portion is represented in base 64 [16] and may be
- divided into any number of white-space-separated substrings, down to
- single base-64 digits, which are concatenated to obtain the full
- signature. These substrings can span lines using the standard
- parenthesis.
-
- Note that the certificate/CRL portion may have internal sub-fields,
- but these do not appear in the master file representation. For
- example, with type 254, there will be an OID size, an OID, and then
- the certificate/CRL proper. However, only a single logical base-64
- string will appear in the text representation.
-
-2.3. X.509 OIDs
-
- OIDs have been defined in connection with the X.500 directory for
- user certificates, certification authority certificates, revocations
- of certification authority, and revocations of user certificates.
- The following table lists the OIDs, their BER encoding, and their
- length-prefixed hex format for use in CERT RRs:
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 6]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
- id-at-userCertificate
- = { joint-iso-ccitt(2) ds(5) at(4) 36 }
- == 0x 03 55 04 24
- id-at-cACertificate
- = { joint-iso-ccitt(2) ds(5) at(4) 37 }
- == 0x 03 55 04 25
- id-at-authorityRevocationList
- = { joint-iso-ccitt(2) ds(5) at(4) 38 }
- == 0x 03 55 04 26
- id-at-certificateRevocationList
- = { joint-iso-ccitt(2) ds(5) at(4) 39 }
- == 0x 03 55 04 27
-
-3. Appropriate Owner Names for CERT RRs
-
- It is recommended that certificate CERT RRs be stored under a domain
- name related to their subject, i.e., the name of the entity intended
- to control the private key corresponding to the public key being
- certified. It is recommended that certificate revocation list CERT
- RRs be stored under a domain name related to their issuer.
-
- Following some of the guidelines below may result in DNS names with
- characters that require DNS quoting as per Section 5.1 of RFC 1035
- [2].
-
- The choice of name under which CERT RRs are stored is important to
- clients that perform CERT queries. In some situations, the clients
- may not know all information about the CERT RR object it wishes to
- retrieve. For example, a client may not know the subject name of an
- X.509 certificate, or the email address of the owner of an OpenPGP
- key. Further, the client might only know the hostname of a service
- that uses X.509 certificates or the Key ID of an OpenPGP key.
-
- Therefore, two owner name guidelines are defined: content-based owner
- names and purpose-based owner names. A content-based owner name is
- derived from the content of the CERT RR data; for example, the
- Subject field in an X.509 certificate or the User ID field in OpenPGP
- keys. A purpose-based owner name is a name that a client retrieving
- CERT RRs ought to know already; for example, the host name of an
- X.509 protected service or the Key ID of an OpenPGP key. The
- content-based and purpose-based owner name may be the same; for
- example, when a client looks up a key based on the From: address of
- an incoming email.
-
- Implementations SHOULD use the purpose-based owner name guidelines
- described in this document and MAY use CNAME RRs at content-based
- owner names (or other names), pointing to the purpose-based owner
- name.
-
-
-
-Josefsson Standards Track [Page 7]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
- Note that this section describes an application-based mapping from
- the name space used in a certificate to the name space used by DNS.
- The DNS does not infer any relationship amongst CERT resource records
- based on similarities or differences of the DNS owner name(s) of CERT
- resource records. For example, if multiple labels are used when
- mapping from a CERT identifier to a domain name, then care must be
- taken in understanding wildcard record synthesis.
-
-3.1. Content-Based X.509 CERT RR Names
-
- Some X.509 versions, such as the PKIX profile of X.509 [8], permit
- multiple names to be associated with subjects and issuers under
- "Subject Alternative Name" and "Issuer Alternative Name". For
- example, the PKIX profile has such Alternate Names with an ASN.1
- specification as follows:
-
- GeneralName ::= CHOICE {
- otherName [0] OtherName,
- rfc822Name [1] IA5String,
- dNSName [2] IA5String,
- x400Address [3] ORAddress,
- directoryName [4] Name,
- ediPartyName [5] EDIPartyName,
- uniformResourceIdentifier [6] IA5String,
- iPAddress [7] OCTET STRING,
- registeredID [8] OBJECT IDENTIFIER }
-
- The recommended locations of CERT storage are as follows, in priority
- order:
-
- 1. If a domain name is included in the identification in the
- certificate or CRL, that ought to be used.
- 2. If a domain name is not included but an IP address is included,
- then the translation of that IP address into the appropriate
- inverse domain name ought to be used.
- 3. If neither of the above is used, but a URI containing a domain
- name is present, that domain name ought to be used.
- 4. If none of the above is included but a character string name is
- included, then it ought to be treated as described below for
- OpenPGP names.
- 5. If none of the above apply, then the distinguished name (DN)
- ought to be mapped into a domain name as specified in [4].
-
- Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
- DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
- string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
- URI <https://www.secure.john-doe.com:8080/>. The storage locations
- recommended, in priority order, would be
-
-
-
-Josefsson Standards Track [Page 8]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
- 1. john-doe.com,
- 2. www.secure.john-doe.com, and
- 3. Doe.com.xy.
-
- Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
- L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
- domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
- (c) string "James Hacker <hacker@mail.widget.foo.example>". The
- storage locations recommended, in priority order, would be
-
- 1. widget.foo.example,
- 2. 201.13.251.10.in-addr.arpa, and
- 3. hacker.mail.widget.foo.example.
-
-3.2. Purpose-Based X.509 CERT RR Names
-
- Due to the difficulty for clients that do not already possess a
- certificate to reconstruct the content-based owner name,
- purpose-based owner names are recommended in this section.
- Recommendations for purpose-based owner names vary per scenario. The
- following table summarizes the purpose-based X.509 CERT RR owner name
- guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
-
- Scenario Owner name
- ------------------ ----------------------------------------------
- S/MIME Certificate Standard translation of an RFC 2822 email
- address. Example: An S/MIME certificate for
- "postmaster@example.org" will use a standard
- hostname translation of the owner name,
- "postmaster.example.org".
-
- TLS Certificate Hostname of the TLS server.
-
- IPsec Certificate Hostname of the IPsec machine and/or, for IPv4
- or IPv6 addresses, the fully qualified domain
- name in the appropriate reverse domain.
-
- An alternate approach for IPsec is to store raw public keys [18].
-
-3.3. Content-Based OpenPGP CERT RR Names
-
- OpenPGP signed keys (certificates) use a general character string
- User ID [5]. However, it is recommended by OpenPGP that such names
- include the RFC 2822 [7] email address of the party, as in "Leslie
- Example <Leslie@host.example>". If such a format is used, the CERT
- ought to be under the standard translation of the email address into
-
-
-
-
-
-Josefsson Standards Track [Page 9]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
- a domain name, which would be leslie.host.example in this case. If
- no RFC 2822 name can be extracted from the string name, no specific
- domain name is recommended.
-
- If a user has more than one email address, the CNAME type can be used
- to reduce the amount of data stored in the DNS. For example:
-
- $ORIGIN example.org.
- smith IN CERT PGP 0 0 <OpenPGP binary>
- john.smith IN CNAME smith
- js IN CNAME smith
-
-3.4. Purpose-Based OpenPGP CERT RR Names
-
- Applications that receive an OpenPGP packet containing encrypted or
- signed data but do not know the email address of the sender will have
- difficulties constructing the correct owner name and cannot use the
- content-based owner name guidelines. However, these clients commonly
- know the key fingerprint or the Key ID. The key ID is found in
- OpenPGP packets, and the key fingerprint is commonly found in
- auxiliary data that may be available. In this case, use of an owner
- name identical to the key fingerprint and the key ID expressed in
- hexadecimal [16] is recommended. For example:
-
- $ORIGIN example.org.
- 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
- F835EDA21E94B565716F IN CERT PGP ...
- B565716F IN CERT PGP ...
-
- If the same key material is stored for several owner names, the use
- of CNAME may help avoid data duplication. Note that CNAME is not
- always applicable, because it maps one owner name to the other for
- all purposes, which may be sub-optimal when two keys with the same
- Key ID are stored.
-
-3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
-
- These types are stored under the same owner names, both purpose- and
- content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 10]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
-4. Performance Considerations
-
- The Domain Name System (DNS) protocol was designed for small
- transfers, typically below 512 octets. While larger transfers will
- perform correctly and work is underway to make larger transfers more
- efficient, it is still advisable at this time that every reasonable
- effort be made to minimize the size of certificates stored within the
- DNS. Steps that can be taken may include using the fewest possible
- optional or extension fields and using short field values for
- necessary variable-length fields.
-
- The RDATA field in the DNS protocol may only hold data of size 65535
- octets (64kb) or less. This means that each CERT RR MUST NOT contain
- more than 64kb of payload, even if the corresponding certificate or
- certificate revocation list is larger. This document addresses this
- by defining "indirect" data types for each normal type.
-
- Deploying CERT RRs to support digitally signed email changes the
- access patterns of DNS lookups from per-domain to per-user. If
- digitally signed email and a key/certificate lookup based on CERT RRs
- are deployed on a wide scale, this may lead to an increased DNS load,
- with potential performance and cache effectiveness consequences.
- Whether or not this load increase will be noticeable is not known.
-
-5. Contributors
-
- The majority of this document is copied verbatim from RFC 2538, by
- Donald Eastlake 3rd and Olafur Gudmundsson.
-
-6. Acknowledgements
-
- Thanks to David Shaw and Michael Graff for their contributions to
- earlier works that motivated, and served as inspiration for, this
- document.
-
- This document was improved by suggestions and comments from Olivier
- Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
- Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
- Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
- Weiler, and Florian Weimer. No doubt the list is incomplete. We
- apologize to anyone we left out.
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 11]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
-7. Security Considerations
-
- By definition, certificates contain their own authenticating
- signatures. Thus, it is reasonable to store certificates in
- non-secure DNS zones or to retrieve certificates from DNS with DNS
- security checking not implemented or deferred for efficiency. The
- results may be trusted if the certificate chain is verified back to a
- known trusted key and this conforms with the user's security policy.
-
- Alternatively, if certificates are retrieved from a secure DNS zone
- with DNS security checking enabled and are verified by DNS security,
- the key within the retrieved certificate may be trusted without
- verifying the certificate chain if this conforms with the user's
- security policy.
-
- If an organization chooses to issue certificates for its employees,
- placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
- is in use, it is possible for someone to enumerate all employees of
- the organization. This is usually not considered desirable, for the
- same reason that enterprise phone listings are not often publicly
- published and are even marked confidential.
-
- Using the URI type introduces another level of indirection that may
- open a new vulnerability. One method of securing that indirection is
- to include a hash of the certificate in the URI itself.
-
- If DNSSEC is used, then the non-existence of a CERT RR and,
- consequently, certificates or revocation lists can be securely
- asserted. Without DNSSEC, this is not possible.
-
-8. IANA Considerations
-
- The IANA has created a new registry for CERT RR: certificate types.
- The initial contents of this registry is:
-
- Decimal Type Meaning Reference
- ------- ---- ------- ---------
- 0 Reserved RFC 4398
- 1 PKIX X.509 as per PKIX RFC 4398
- 2 SPKI SPKI certificate RFC 4398
- 3 PGP OpenPGP packet RFC 4398
- 4 IPKIX The URL of an X.509 data object RFC 4398
- 5 ISPKI The URL of an SPKI certificate RFC 4398
- 6 IPGP The fingerprint and URL RFC 4398
- of an OpenPGP packet
- 7 ACPKIX Attribute Certificate RFC 4398
- 8 IACPKIX The URL of an Attribute RFC 4398
- Certificate
-
-
-
-Josefsson Standards Track [Page 12]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
- 9-252 Available for IANA assignment
- by IETF Standards action
- 253 URI URI private RFC 4398
- 254 OID OID private RFC 4398
- 255 Reserved RFC 4398
- 256-65279 Available for IANA assignment
- by IETF Consensus
- 65280-65534 Experimental RFC 4398
- 65535 Reserved RFC 4398
-
- Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
- only be assigned by an IETF standards action [6]. This document
- assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate
- types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
- based on RFC documentation of the certificate type. The availability
- of private types under 0x00FD and 0x00FE ought to satisfy most
- requirements for proprietary or private types.
-
- The CERT RR reuses the DNS Security Algorithm Numbers registry. In
- particular, the CERT RR requires that algorithm number 0 remain
- reserved, as described in Section 2. The IANA will reference the
- CERT RR as a user of this registry and value 0, in particular.
-
-9. Changes since RFC 2538
-
- 1. Editorial changes to conform with new document requirements,
- including splitting reference section into two parts and
- updating the references to point at latest versions, and to add
- some additional references.
- 2. Improve terminology. For example replace "PGP" with "OpenPGP",
- to align with RFC 2440.
- 3. In Section 2.1, clarify that OpenPGP public key data are binary,
- not the ASCII armored format, and reference 10.1 in RFC 2440 on
- how to deal with OpenPGP keys, and acknowledge that
- implementations may handle additional packet types.
- 4. Clarify that integers in the representation format are decimal.
- 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
- terminology. Improve reference for Key Tag Algorithm
- calculations.
- 6. Add examples that suggest use of CNAME to reduce bandwidth.
- 7. In Section 3, appended the last paragraphs that discuss
- "content-based" vs "purpose-based" owner names. Add Section 3.2
- for purpose-based X.509 CERT owner names, and Section 3.4 for
- purpose-based OpenPGP CERT owner names.
- 8. Added size considerations.
- 9. The SPKI types has been reserved, until RFC 2692/2693 is moved
- from the experimental status.
- 10. Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
-
-
-
-Josefsson Standards Track [Page 13]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
- 11. An IANA registry of CERT type values was created.
-
-10. References
-
-10.1. 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., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
- "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
- January 1998.
-
- [5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
- "OpenPGP Message Format", RFC 2440, November 1998.
-
- [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
- [8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
- Public Key Infrastructure Certificate and Certificate
- Revocation List (CRL) Profile", RFC 3280, April 2002.
-
- [9] Farrell, S. and R. Housley, "An Internet Attribute Certificate
- Profile for Authorization", RFC 3281, April 2002.
-
- [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
- January 2005.
-
- [11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-
-
-Josefsson Standards Track [Page 14]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
-10.2. Informative References
-
- [13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
- RFC 2246, January 1999.
-
- [14] Kent, S. and K. Seo, "Security Architecture for the Internet
- Protocol", RFC 4301, December 2005.
-
- [15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
- and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
- September 1999.
-
- [16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
- RFC 3548, July 2003.
-
- [17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
- (S/MIME) Version 3.1 Message Specification", RFC 3851,
- July 2004.
-
- [18] Richardson, M., "A Method for Storing IPsec Keying Material in
- DNS", RFC 4025, March 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 15]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
-Appendix A. Copying Conditions
-
- Regarding the portion of this document that was written by Simon
- Josefsson ("the author", for the remainder of this section), the
- author makes no guarantees and is not responsible for any damage
- resulting from its use. The author grants irrevocable permission to
- anyone to use, modify, and distribute it in any way that does not
- diminish the rights of anyone else to use, modify, and distribute it,
- provided that redistributed derivative works do not contain
- misleading author or version information. Derivative works need not
- be licensed under similar terms.
-
-Author's Address
-
- Simon Josefsson
-
- EMail: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 16]
-\f
-RFC 4398 Storing Certificates in the DNS February 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- 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 provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 17]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group M. Wong
-Request for Comments: 4408 W. Schlitt
-Category: Experimental April 2006
-
-
- Sender Policy Framework (SPF) for
- Authorizing Use of Domains in E-Mail, Version 1
-
-Status of This Memo
-
- This memo defines an Experimental Protocol for the Internet
- community. It does not specify an Internet standard of any kind.
- Discussion and suggestions for improvement are requested.
- Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-IESG Note
-
- The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
- are published simultaneously as Experimental RFCs, although there is
- no general technical consensus and efforts to reconcile the two
- approaches have failed. As such, these documents have not received
- full IETF review and are published "AS-IS" to document the different
- approaches as they were considered in the MARID working group.
-
- The IESG takes no position about which approach is to be preferred
- and cautions the reader that there are serious open issues for each
- approach and concerns about using them in tandem. The IESG believes
- that documenting the different approaches does less harm than not
- documenting them.
-
- Note that the Sender ID experiment may use DNS records that may have
- been created for the current SPF experiment or earlier versions in
- this set of experiments. Depending on the content of the record,
- this may mean that Sender-ID heuristics would be applied incorrectly
- to a message. Depending on the actions associated by the recipient
- with those heuristics, the message may not be delivered or may be
- discarded on receipt.
-
- Participants relying on Sender ID experiment DNS records are warned
- that they may lose valid messages in this set of circumstances.
- aParticipants publishing SPF experiment DNS records should consider
- the advice given in section 3.4 of RFC 4406 and may wish to publish
- both v=spf1 and spf2.0 records to avoid the conflict.
-
-
-
-
-Wong & Schlitt Experimental [Page 1]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- Participants in the Sender-ID experiment need to be aware that the
- way Resent-* header fields are used will result in failure to receive
- legitimate email when interacting with standards-compliant systems
- (specifically automatic forwarders which comply with the standards by
- not adding Resent-* headers, and systems which comply with RFC 822
- but have not yet implemented RFC 2822 Resent-* semantics). It would
- be inappropriate to advance Sender-ID on the standards track without
- resolving this interoperability problem.
-
- The community is invited to observe the success or failure of the two
- approaches during the two years following publication, in order that
- a community consensus can be reached in the future.
-
-Abstract
-
- E-mail on the Internet can be forged in a number of ways. In
- particular, existing protocols place no restriction on what a sending
- host can use as the reverse-path of a message or the domain given on
- the SMTP HELO/EHLO commands. This document describes version 1 of
- the Sender Policy Framework (SPF) protocol, whereby a domain may
- explicitly authorize the hosts that are allowed to use its domain
- name, and a receiving host may check such authorization.
-
-Table of Contents
-
- 1. Introduction ....................................................4
- 1.1. Protocol Status ............................................4
- 1.2. Terminology ................................................5
- 2. Operation .......................................................5
- 2.1. The HELO Identity ..........................................5
- 2.2. The MAIL FROM Identity .....................................5
- 2.3. Publishing Authorization ...................................6
- 2.4. Checking Authorization .....................................6
- 2.5. Interpreting the Result ....................................7
- 2.5.1. None ................................................8
- 2.5.2. Neutral .............................................8
- 2.5.3. Pass ................................................8
- 2.5.4. Fail ................................................8
- 2.5.5. SoftFail ............................................9
- 2.5.6. TempError ...........................................9
- 2.5.7. PermError ...........................................9
- 3. SPF Records .....................................................9
- 3.1. Publishing ................................................10
- 3.1.1. DNS Resource Record Types ..........................10
- 3.1.2. Multiple DNS Records ...............................11
- 3.1.3. Multiple Strings in a Single DNS record ............11
- 3.1.4. Record Size ........................................11
- 3.1.5. Wildcard Records ...................................11
-
-
-
-Wong & Schlitt Experimental [Page 2]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- 4. The check_host() Function ......................................12
- 4.1. Arguments .................................................12
- 4.2. Results ...................................................13
- 4.3. Initial Processing ........................................13
- 4.4. Record Lookup .............................................13
- 4.5. Selecting Records .........................................13
- 4.6. Record Evaluation .........................................14
- 4.6.1. Term Evaluation ....................................14
- 4.6.2. Mechanisms .........................................15
- 4.6.3. Modifiers ..........................................15
- 4.7. Default Result ............................................16
- 4.8. Domain Specification ......................................16
- 5. Mechanism Definitions ..........................................16
- 5.1. "all" .....................................................17
- 5.2. "include" .................................................18
- 5.3. "a" .......................................................19
- 5.4. "mx" ......................................................20
- 5.5. "ptr" .....................................................20
- 5.6. "ip4" and "ip6" ...........................................21
- 5.7. "exists" ..................................................22
- 6. Modifier Definitions ...........................................22
- 6.1. redirect: Redirected Query ................................23
- 6.2. exp: Explanation ..........................................23
- 7. The Received-SPF Header Field ..................................25
- 8. Macros .........................................................27
- 8.1. Macro Definitions .........................................27
- 8.2. Expansion Examples ........................................30
- 9. Implications ...................................................31
- 9.1. Sending Domains ...........................................31
- 9.2. Mailing Lists .............................................32
- 9.3. Forwarding Services and Aliases ...........................32
- 9.4. Mail Services .............................................34
- 9.5. MTA Relays ................................................34
- 10. Security Considerations .......................................35
- 10.1. Processing Limits ........................................35
- 10.2. SPF-Authorized E-Mail May Contain Other False
- Identities ...............................................37
- 10.3. Spoofed DNS and IP Data ..................................37
- 10.4. Cross-User Forgery .......................................37
- 10.5. Untrusted Information Sources ............................38
- 10.6. Privacy Exposure .........................................38
- 11. Contributors and Acknowledgements .............................38
- 12. IANA Considerations ...........................................39
- 12.1. The SPF DNS Record Type ..................................39
- 12.2. The Received-SPF Mail Header Field .......................39
- 13. References ....................................................39
- 13.1. Normative References .....................................39
- 13.2. Informative References ...................................40
-
-
-
-Wong & Schlitt Experimental [Page 3]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- Appendix A. Collected ABNF .......................................42
- Appendix B. Extended Examples ....................................44
- B.1. Simple Examples ..........................................44
- B.2. Multiple Domain Example ..................................45
- B.3. DNSBL Style Example ......................................46
- B.4. Multiple Requirements Example ............................46
-
-1. Introduction
-
- The current E-Mail infrastructure has the property that any host
- injecting mail into the mail system can identify itself as any domain
- name it wants. Hosts can do this at a variety of levels: in
- particular, the session, the envelope, and the mail headers.
- Although this feature is desirable in some circumstances, it is a
- major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
- Furthermore, many domain name holders are understandably concerned
- about the ease with which other entities may make use of their domain
- names, often with malicious intent.
-
- This document defines a protocol by which domain owners may authorize
- hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
- Compliant domain holders publish Sender Policy Framework (SPF)
- records specifying which hosts are permitted to use their names, and
- compliant mail receivers use the published SPF records to test the
- authorization of sending Mail Transfer Agents (MTAs) using a given
- "HELO" or "MAIL FROM" identity during a mail transaction.
-
- An additional benefit to mail receivers is that after the use of an
- identity is verified, local policy decisions about the mail can be
- made based on the sender's domain, rather than the host's IP address.
- This is advantageous because reputation of domain names is likely to
- be more accurate than reputation of host IP addresses. Furthermore,
- if a claimed identity fails verification, local policy can take
- stronger action against such E-Mail, such as rejecting it.
-
-1.1. Protocol Status
-
- SPF has been in development since the summer of 2003 and has seen
- deployment beyond the developers beginning in December 2003. The
- design of SPF slowly evolved until the spring of 2004 and has since
- stabilized. There have been quite a number of forms of SPF, some
- written up as documents, some submitted as Internet Drafts, and many
- discussed and debated in development forums.
-
- The goal of this document is to clearly document the protocol defined
- by earlier draft specifications of SPF as used in existing
- implementations. This conception of SPF is sometimes called "SPF
- Classic". It is understood that particular implementations and
-
-
-
-Wong & Schlitt Experimental [Page 4]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- deployments may differ from, and build upon, this work. It is hoped
- that we have nonetheless captured the common understanding of SPF
- version 1.
-
-1.2. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- This document is concerned with the portion of a mail message
- commonly called "envelope sender", "return path", "reverse path",
- "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are
- either not well defined or often used casually, this document defines
- the "MAIL FROM" identity in Section 2.2. Note that other terms that
- may superficially look like the common terms, such as "reverse-path",
- are used only with the defined meanings from normative documents.
-
-2. Operation
-
-2.1. The HELO Identity
-
- The "HELO" identity derives from either the SMTP HELO or EHLO command
- (see [RFC2821]). These commands supply the SMTP client (sending
- host) for the SMTP session. Note that requirements for the domain
- presented in the EHLO or HELO command are not always clear to the
- sending party, and SPF clients must be prepared for the "HELO"
- identity to be malformed or an IP address literal. At the time of
- this writing, many legitimate E-Mails are delivered with invalid HELO
- domains.
-
- It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
- identity, but also separately check the "HELO" identity by applying
- the check_host() function (Section 4) to the "HELO" identity as the
- <sender>.
-
-2.2. The MAIL FROM Identity
-
- The "MAIL FROM" identity derives from the SMTP MAIL command (see
- [RFC2821]). This command supplies the "reverse-path" for a message,
- which generally consists of the sender mailbox, and is the mailbox to
- which notification messages are to be sent if there are problems
- delivering the message.
-
- [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
- RFC 2821). In this case, there is no explicit sender mailbox, and
- such a message can be assumed to be a notification message from the
- mail system itself. When the reverse-path is null, this document
-
-
-
-Wong & Schlitt Experimental [Page 5]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- defines the "MAIL FROM" identity to be the mailbox composed of the
- localpart "postmaster" and the "HELO" identity (which may or may not
- have been checked separately before).
-
- SPF clients MUST check the "MAIL FROM" identity. SPF clients check
- the "MAIL FROM" identity by applying the check_host() function to the
- "MAIL FROM" identity as the <sender>.
-
-2.3. Publishing Authorization
-
- An SPF-compliant domain MUST publish a valid SPF record as described
- in Section 3. This record authorizes the use of the domain name in
- the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
-
- If domain owners choose to publish SPF records, it is RECOMMENDED
- that they end in "-all", or redirect to other records that do, so
- that a definitive determination of authorization can be made.
-
- Domain holders may publish SPF records that explicitly authorize no
- hosts if mail should never originate using that domain.
-
- When changing SPF records, care must be taken to ensure that there is
- a transition period so that the old policy remains valid until all
- legitimate E-Mail has been checked.
-
-2.4. Checking Authorization
-
- A mail receiver can perform a set of SPF checks for each mail message
- it receives. An SPF check tests the authorization of a client host
- to emit mail with a given identity. Typically, such checks are done
- by a receiving MTA, but can be performed elsewhere in the mail
- processing chain so long as the required information is available and
- reliable. At least the "MAIL FROM" identity MUST be checked, but it
- is RECOMMENDED that the "HELO" identity also be checked beforehand.
-
- Without explicit approval of the domain owner, checking other
- identities against SPF version 1 records is NOT RECOMMENDED because
- there are cases that are known to give incorrect results. For
- example, almost all mailing lists rewrite the "MAIL FROM" identity
- (see Section 9.2), but some do not change any other identities in the
- message. The scenario described in Section 9.3, sub-section 1.2, is
- another example. Documents that define other identities should
- define the method for explicit approval.
-
- It is possible that mail receivers will use the SPF check as part of
- a larger set of tests on incoming mail. The results of other tests
- may influence whether or not a particular SPF check is performed.
- For example, finding the sending host's IP address on a local white
-
-
-
-Wong & Schlitt Experimental [Page 6]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- list may cause all other tests to be skipped and all mail from that
- host to be accepted.
-
- When a mail receiver decides to perform an SPF check, it MUST use a
- correctly-implemented check_host() function (Section 4) evaluated
- with the correct parameters. Although the test as a whole is
- optional, once it has been decided to perform a test it must be
- performed as specified so that the correct semantics are preserved
- between publisher and receiver.
-
- To make the test, the mail receiver MUST evaluate the check_host()
- function with the arguments set as follows:
-
- <ip> - the IP address of the SMTP client that is emitting the
- mail, either IPv4 or IPv6.
-
- <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
-
- <sender> - the "MAIL FROM" or "HELO" identity.
-
- Note that the <domain> argument may not be a well-formed domain name.
- For example, if the reverse-path was null, then the EHLO/HELO domain
- is used, with its associated problems (see Section 2.1). In these
- cases, check_host() is defined in Section 4.3 to return a "None"
- result.
-
- Although invalid, malformed, or non-existent domains cause SPF checks
- to return "None" because no SPF record can be found, it has long been
- the policy of many MTAs to reject E-Mail from such domains,
- especially in the case of invalid "MAIL FROM". In order to prevent
- the circumvention of SPF records, rejecting E-Mail from invalid
- domains should be considered.
-
- Implementations must take care to correctly extract the <domain> from
- the data given with the SMTP MAIL FROM command as many MTAs will
- still accept such things as source routes (see [RFC2821], Appendix
- C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
- These archaic features have been maliciously used to bypass security
- systems.
-
-2.5. Interpreting the Result
-
- This section describes how software that performs the authorization
- should interpret the results of the check_host() function. The
- authorization check SHOULD be performed during the processing of the
- SMTP transaction that sends the mail. This allows errors to be
- returned directly to the sending MTA by way of SMTP replies.
-
-
-
-
-Wong & Schlitt Experimental [Page 7]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- Performing the authorization after the SMTP transaction has finished
- may cause problems, such as the following: (1) It may be difficult to
- accurately extract the required information from potentially
- deceptive headers; (2) legitimate E-Mail may fail because the
- sender's policy may have since changed.
-
- Generating non-delivery notifications to forged identities that have
- failed the authorization check is generally abusive and against the
- explicit wishes of the identity owner.
-
-2.5.1. None
-
- A result of "None" means that no records were published by the domain
- or that no checkable sender domain could be determined from the given
- identity. The checking software cannot ascertain whether or not the
- client host is authorized.
-
-2.5.2. Neutral
-
- The domain owner has explicitly stated that he cannot or does not
- want to assert whether or not the IP address is authorized. A
- "Neutral" result MUST be treated exactly like the "None" result; the
- distinction exists only for informational purposes. Treating
- "Neutral" more harshly than "None" would discourage domain owners
- from testing the use of SPF records (see Section 9.1).
-
-2.5.3. Pass
-
- A "Pass" result means that the client is authorized to inject mail
- with the given identity. The domain can now, in the sense of
- reputation, be considered responsible for sending the message.
- Further policy checks can now proceed with confidence in the
- legitimate use of the identity.
-
-2.5.4. Fail
-
- A "Fail" result is an explicit statement that the client is not
- authorized to use the domain in the given identity. The checking
- software can choose to mark the mail based on this or to reject the
- mail outright.
-
- If the checking software chooses to reject the mail during the SMTP
- transaction, then it SHOULD use an SMTP reply code of 550 (see
- [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
- (DSN) code (see [RFC3464]), in addition to an appropriate reply text.
- The check_host() function may return either a default explanation
- string or one from the domain that published the SPF records (see
- Section 6.2). If the information does not originate with the
-
-
-
-Wong & Schlitt Experimental [Page 8]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- checking software, it should be made clear that the text is provided
- by the sender's domain. For example:
-
- 550-5.7.1 SPF MAIL FROM check failed:
- 550-5.7.1 The domain example.com explains:
- 550 5.7.1 Please see http://www.example.com/mailpolicy.html
-
-2.5.5. SoftFail
-
- A "SoftFail" result should be treated as somewhere between a "Fail"
- and a "Neutral". The domain believes the host is not authorized but
- is not willing to make that strong of a statement. Receiving
- software SHOULD NOT reject the message based solely on this result,
- but MAY subject the message to closer scrutiny than normal.
-
- The domain owner wants to discourage the use of this host and thus
- desires limited feedback when a "SoftFail" result occurs. For
- example, the recipient's Mail User Agent (MUA) could highlight the
- "SoftFail" status, or the receiving MTA could give the sender a
- message using a technique called "greylisting" whereby the MTA can
- issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
- first time the message is received, but accept it the second time.
-
-2.5.6. TempError
-
- A "TempError" result means that the SPF client encountered a
- transient error while performing the check. Checking software can
- choose to accept or temporarily reject the message. If the message
- is rejected during the SMTP transaction for this reason, the software
- SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
- code.
-
-2.5.7. PermError
-
- A "PermError" result means that the domain's published records could
- not be correctly interpreted. This signals an error condition that
- requires manual intervention to be resolved, as opposed to the
- TempError result. Be aware that if the domain owner uses macros
- (Section 8), it is possible that this result is due to the checked
- identities having an unexpected format.
-
-3. SPF Records
-
- An SPF record is a DNS Resource Record (RR) that declares which hosts
- are, and are not, authorized to use a domain name for the "HELO" and
- "MAIL FROM" identities. Loosely, the record partitions all hosts
- into permitted and not-permitted sets (though some hosts might fall
- into neither category).
-
-
-
-Wong & Schlitt Experimental [Page 9]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- The SPF record is a single string of text. An example record is the
- following:
-
- v=spf1 +mx a:colo.example.com/28 -all
-
- This record has a version of "spf1" and three directives: "+mx",
- "a:colo.example.com/28" (the + is implied), and "-all".
-
-3.1. Publishing
-
- Domain owners wishing to be SPF compliant must publish SPF records
- for the hosts that are used in the "MAIL FROM" and "HELO" identities.
- The SPF records are placed in the DNS tree at the host name it
- pertains to, not a subdomain under it, such as is done with SRV
- records. This is the same whether the TXT or SPF RR type (see
- Section 3.1.1) is used.
-
- The example above in Section 3 might be published via these lines in
- a domain zone file:
-
- example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
- smtp-out.example.com. TXT "v=spf1 a -all"
-
- When publishing via TXT records, beware of other TXT records
- published there for other purposes. They may cause problems with
- size limits (see Section 3.1.4).
-
-3.1.1. DNS Resource Record Types
-
- This document defines a new DNS RR of type SPF, code 99. The format
- of this type is identical to the TXT RR [RFC1035]. For either type,
- the character content of the record is encoded as [US-ASCII].
-
- It is recognized that the current practice (using a TXT record) is
- not optimal, but it is necessary because there are a number of DNS
- server and resolver implementations in common use that cannot handle
- the new RR type. The two-record-type scheme provides a forward path
- to the better solution of using an RR type reserved for this purpose.
-
- An SPF-compliant domain name SHOULD have SPF records of both RR
- types. A compliant domain name MUST have a record of at least one
- type. If a domain has records of both types, they MUST have
- identical content. For example, instead of publishing just one
- record as in Section 3.1 above, it is better to publish:
-
- example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
- example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
-
-
-
-
-Wong & Schlitt Experimental [Page 10]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- Example RRs in this document are shown with the TXT record type;
- however, they could be published with the SPF type or with both
- types.
-
-3.1.2. Multiple DNS Records
-
- A domain name MUST NOT have multiple records that would cause an
- authorization check to select more than one record. See Section 4.5
- for the selection rules.
-
-3.1.3. Multiple Strings in a Single DNS record
-
- As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
- record (either TXT or SPF RR types) can be composed of more than one
- string. If a published record contains multiple strings, then the
- record MUST be treated as if those strings are concatenated together
- without adding spaces. For example:
-
- IN TXT "v=spf1 .... first" "second string..."
-
- MUST be treated as equivalent to
-
- IN TXT "v=spf1 .... firstsecond string..."
-
- SPF or TXT records containing multiple strings are useful in
- constructing records that would exceed the 255-byte maximum length of
- a string within a single TXT or SPF RR record.
-
-3.1.4. Record Size
-
- The published SPF record for a given domain name SHOULD remain small
- enough that the results of a query for it will fit within 512 octets.
- This will keep even older DNS implementations from falling over to
- TCP. Since the answer size is dependent on many things outside the
- scope of this document, it is only possible to give this guideline:
- If the combined length of the DNS name and the text of all the
- records of a given type (TXT or SPF) is under 450 characters, then
- DNS answers should fit in UDP packets. Note that when computing the
- sizes for queries of the TXT format, one must take into account any
- other TXT records published at the domain name. Records that are too
- long to fit in a single UDP packet MAY be silently ignored by SPF
- clients.
-
-3.1.5. Wildcard Records
-
- Use of wildcard records for publishing is not recommended. Care must
- be taken if wildcard records are used. If a domain publishes
- wildcard MX records, it may want to publish wildcard declarations,
-
-
-
-Wong & Schlitt Experimental [Page 11]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- subject to the same requirements and problems. In particular, the
- declaration must be repeated for any host that has any RR records at
- all, and for subdomains thereof. For example, the example given in
- [RFC1034], Section 4.3.3, could be extended with the following:
-
- X.COM. MX 10 A.X.COM
- X.COM. TXT "v=spf1 a:A.X.COM -all"
-
- *.X.COM. MX 10 A.X.COM
- *.X.COM. TXT "v=spf1 a:A.X.COM -all"
-
- A.X.COM. A 1.2.3.4
- A.X.COM. MX 10 A.X.COM
- A.X.COM. TXT "v=spf1 a:A.X.COM -all"
-
- *.A.X.COM. MX 10 A.X.COM
- *.A.X.COM. TXT "v=spf1 a:A.X.COM -all"
-
- Notice that SPF records must be repeated twice for every name within
- the domain: once for the name, and once with a wildcard to cover the
- tree under the name.
-
- Use of wildcards is discouraged in general as they cause every name
- under the domain to exist and queries against arbitrary names will
- never return RCODE 3 (Name Error).
-
-4. The check_host() Function
-
- The check_host() function fetches SPF records, parses them, and
- interprets them to determine whether a particular host is or is not
- permitted to send mail with a given identity. Mail receivers that
- perform this check MUST correctly evaluate the check_host() function
- as described here.
-
- Implementations MAY use a different algorithm than the canonical
- algorithm defined here, so long as the results are the same in all
- cases.
-
-4.1. Arguments
-
- The check_host() function takes these arguments:
-
- <ip> - the IP address of the SMTP client that is emitting the
- mail, either IPv4 or IPv6.
-
- <domain> - the domain that provides the sought-after authorization
- information; initially, the domain portion of the "MAIL
- FROM" or "HELO" identity.
-
-
-
-Wong & Schlitt Experimental [Page 12]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- <sender> - the "MAIL FROM" or "HELO" identity.
-
- The domain portion of <sender> will usually be the same as the
- <domain> argument when check_host() is initially evaluated. However,
- this will generally not be true for recursive evaluations (see
- Section 5.2 below).
-
- Actual implementations of the check_host() function may need
- additional arguments.
-
-4.2. Results
-
- The function check_host() can return one of several results described
- in Section 2.5. Based on the result, the action to be taken is
- determined by the local policies of the receiver.
-
-4.3. Initial Processing
-
- If the <domain> is malformed (label longer than 63 characters, zero-
- length label not at the end, etc.) or is not a fully qualified domain
- name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
- check_host() immediately returns the result "None".
-
- If the <sender> has no localpart, substitute the string "postmaster"
- for the localpart.
-
-4.4. Record Lookup
-
- In accordance with how the records are published (see Section 3.1
- above), a DNS query needs to be made for the <domain> name, querying
- for either RR type TXT, SPF, or both. If both SPF and TXT RRs are
- looked up, the queries MAY be done in parallel.
-
- If all DNS lookups that are made return a server failure (RCODE 2),
- or other error (RCODE other than 0 or 3), or time out, then
- check_host() exits immediately with the result "TempError".
-
-4.5. Selecting Records
-
- Records begin with a version section:
-
- record = version terms *SP
- version = "v=spf1"
-
- Starting with the set of records that were returned by the lookup,
- record selection proceeds in two steps:
-
-
-
-
-
-Wong & Schlitt Experimental [Page 13]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- 1. Records that do not begin with a version section of exactly
- "v=spf1" are discarded. Note that the version section is
- terminated either by an SP character or the end of the record. A
- record with a version section of "v=spf10" does not match and must
- be discarded.
-
- 2. If any records of type SPF are in the set, then all records of
- type TXT are discarded.
-
- After the above steps, there should be exactly one record remaining
- and evaluation can proceed. If there are two or more records
- remaining, then check_host() exits immediately with the result of
- "PermError".
-
- If no matching records are returned, an SPF client MUST assume that
- the domain makes no SPF declarations. SPF processing MUST stop and
- return "None".
-
-4.6. Record Evaluation
-
- After one SPF record has been selected, the check_host() function
- parses and interprets it to find a result for the current test. If
- there are any syntax errors, check_host() returns immediately with
- the result "PermError".
-
- Implementations MAY choose to parse the entire record first and
- return "PermError" if the record is not syntactically well formed.
- However, in all cases, any syntax errors anywhere in the record MUST
- be detected.
-
-4.6.1. Term Evaluation
-
- There are two types of terms: mechanisms and modifiers. A record
- contains an ordered list of these as specified in the following
- Augmented Backus-Naur Form (ABNF).
-
- terms = *( 1*SP ( directive / modifier ) )
-
- directive = [ qualifier ] mechanism
- qualifier = "+" / "-" / "?" / "~"
- mechanism = ( all / include
- / A / MX / PTR / IP4 / IP6 / exists )
- modifier = redirect / explanation / unknown-modifier
- unknown-modifier = name "=" macro-string
-
- name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
-
- Most mechanisms allow a ":" or "/" character after the name.
-
-
-
-Wong & Schlitt Experimental [Page 14]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- Modifiers always contain an equals ('=') character immediately after
- the name, and before any ":" or "/" characters that may be part of
- the macro-string.
-
- Terms that do not contain any of "=", ":", or "/" are mechanisms, as
- defined in Section 5.
-
- As per the definition of the ABNF notation in [RFC4234], mechanism
- and modifier names are case-insensitive.
-
-4.6.2. Mechanisms
-
- Each mechanism is considered in turn from left to right. If there
- are no more mechanisms, the result is specified in Section 4.7.
-
- When a mechanism is evaluated, one of three things can happen: it can
- match, not match, or throw an exception.
-
- If it matches, processing ends and the qualifier value is returned as
- the result of that record. If it does not match, processing
- continues with the next mechanism. If it throws an exception,
- mechanism processing ends and the exception value is returned.
-
- The possible qualifiers, and the results they return are as follows:
-
- "+" Pass
- "-" Fail
- "~" SoftFail
- "?" Neutral
-
- The qualifier is optional and defaults to "+".
-
- When a mechanism matches and the qualifier is "-", then a "Fail"
- result is returned and the explanation string is computed as
- described in Section 6.2.
-
- The specific mechanisms are described in Section 5.
-
-4.6.3. Modifiers
-
- Modifiers are not mechanisms: they do not return match or not-match.
- Instead they provide additional information. Although modifiers do
- not directly affect the evaluation of the record, the "redirect"
- modifier has an effect after all the mechanisms have been evaluated.
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 15]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-4.7. Default Result
-
- If none of the mechanisms match and there is no "redirect" modifier,
- then the check_host() returns a result of "Neutral", just as if
- "?all" were specified as the last directive. If there is a
- "redirect" modifier, check_host() proceeds as defined in Section 6.1.
-
- Note that records SHOULD always use either a "redirect" modifier or
- an "all" mechanism to explicitly terminate processing.
-
- For example:
-
- v=spf1 +mx -all
- or
- v=spf1 +mx redirect=_spf.example.com
-
-4.8. Domain Specification
-
- Several of these mechanisms and modifiers have a <domain-spec>
- section. The <domain-spec> string is macro expanded (see Section 8).
- The resulting string is the common presentation form of a fully-
- qualified DNS name: a series of labels separated by periods. This
- domain is called the <target-name> in the rest of this document.
-
- Note: The result of the macro expansion is not subject to any further
- escaping. Hence, this facility cannot produce all characters that
- are legal in a DNS label (e.g., the control characters). However,
- this facility is powerful enough to express legal host names and
- common utility labels (such as "_spf") that are used in DNS.
-
- For several mechanisms, the <domain-spec> is optional. If it is not
- provided, the <domain> is used as the <target-name>.
-
-5. Mechanism Definitions
-
- This section defines two types of mechanisms.
-
- Basic mechanisms contribute to the language framework. They do not
- specify a particular type of authorization scheme.
-
- all
- include
-
- Designated sender mechanisms are used to designate a set of <ip>
- addresses as being permitted or not permitted to use the <domain> for
- sending mail.
-
-
-
-
-
-Wong & Schlitt Experimental [Page 16]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- a
- mx
- ptr
- ip4
- ip6
- exists
-
- The following conventions apply to all mechanisms that perform a
- comparison between <ip> and an IP address at any point:
-
- If no CIDR-length is given in the directive, then <ip> and the IP
- address are compared for equality. (Here, CIDR is Classless Inter-
- Domain Routing.)
-
- If a CIDR-length is specified, then only the specified number of
- high-order bits of <ip> and the IP address are compared for equality.
-
- When any mechanism fetches host addresses to compare with <ip>, when
- <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
- address, AAAA records are fetched. Even if the SMTP connection is
- via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
- 2.5.5) MUST still be considered an IPv4 address.
-
- Several mechanisms rely on information fetched from DNS. For these
- DNS queries, except where noted, if the DNS server returns an error
- (RCODE other than 0 or 3) or the query times out, the mechanism
- throws the exception "TempError". If the server returns "domain does
- not exist" (RCODE 3), then evaluation of the mechanism continues as
- if the server returned no error (RCODE 0) and zero answer records.
-
-5.1. "all"
-
- all = "all"
-
- The "all" mechanism is a test that always matches. It is used as the
- rightmost mechanism in a record to provide an explicit default.
-
- For example:
-
- v=spf1 a mx -all
-
- Mechanisms after "all" will never be tested. Any "redirect" modifier
- (Section 6.1) has no effect when there is an "all" mechanism.
-
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 17]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-5.2. "include"
-
- include = "include" ":" domain-spec
-
- The "include" mechanism triggers a recursive evaluation of
- check_host(). The domain-spec is expanded as per Section 8. Then
- check_host() is evaluated with the resulting string as the <domain>.
- The <ip> and <sender> arguments remain the same as in the current
- evaluation of check_host().
-
- In hindsight, the name "include" was poorly chosen. Only the
- evaluated result of the referenced SPF record is used, rather than
- acting as if the referenced SPF record was literally included in the
- first. For example, evaluating a "-all" directive in the referenced
- record does not terminate the overall processing and does not
- necessarily result in an overall "Fail". (Better names for this
- mechanism would have been "if-pass", "on-pass", etc.)
-
- The "include" mechanism makes it possible for one domain to designate
- multiple administratively-independent domains. For example, a vanity
- domain "example.net" might send mail using the servers of
- administratively-independent domains example.com and example.org.
-
- Example.net could say
-
- IN TXT "v=spf1 include:example.com include:example.org -all"
-
- This would direct check_host() to, in effect, check the records of
- example.com and example.org for a "Pass" result. Only if the host
- were not permitted for either of those domains would the result be
- "Fail".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 18]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- Whether this mechanism matches, does not match, or throws an
- exception depends on the result of the recursive evaluation of
- check_host():
-
- +---------------------------------+---------------------------------+
- | A recursive check_host() result | Causes the "include" mechanism |
- | of: | to: |
- +---------------------------------+---------------------------------+
- | Pass | match |
- | | |
- | Fail | not match |
- | | |
- | SoftFail | not match |
- | | |
- | Neutral | not match |
- | | |
- | TempError | throw TempError |
- | | |
- | PermError | throw PermError |
- | | |
- | None | throw PermError |
- +---------------------------------+---------------------------------+
-
- The "include" mechanism is intended for crossing administrative
- boundaries. Although it is possible to use includes to consolidate
- multiple domains that share the same set of designated hosts, domains
- are encouraged to use redirects where possible, and to minimize the
- number of includes within a single administrative domain. For
- example, if example.com and example.org were managed by the same
- entity, and if the permitted set of hosts for both domains was
- "mx:example.com", it would be possible for example.org to specify
- "include:example.com", but it would be preferable to specify
- "redirect=example.com" or even "mx:example.com".
-
-5.3. "a"
-
- This mechanism matches if <ip> is one of the <target-name>'s IP
- addresses.
-
- A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
-
- An address lookup is done on the <target-name>. The <ip> is compared
- to the returned address(es). If any address matches, the mechanism
- matches.
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 19]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-5.4. "mx"
-
- This mechanism matches if <ip> is one of the MX hosts for a domain
- name.
-
- MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
-
- check_host() first performs an MX lookup on the <target-name>. Then
- it performs an address lookup on each MX name returned. The <ip> is
- compared to each returned IP address. To prevent Denial of Service
- (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
- evaluation of an "mx" mechanism (see Section 10). If any address
- matches, the mechanism matches.
-
- Note regarding implicit MXs: If the <target-name> has no MX records,
- check_host() MUST NOT pretend the target is its single MX, and MUST
- NOT default to an A lookup on the <target-name> directly. This
- behavior breaks with the legacy "implicit MX" rule. See [RFC2821],
- Section 5. If such behavior is desired, the publisher should specify
- an "a" directive.
-
-5.5. "ptr"
-
- This mechanism tests whether the DNS reverse-mapping for <ip> exists
- and correctly points to a domain name within a particular domain.
-
- PTR = "ptr" [ ":" domain-spec ]
-
- First, the <ip>'s name is looked up using this procedure: perform a
- DNS reverse-mapping for <ip>, looking up the corresponding PTR record
- in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
- if it is an IPv6 address. For each record returned, validate the
- domain name by looking up its IP address. To prevent DoS attacks,
- more than 10 PTR names MUST NOT be looked up during the evaluation of
- a "ptr" mechanism (see Section 10). If <ip> is among the returned IP
- addresses, then that domain name is validated. In pseudocode:
-
- sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
- sending-domain_names are found, use at most 10. for each name in
- (sending-domain_names) {
- IP_addresses := a_lookup(name);
- if the sending-domain_IP is one of the IP_addresses {
- validated-sending-domain_names += name;
- } }
-
- Check all validated domain names to see if they end in the
- <target-name> domain. If any do, this mechanism matches. If no
- validated domain name can be found, or if none of the validated
-
-
-
-Wong & Schlitt Experimental [Page 20]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- domain names end in the <target-name>, this mechanism fails to match.
- If a DNS error occurs while doing the PTR RR lookup, then this
- mechanism fails to match. If a DNS error occurs while doing an A RR
- lookup, then that domain name is skipped and the search continues.
-
- Pseudocode:
-
- for each name in (validated-sending-domain_names) {
- if name ends in <domain-spec>, return match.
- if name is <domain-spec>, return match.
- }
- return no-match.
-
- This mechanism matches if the <target-name> is either an ancestor of
- a validated domain name or if the <target-name> and a validated
- domain name are the same. For example: "mail.example.com" is within
- the domain "example.com", but "mail.bad-example.com" is not.
-
- Note: Use of this mechanism is discouraged because it is slow, it is
- not as reliable as other mechanisms in cases of DNS errors, and it
- places a large burden on the arpa name servers. If used, proper PTR
- records must be in place for the domain's hosts and the "ptr"
- mechanism should be one of the last mechanisms checked.
-
-5.6. "ip4" and "ip6"
-
- These mechanisms test whether <ip> is contained within a given IP
- network.
-
- IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
- IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
-
- ip4-cidr-length = "/" 1*DIGIT
- ip6-cidr-length = "/" 1*DIGIT
- dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
-
- ip4-network = qnum "." qnum "." qnum "." qnum
- qnum = DIGIT ; 0-9
- / %x31-39 DIGIT ; 10-99
- / "1" 2DIGIT ; 100-199
- / "2" %x30-34 DIGIT ; 200-249
- / "25" %x30-35 ; 250-255
- ; as per conventional dotted quad notation. e.g., 192.0.2.0
- ip6-network = <as per [RFC 3513], section 2.2>
- ; e.g., 2001:DB8::CD30
-
- The <ip> is compared to the given network. If CIDR-length high-order
- bits match, the mechanism matches.
-
-
-
-Wong & Schlitt Experimental [Page 21]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- If ip4-cidr-length is omitted, it is taken to be "/32". If
- ip6-cidr-length is omitted, it is taken to be "/128". It is not
- permitted to omit parts of the IP address instead of using CIDR
- notations. That is, use 192.0.2.0/24 instead of 192.0.2.
-
-5.7. "exists"
-
- This mechanism is used to construct an arbitrary domain name that is
- used for a DNS A record query. It allows for complicated schemes
- involving arbitrary parts of the mail envelope to determine what is
- permitted.
-
- exists = "exists" ":" domain-spec
-
- The domain-spec is expanded as per Section 8. The resulting domain
- name is used for a DNS A RR lookup. If any A record is returned,
- this mechanism matches. The lookup type is A even when the
- connection type is IPv6.
-
- Domains can use this mechanism to specify arbitrarily complex
- queries. For example, suppose example.com publishes the record:
-
- v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
-
- The <target-name> might expand to
- "1.2.0.192.someuser._spf.example.com". This makes fine-grained
- decisions possible at the level of the user and client IP address.
-
- This mechanism enables queries that mimic the style of tests that
- existing anti-spam DNS blacklists (DNSBL) use.
-
-6. Modifier Definitions
-
- Modifiers are name/value pairs that provide additional information.
- Modifiers always have an "=" separating the name and the value.
-
- The modifiers defined in this document ("redirect" and "exp") MAY
- appear anywhere in the record, but SHOULD appear at the end, after
- all mechanisms. Ordering of these two modifiers does not matter.
- These two modifiers MUST NOT appear in a record more than once each.
- If they do, then check_host() exits with a result of "PermError".
-
- Unrecognized modifiers MUST be ignored no matter where in a record,
- or how often. This allows implementations of this document to
- gracefully handle records with modifiers that are defined in other
- specifications.
-
-
-
-
-
-Wong & Schlitt Experimental [Page 22]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-6.1. redirect: Redirected Query
-
- If all mechanisms fail to match, and a "redirect" modifier is
- present, then processing proceeds as follows:
-
- redirect = "redirect" "=" domain-spec
-
- The domain-spec portion of the redirect section is expanded as per
- the macro rules in Section 8. Then check_host() is evaluated with
- the resulting string as the <domain>. The <ip> and <sender>
- arguments remain the same as current evaluation of check_host().
-
- The result of this new evaluation of check_host() is then considered
- the result of the current evaluation with the exception that if no
- SPF record is found, or if the target-name is malformed, the result
- is a "PermError" rather than "None".
-
- Note that the newly-queried domain may itself specify redirect
- processing.
-
- This facility is intended for use by organizations that wish to apply
- the same record to multiple domains. For example:
-
- la.example.com. TXT "v=spf1 redirect=_spf.example.com"
- ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
- sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
- _spf.example.com. TXT "v=spf1 mx:example.com -all"
-
- In this example, mail from any of the three domains is described by
- the same record. This can be an administrative advantage.
-
- Note: In general, the domain "A" cannot reliably use a redirect to
- another domain "B" not under the same administrative control. Since
- the <sender> stays the same, there is no guarantee that the record at
- domain "B" will correctly work for mailboxes in domain "A",
- especially if domain "B" uses mechanisms involving localparts. An
- "include" directive may be more appropriate.
-
- For clarity, it is RECOMMENDED that any "redirect" modifier appear as
- the very last term in a record.
-
-6.2. exp: Explanation
-
- explanation = "exp" "=" domain-spec
-
- If check_host() results in a "Fail" due to a mechanism match (such as
- "-all"), and the "exp" modifier is present, then the explanation
- string returned is computed as described below. If no "exp" modifier
-
-
-
-Wong & Schlitt Experimental [Page 23]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- is present, then either a default explanation string or an empty
- explanation string may be returned.
-
- The <domain-spec> is macro expanded (see Section 8) and becomes the
- <target-name>. The DNS TXT record for the <target-name> is fetched.
-
- If <domain-spec> is empty, or there are any DNS processing errors
- (any RCODE other than 0), or if no records are returned, or if more
- than one record is returned, or if there are syntax errors in the
- explanation string, then proceed as if no exp modifier was given.
-
- The fetched TXT record's strings are concatenated with no spaces, and
- then treated as an <explain-string>, which is macro-expanded. This
- final result is the explanation string. Implementations MAY limit
- the length of the resulting explanation string to allow for other
- protocol constraints and/or reasonable processing limits. Since the
- explanation string is intended for an SMTP response and [RFC2821]
- Section 2.4 says that responses are in [US-ASCII], the explanation
- string is also limited to US-ASCII.
-
- Software evaluating check_host() can use this string to communicate
- information from the publishing domain in the form of a short message
- or URL. Software SHOULD make it clear that the explanation string
- comes from a third party. For example, it can prepend the macro
- string "%{o} explains: " to the explanation, such as shown in Section
- 2.5.4.
-
- Suppose example.com has this record:
-
- v=spf1 mx -all exp=explain._spf.%{d}
-
- Here are some examples of possible explanation TXT records at
- explain._spf.example.com:
-
- "Mail from example.com should only be sent by its own servers."
- -- a simple, constant message
-
- "%{i} is not one of %{d}'s designated mail servers."
- -- a message with a little more information, including the IP
- address that failed the check
-
- "See http://%{d}/why.html?s=%{S}&i=%{I}"
- -- a complicated example that constructs a URL with the
- arguments to check_host() so that a web page can be
- generated with detailed, custom instructions
-
- Note: During recursion into an "include" mechanism, an exp= modifier
- from the <target-name> MUST NOT be used. In contrast, when executing
-
-
-
-Wong & Schlitt Experimental [Page 24]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- a "redirect" modifier, an exp= modifier from the original domain MUST
- NOT be used.
-
-7. The Received-SPF Header Field
-
- It is RECOMMENDED that SMTP receivers record the result of SPF
- processing in the message header. If an SMTP receiver chooses to do
- so, it SHOULD use the "Received-SPF" header field defined here for
- each identity that was checked. This information is intended for the
- recipient. (Information intended for the sender is described in
- Section 6.2, Explanation.)
-
- The Received-SPF header field is a trace field (see [RFC2822] Section
- 3.6.7) and SHOULD be prepended to the existing header, above the
- Received: field that is generated by the SMTP receiver. It MUST
- appear above all other Received-SPF fields in the message. The
- header field has the following format:
-
- header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
- [ key-value-list ] CRLF
-
- result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
- "None" / "TempError" / "PermError"
-
- key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
- [";"]
-
- key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
-
- key = "client-ip" / "envelope-from" / "helo" /
- "problem" / "receiver" / "identity" /
- mechanism / "x-" name / name
-
- identity = "mailfrom" ; for the "MAIL FROM" identity
- / "helo" ; for the "HELO" identity
- / name ; other identities
-
- dot-atom = <unquoted word as per [RFC2822]>
- quoted-string = <quoted string as per [RFC2822]>
- comment = <comment string as per [RFC2822]>
- CFWS = <comment or folding white space as per [RFC2822]>
- FWS = <folding white space as per [RFC2822]>
- CRLF = <standard end-of-line token as per [RFC2822]>
-
- The header field SHOULD include a "(...)" style <comment> after the
- result, conveying supporting information for the result, such as
- <ip>, <sender>, and <domain>.
-
-
-
-
-Wong & Schlitt Experimental [Page 25]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- The following key-value pairs are designed for later machine parsing.
- SPF clients SHOULD give enough information so that the SPF results
- can be verified. That is, at least "client-ip", "helo", and, if the
- "MAIL FROM" identity was checked, "envelope-from".
-
- client-ip the IP address of the SMTP client
-
- envelope-from the envelope sender mailbox
-
- helo the host name given in the HELO or EHLO command
-
- mechanism the mechanism that matched (if no mechanisms matched,
- substitute the word "default")
-
- problem if an error was returned, details about the error
-
- receiver the host name of the SPF client
-
- identity the identity that was checked; see the <identity> ABNF
- rule
-
- Other keys may be defined by SPF clients. Until a new key name
- becomes widely accepted, new key names should start with "x-".
-
- SPF clients MUST make sure that the Received-SPF header field does
- not contain invalid characters, is not excessively long, and does not
- contain malicious data that has been provided by the sender.
-
- Examples of various header styles that could be generated are the
- following:
-
- Received-SPF: Pass (mybox.example.org: domain of
- myname@example.com designates 192.0.2.1 as permitted sender)
- receiver=mybox.example.org; client-ip=192.0.2.1;
- envelope-from=<myname@example.com>; helo=foo.example.com;
-
- Received-SPF: Fail (mybox.example.org: domain of
- myname@example.com does not designate
- 192.0.2.1 as permitted sender)
- identity=mailfrom; client-ip=192.0.2.1;
- envelope-from=<myname@example.com>;
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 26]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-8. Macros
-
-8.1. Macro Definitions
-
- Many mechanisms and modifiers perform macro expansion on part of the
- term.
-
- domain-spec = macro-string domain-end
- domain-end = ( "." toplabel [ "." ] ) / macro-expand
-
- toplabel = ( *alphanum ALPHA *alphanum ) /
- ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
- ; LDH rule plus additional TLD restrictions
- ; (see [RFC3696], Section 2)
- alphanum = ALPHA / DIGIT
-
- explain-string = *( macro-string / SP )
-
- macro-string = *( macro-expand / macro-literal )
- macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
- / "%%" / "%_" / "%-"
- macro-literal = %x21-24 / %x26-7E
- ; visible characters except "%"
- macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
- "c" / "r" / "t"
- transformers = *DIGIT [ "r" ]
- delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
-
- A literal "%" is expressed by "%%".
-
- "%_" expands to a single " " space.
- "%-" expands to a URL-encoded space, viz., "%20".
-
- The following macro letters are expanded in term arguments:
-
- s = <sender>
- l = local-part of <sender>
- o = domain of <sender>
- d = <domain>
- i = <ip>
- p = the validated domain name of <ip>
- v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
- h = HELO/EHLO domain
-
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 27]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- The following macro letters are allowed only in "exp" text:
-
- c = SMTP client IP (easily readable format)
- r = domain name of host performing the check
- t = current timestamp
-
- A '%' character not followed by a '{', '%', '-', or '_' character is
- a syntax error. So
-
- -exists:%(ir).sbl.spamhaus.example.org
-
- is incorrect and will cause check_host() to return a "PermError".
- Instead, say
-
- -exists:%{ir}.sbl.spamhaus.example.org
-
- Optional transformers are the following:
-
- *DIGIT = zero or more digits
- 'r' = reverse value, splitting on dots by default
-
- If transformers or delimiters are provided, the replacement value for
- a macro letter is split into parts. After performing any reversal
- operation and/or removal of left-hand parts, the parts are rejoined
- using "." and not the original splitting characters.
-
- By default, strings are split on "." (dots). Note that no special
- treatment is given to leading, trailing, or consecutive delimiters,
- and so the list of parts may contain empty strings. Older
- implementations of SPF prohibit trailing dots in domain names, so
- trailing dots should not be published by domain owners, although they
- must be accepted by implementations conforming to this document.
- Macros may specify delimiter characters that are used instead of ".".
-
- The 'r' transformer indicates a reversal operation: if the client IP
- address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"
- and the macro %{ir} would expand to "1.2.0.192".
-
- The DIGIT transformer indicates the number of right-hand parts to
- use, after optional reversal. If a DIGIT is specified, the value
- MUST be nonzero. If no DIGITs are specified, or if the value
- specifies more parts than are available, all the available parts are
- used. If the DIGIT was 5, and only 3 parts were available, the macro
- interpreter would pretend the DIGIT was 3. Implementations MUST
- support at least a value of 128, as that is the maximum number of
- labels in a domain name.
-
-
-
-
-
-Wong & Schlitt Experimental [Page 28]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- The "s" macro expands to the <sender> argument. It is an E-Mail
- address with a localpart, an "@" character, and a domain. The "l"
- macro expands to just the localpart. The "o" macro expands to just
- the domain part. Note that these values remain the same during
- recursive and chained evaluations due to "include" and/or "redirect".
- Note also that if the original <sender> had no localpart, the
- localpart was set to "postmaster" in initial processing (see Section
- 4.3).
-
- For IPv4 addresses, both the "i" and "c" macros expand to the
- standard dotted-quad format.
-
- For IPv6 addresses, the "i" macro expands to a dot-format address; it
- is intended for use in %{ir}. The "c" macro may expand to any of the
- hexadecimal colon-format addresses specified in [RFC3513], Section
- 2.2. It is intended for humans to read.
-
- The "p" macro expands to the validated domain name of <ip>. The
- procedure for finding the validated domain name is defined in Section
- 5.5. If the <domain> is present in the list of validated domains, it
- SHOULD be used. Otherwise, if a subdomain of the <domain> is
- present, it SHOULD be used. Otherwise, any name from the list may be
- used. If there are no validated domain names or if a DNS error
- occurs, the string "unknown" is used.
-
- The "r" macro expands to the name of the receiving MTA. This SHOULD
- be a fully qualified domain name, but if one does not exist (as when
- the checking is done by a MUA) or if policy restrictions dictate
- otherwise, the word "unknown" SHOULD be substituted. The domain name
- may be different from the name found in the MX record that the client
- MTA used to locate the receiving MTA.
-
- The "t" macro expands to the decimal representation of the
- approximate number of seconds since the Epoch (Midnight, January 1,
- 1970, UTC). This is the same value as is returned by the POSIX
- time() function in most standards-compliant libraries.
-
- When the result of macro expansion is used in a domain name query, if
- the expanded domain name exceeds 253 characters (the maximum length
- of a domain name), the left side is truncated to fit, by removing
- successive domain labels until the total length does not exceed 253
- characters.
-
- Uppercased macros expand exactly as their lowercased equivalents, and
- are then URL escaped. URL escaping must be performed for characters
- not in the "uric" set, which is defined in [RFC3986].
-
-
-
-
-
-Wong & Schlitt Experimental [Page 29]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- Note: Care must be taken so that macro expansion for legitimate
- E-Mail does not exceed the 63-character limit on DNS labels. The
- localpart of E-Mail addresses, in particular, can have more than 63
- characters between dots.
-
- Note: Domains should avoid using the "s", "l", "o", or "h" macros in
- conjunction with any mechanism directive. Although these macros are
- powerful and allow per-user records to be published, they severely
- limit the ability of implementations to cache results of check_host()
- and they reduce the effectiveness of DNS caches.
-
- Implementations should be aware that if no directive processed during
- the evaluation of check_host() contains an "s", "l", "o", or "h"
- macro, then the results of the evaluation can be cached on the basis
- of <domain> and <ip> alone for as long as the shortest Time To Live
- (TTL) of all the DNS records involved.
-
-8.2. Expansion Examples
-
- The <sender> is strong-bad@email.example.com.
- The IPv4 SMTP client IP is 192.0.2.3.
- The IPv6 SMTP client IP is 2001:DB8::CB01.
- The PTR domain name of the client IP is mx.example.org.
-
- macro expansion
- ------- ----------------------------
- %{s} strong-bad@email.example.com
- %{o} email.example.com
- %{d} email.example.com
- %{d4} email.example.com
- %{d3} email.example.com
- %{d2} example.com
- %{d1} com
- %{dr} com.example.email
- %{d2r} example.email
- %{l} strong-bad
- %{l-} strong.bad
- %{lr} strong-bad
- %{lr-} bad.strong
- %{l1r-} strong
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 30]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- macro-string expansion
- --------------------------------------------------------------------
- %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com
- %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com
-
- %{lr-}.lp.%{ir}.%{v}._spf.%{d2}
- bad.strong.lp.3.2.0.192.in-addr._spf.example.com
-
- %{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
- 3.2.0.192.in-addr.strong.lp._spf.example.com
-
- %{d2}.trusted-domains.example.net
- example.com.trusted-domains.example.net
-
- IPv6:
- %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0.
- 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
-
-9. Implications
-
- This section outlines the major implications that adoption of this
- document will have on various entities involved in Internet E-Mail.
- It is intended to make clear to the reader where this document
- knowingly affects the operation of such entities. This section is
- not a "how-to" manual, or a "best practices" document, and it is not
- a comprehensive list of what such entities should do in light of this
- document.
-
- This section is non-normative.
-
-9.1. Sending Domains
-
- Domains that wish to be compliant with this specification will need
- to determine the list of hosts that they allow to use their domain
- name in the "HELO" and "MAIL FROM" identities. It is recognized that
- forming such a list is not just a simple technical exercise, but
- involves policy decisions with both technical and administrative
- considerations.
-
- It can be helpful to publish records that include a "tracking
- exists:" mechanism. By looking at the name server logs, a rough list
- may then be generated. For example:
-
- v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 31]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-9.2. Mailing Lists
-
- Mailing lists must be aware of how they re-inject mail that is sent
- to the list. Mailing lists MUST comply with the requirements in
- [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that
- the reverse-path MUST be changed to be the mailbox of a person or
- other entity who administers the list. Whereas the reasons for
- changing the reverse-path are many and long-standing, SPF adds
- enforcement to this requirement.
-
- In practice, almost all mailing list software in use already complies
- with this requirement. Mailing lists that do not comply may or may
- not encounter problems depending on how access to the list is
- restricted. Such lists that are entirely internal to a domain (only
- people in the domain can send to or receive from the list) are not
- affected.
-
-9.3. Forwarding Services and Aliases
-
- Forwarding services take mail that is received at a mailbox and
- direct it to some external mailbox. At the time of this writing, the
- near-universal practice of such services is to use the original "MAIL
- FROM" of a message when re-injecting it for delivery to the external
- mailbox. [RFC1123] and [RFC2821] describe this action as an "alias"
- rather than a "mail list". This means that the external mailbox's
- MTA sees all such mail in a connection from a host of the forwarding
- service, and so the "MAIL FROM" identity will not, in general, pass
- authorization.
-
- There are three places that techniques can be used to ameliorate this
- problem.
-
- 1. The beginning, when E-Mail is first sent.
-
- 1. "Neutral" results could be given for IP addresses that may be
- forwarders, instead of "Fail" results. For example:
-
- "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
-
- This would cause a lookup on an anti-spam DNS blacklist
- (DNSBL) and cause a result of "Fail" only for E-Mail coming
- from listed sources. All other E-Mail, including E-Mail sent
- through forwarders, would receive a "Neutral" result. By
- checking the DNSBL after the known good sources, problems with
- incorrect listing on the DNSBL are greatly reduced.
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 32]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- 2. The "MAIL FROM" identity could have additional information in
- the localpart that cryptographically identifies the mail as
- coming from an authorized source. In this case, such an SPF
- record could be used:
-
- "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
-
- Then, a specialized DNS server can be set up to serve the
- _spf_verify subdomain that validates the localpart. Although
- this requires an extra DNS lookup, this happens only when the
- E-Mail would otherwise be rejected as not coming from a known
- good source.
-
- Note that due to the 63-character limit for domain labels,
- this approach only works reliably if the localpart signature
- scheme is guaranteed either to only produce localparts with a
- maximum of 63 characters or to gracefully handle truncated
- localparts.
-
- 3. Similarly, a specialized DNS server could be set up that will
- rate-limit the E-Mail coming from unexpected IP addresses.
-
- "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
-
- 4. SPF allows the creation of per-user policies for special
- cases. For example, the following SPF record and appropriate
- wildcard DNS records can be used:
-
- "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
-
- 2. The middle, when E-Mail is forwarded.
-
- 1. Forwarding services can solve the problem by rewriting the
- "MAIL FROM" to be in their own domain. This means that mail
- bounced from the external mailbox will have to be re-bounced
- by the forwarding service. Various schemes to do this exist
- though they vary widely in complexity and resource
- requirements on the part of the forwarding service.
-
- 2. Several popular MTAs can be forced from "alias" semantics to
- "mailing list" semantics by configuring an additional alias
- with "owner-" prepended to the original alias name (e.g., an
- alias of "friends: george@example.com, fred@example.org" would
- need another alias of the form "owner-friends: localowner").
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 33]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- 3. The end, when E-Mail is received.
-
- 1. If the owner of the external mailbox wishes to trust the
- forwarding service, he can direct the external mailbox's MTA
- to skip SPF tests when the client host belongs to the
- forwarding service.
-
- 2. Tests against other identities, such as the "HELO" identity,
- may be used to override a failed test against the "MAIL FROM"
- identity.
-
- 3. For larger domains, it may not be possible to have a complete
- or accurate list of forwarding services used by the owners of
- the domain's mailboxes. In such cases, whitelists of
- generally-recognized forwarding services could be employed.
-
-9.4. Mail Services
-
- Service providers that offer mail services to third-party domains,
- such as sending of bulk mail, may want to adjust their setup in light
- of the authorization check described in this document. If the "MAIL
- FROM" identity used for such E-Mail uses the domain of the service
- provider, then the provider needs only to ensure that its sending
- host is authorized by its own SPF record, if any.
-
- If the "MAIL FROM" identity does not use the mail service provider's
- domain, then extra care must be taken. The SPF record format has
- several options for the third-party domain to authorize the service
- provider's MTAs to send mail on its behalf. For mail service
- providers, such as ISPs, that have a wide variety of customers using
- the same MTA, steps should be taken to prevent cross-customer forgery
- (see Section 10.4).
-
-9.5. MTA Relays
-
- The authorization check generally precludes the use of arbitrary MTA
- relays between sender and receiver of an E-Mail message.
-
- Within an organization, MTA relays can be effectively deployed.
- However, for purposes of this document, such relays are effectively
- transparent. The SPF authorization check is a check between border
- MTAs of different domains.
-
- For mail senders, this means that published SPF records must
- authorize any MTAs that actually send across the Internet. Usually,
- these are just the border MTAs as internal MTAs simply forward mail
- to these MTAs for delivery.
-
-
-
-
-Wong & Schlitt Experimental [Page 34]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- Mail receivers will generally want to perform the authorization check
- at the border MTAs, specifically including all secondary MXs. This
- allows mail that fails to be rejected during the SMTP session rather
- than bounced. Internal MTAs then do not perform the authorization
- test. To perform the authorization test other than at the border,
- the host that first transferred the message to the organization must
- be determined, which can be difficult to extract from the message
- header. Testing other than at the border is not recommended.
-
-10. Security Considerations
-
-10.1. Processing Limits
-
- As with most aspects of E-Mail, there are a number of ways that
- malicious parties could use the protocol as an avenue for a
- Denial-of-Service (DoS) attack. The processing limits outlined here
- are designed to prevent attacks such as the following:
-
- o A malicious party could create an SPF record with many references
- to a victim's domain and send many E-Mails to different SPF
- clients; those SPF clients would then create a DoS attack. In
- effect, the SPF clients are being used to amplify the attacker's
- bandwidth by using fewer bytes in the SMTP session than are used
- by the DNS queries. Using SPF clients also allows the attacker to
- hide the true source of the attack.
-
- o Whereas implementations of check_host() are supposed to limit the
- number of DNS lookups, malicious domains could publish records
- that exceed these limits in an attempt to waste computation effort
- at their targets when they send them mail. Malicious domains
- could also design SPF records that cause particular
- implementations to use excessive memory or CPU usage, or to
- trigger bugs.
-
- o Malicious parties could send a large volume of mail purporting to
- come from the intended target to a wide variety of legitimate mail
- hosts. These legitimate machines would then present a DNS load on
- the target as they fetched the relevant records.
-
- Of these, the case of a third party referenced in the SPF record is
- the easiest for a DoS attack to effectively exploit. As a result,
- limits that may seem reasonable for an individual mail server can
- still allow an unreasonable amount of bandwidth amplification.
- Therefore, the processing limits need to be quite low.
-
- SPF implementations MUST limit the number of mechanisms and modifiers
- that do DNS lookups to at most 10 per SPF check, including any
- lookups caused by the use of the "include" mechanism or the
-
-
-
-Wong & Schlitt Experimental [Page 35]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- "redirect" modifier. If this number is exceeded during a check, a
- PermError MUST be returned. The "include", "a", "mx", "ptr", and
- "exists" mechanisms as well as the "redirect" modifier do count
- against this limit. The "all", "ip4", and "ip6" mechanisms do not
- require DNS lookups and therefore do not count against this limit.
- The "exp" modifier does not count against this limit because the DNS
- lookup to fetch the explanation string occurs after the SPF record
- has been evaluated.
-
- When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
- there MUST be a limit of no more than 10 MX or PTR RRs looked up and
- checked.
-
- SPF implementations SHOULD limit the total amount of data obtained
- from the DNS queries. For example, when DNS over TCP or EDNS0 are
- available, there may need to be an explicit limit to how much data
- will be accepted to prevent excessive bandwidth usage or memory usage
- and DoS attacks.
-
- MTAs or other processors MAY also impose a limit on the maximum
- amount of elapsed time to evaluate check_host(). Such a limit SHOULD
- allow at least 20 seconds. If such a limit is exceeded, the result
- of authorization SHOULD be "TempError".
-
- Domains publishing records SHOULD try to keep the number of "include"
- mechanisms and chained "redirect" modifiers to a minimum. Domains
- SHOULD also try to minimize the amount of other DNS information
- needed to evaluate a record. This can be done by choosing directives
- that require less DNS information and placing lower-cost mechanisms
- earlier in the SPF record.
-
- For example, consider a domain set up as follows:
-
- example.com. IN MX 10 mx.example.com.
- mx.example.com. IN A 192.0.2.1
- a.example.com. IN TXT "v=spf1 mx:example.com -all"
- b.example.com. IN TXT "v=spf1 a:mx.example.com -all"
- c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"
-
- Evaluating check_host() for the domain "a.example.com" requires the
- MX records for "example.com", and then the A records for the listed
- hosts. Evaluating for "b.example.com" requires only the A records.
- Evaluating for "c.example.com" requires none.
-
- However, there may be administrative considerations: using "a" over
- "ip4" allows hosts to be renumbered easily. Using "mx" over "a"
- allows the set of mail hosts to be changed easily.
-
-
-
-
-Wong & Schlitt Experimental [Page 36]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-10.2. SPF-Authorized E-Mail May Contain Other False Identities
-
- The "MAIL FROM" and "HELO" identity authorizations must not be
- construed to provide more assurance than they do. It is entirely
- possible for a malicious sender to inject a message using his own
- domain in the identities used by SPF, to have that domain's SPF
- record authorize the sending host, and yet the message can easily
- list other identities in its header. Unless the user or the MUA
- takes care to note that the authorized identity does not match the
- other more commonly-presented identities (such as the From: header
- field), the user may be lulled into a false sense of security.
-
-10.3. Spoofed DNS and IP Data
-
- There are two aspects of this protocol that malicious parties could
- exploit to undermine the validity of the check_host() function:
-
- o The evaluation of check_host() relies heavily on DNS. A malicious
- attacker could attack the DNS infrastructure and cause
- check_host() to see spoofed DNS data, and then return incorrect
- results. This could include returning "Pass" for an <ip> value
- where the actual domain's record would evaluate to "Fail". See
- [RFC3833] for a description of DNS weaknesses.
-
- o The client IP address, <ip>, is assumed to be correct. A
- malicious attacker could spoof TCP sequence numbers to make mail
- appear to come from a permitted host for a domain that the
- attacker is impersonating.
-
-10.4. Cross-User Forgery
-
- By definition, SPF policies just map domain names to sets of
- authorized MTAs, not whole E-Mail addresses to sets of authorized
- users. Although the "l" macro (Section 8) provides a limited way to
- define individual sets of authorized MTAs for specific E-Mail
- addresses, it is generally impossible to verify, through SPF, the use
- of specific E-Mail addresses by individual users of the same MTA.
-
- It is up to mail services and their MTAs to directly prevent
- cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be
- restricted to using only those E-Mail addresses that are actually
- under their control (see [RFC4409], Section 6.1). Another means to
- verify the identity of individual users is message cryptography such
- as PGP ([RFC2440]) or S/MIME ([RFC3851]).
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 37]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-10.5. Untrusted Information Sources
-
- SPF uses information supplied by third parties, such as the "HELO"
- domain name, the "MAIL FROM" address, and SPF records. This
- information is then passed to the receiver in the Received-SPF: trace
- fields and possibly returned to the client MTA in the form of an SMTP
- rejection message. This information must be checked for invalid
- characters and excessively long lines.
-
- When the authorization check fails, an explanation string may be
- included in the reject response. Both the sender and the rejecting
- receiver need to be aware that the explanation was determined by the
- publisher of the SPF record checked and, in general, not the
- receiver. The explanation may contain malicious URLs, or it may be
- offensive or misleading.
-
- This is probably less of a concern than it may initially seem since
- such messages are returned to the sender, and the explanation strings
- come from the sender policy published by the domain in the identity
- claimed by that very sender. As long as the DSN is not redirected to
- someone other than the actual sender, the only people who see
- malicious explanation strings are people whose messages claim to be
- from domains that publish such strings in their SPF records. In
- practice, DSNs can be misdirected, such as when an MTA accepts an
- E-Mail and then later generates a DSN to a forged address, or when an
- E-Mail forwarder does not direct the DSN back to the original sender.
-
-10.6. Privacy Exposure
-
- Checking SPF records causes DNS queries to be sent to the domain
- owner. These DNS queries, especially if they are caused by the
- "exists" mechanism, can contain information about who is sending
- E-Mail and likely to which MTA the E-Mail is being sent. This can
- introduce some privacy concerns, which may be more or less of an
- issue depending on local laws and the relationship between the domain
- owner and the person sending the E-Mail.
-
-11. Contributors and Acknowledgements
-
- This document is largely based on the work of Meng Weng Wong and Mark
- Lentczner. Although, as this section acknowledges, many people have
- contributed to this document, a very large portion of the writing and
- editing are due to Meng and Mark.
-
- This design owes a debt of parentage to [RMX] by Hadmut Danisch and
- to [DMP] by Gordon Fecyk. The idea of using a DNS record to check
- the legitimacy of an E-Mail address traces its ancestry further back
- through messages on the namedroppers mailing list by Paul Vixie
-
-
-
-Wong & Schlitt Experimental [Page 38]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- [Vixie] (based on suggestion by Jim Miller) and by David Green
- [Green].
-
- Philip Gladstone contributed the concept of macros to the
- specification, multiplying the expressiveness of the language and
- making per-user and per-IP lookups possible.
-
- The authors would also like to thank the literally hundreds of
- individuals who have participated in the development of this design.
- They are far too numerous to name, but they include the following:
-
- The folks on the spf-discuss mailing list.
- The folks on the SPAM-L mailing list.
- The folks on the IRTF ASRG mailing list.
- The folks on the IETF MARID mailing list.
- The folks on #perl.
-
-12. IANA Considerations
-
-12.1. The SPF DNS Record Type
-
- The IANA has assigned a new Resource Record Type and Qtype from the
- DNS Parameters Registry for the SPF RR type with code 99.
-
-12.2. The Received-SPF Mail Header Field
-
- Per [RFC3864], the "Received-SPF:" header field is added to the IANA
- Permanent Message Header Field Registry. The following is the
- registration template:
-
- Header field name: Received-SPF
- Applicable protocol: mail ([RFC2822])
- Status: Experimental
- Author/Change controller: IETF
- Specification document(s): RFC 4408
- Related information:
- Requesting SPF Council review of any proposed changes and
- additions to this field are recommended. For information about
- the SPF Council see http://www.openspf.org/Council
-
-13. References
-
-13.1. Normative References
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
-
-
-
-
-Wong & Schlitt Experimental [Page 39]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
- and Support", STD 3, RFC 1123, October 1989.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
- April 2001.
-
- [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
- 2001.
-
- [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
- for Delivery Status Notifications", RFC 3464, January
- 2003.
-
- [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
- (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
- [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
- Procedures for Message Header Fields", BCP 90, RFC 3864,
- September 2004.
-
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifier (URI): Generic Syntax", STD 66, RFC
- 3986, January 2005.
-
- [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 4234, October 2005.
-
- [US-ASCII] American National Standards Institute (formerly United
- States of America Standards Institute), "USA Code for
- Information Interchange, X3.4", 1968.
-
- ANSI X3.4-1968 has been replaced by newer versions with slight
- modifications, but the 1968 version remains definitive for
- the Internet.
-
-13.2 Informative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August
- 1996.
-
- [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
- "OpenPGP Message Format", RFC 2440, November 1998.
-
-
-
-Wong & Schlitt Experimental [Page 40]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- [RFC2554] Myers, J., "SMTP Service Extension for Authentication",
- RFC 2554, March 1999.
-
- [RFC3696] Klensin, J., "Application Techniques for Checking and
- Transformation of Names", RFC 3696, February 2004.
-
- [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
- Name System (DNS)", RFC 3833, August 2004.
-
- [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
- Extensions (S/MIME) Version 3.1 Message Specification",
- RFC 3851, July 2004.
-
- [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
- RFC 4409, April 2006.
-
- [RMX] Danish, H., "The RMX DNS RR Type for light weight sender
- authentication", Work In Progress
-
- [DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress
-
- [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002.
-
- [Green] Green, D., "Domain-Authorized SMTP Mail", 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 41]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-Appendix A. Collected ABNF
-
- This section is normative and any discrepancies with the ABNF
- fragments in the preceding text are to be resolved in favor of this
- grammar.
-
- See [RFC4234] for ABNF notation. Please note that as per this ABNF
- definition, literal text strings (those in quotes) are case-
- insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
-
- record = version terms *SP
- version = "v=spf1"
-
- terms = *( 1*SP ( directive / modifier ) )
-
- directive = [ qualifier ] mechanism
- qualifier = "+" / "-" / "?" / "~"
- mechanism = ( all / include
- / A / MX / PTR / IP4 / IP6 / exists )
-
- all = "all"
- include = "include" ":" domain-spec
- A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
- MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
- PTR = "ptr" [ ":" domain-spec ]
- IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
- IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
- exists = "exists" ":" domain-spec
-
- modifier = redirect / explanation / unknown-modifier
- redirect = "redirect" "=" domain-spec
- explanation = "exp" "=" domain-spec
- unknown-modifier = name "=" macro-string
-
- ip4-cidr-length = "/" 1*DIGIT
- ip6-cidr-length = "/" 1*DIGIT
- dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
-
- ip4-network = qnum "." qnum "." qnum "." qnum
- qnum = DIGIT ; 0-9
- / %x31-39 DIGIT ; 10-99
- / "1" 2DIGIT ; 100-199
- / "2" %x30-34 DIGIT ; 200-249
- / "25" %x30-35 ; 250-255
- ; conventional dotted quad notation. e.g., 192.0.2.0
- ip6-network = <as per [RFC 3513], section 2.2>
- ; e.g., 2001:DB8::CD30
-
-
-
-
-Wong & Schlitt Experimental [Page 42]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- domain-spec = macro-string domain-end
- domain-end = ( "." toplabel [ "." ] ) / macro-expand
- toplabel = ( *alphanum ALPHA *alphanum ) /
- ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
- ; LDH rule plus additional TLD restrictions
- ; (see [RFC3696], Section 2)
-
- alphanum = ALPHA / DIGIT
-
- explain-string = *( macro-string / SP )
-
- macro-string = *( macro-expand / macro-literal )
- macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
- / "%%" / "%_" / "%-"
- macro-literal = %x21-24 / %x26-7E
- ; visible characters except "%"
- macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
- "c" / "r" / "t"
- transformers = *DIGIT [ "r" ]
- delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
-
- name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
-
- header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
- [ key-value-list ] CRLF
-
- result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
- "None" / "TempError" / "PermError"
-
- key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
- [";"]
-
- key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
-
- key = "client-ip" / "envelope-from" / "helo" /
- "problem" / "receiver" / "identity" /
- mechanism / "x-" name / name
-
- identity = "mailfrom" ; for the "MAIL FROM" identity
- / "helo" ; for the "HELO" identity
- / name ; other identities
-
- dot-atom = <unquoted word as per [RFC2822]>
- quoted-string = <quoted string as per [RFC2822]>
- comment = <comment string as per [RFC2822]>
- CFWS = <comment or folding white space as per [RFC2822]>
- FWS = <folding white space as per [RFC2822]>
- CRLF = <standard end-of-line token as per [RFC2822]>
-
-
-
-Wong & Schlitt Experimental [Page 43]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-Appendix B. Extended Examples
-
- These examples are based on the following DNS setup:
-
- ; A domain with two mail servers, two hosts
- ; and two servers at the domain name
- $ORIGIN example.com.
- @ MX 10 mail-a
- MX 20 mail-b
- A 192.0.2.10
- A 192.0.2.11
- amy A 192.0.2.65
- bob A 192.0.2.66
- mail-a A 192.0.2.129
- mail-b A 192.0.2.130
- www CNAME example.com.
-
- ; A related domain
- $ORIGIN example.org.
- @ MX 10 mail-c
- mail-c A 192.0.2.140
-
- ; The reverse IP for those addresses
- $ORIGIN 2.0.192.in-addr.arpa.
- 10 PTR example.com.
- 11 PTR example.com.
- 65 PTR amy.example.com.
- 66 PTR bob.example.com.
- 129 PTR mail-a.example.com.
- 130 PTR mail-b.example.com.
- 140 PTR mail-c.example.org.
-
- ; A rogue reverse IP domain that claims to be
- ; something it's not
- $ORIGIN 0.0.10.in-addr.arpa.
- 4 PTR bob.example.com.
-
-B.1. Simple Examples
-
- These examples show various possible published records for
- example.com and which values if <ip> would cause check_host() to
- return "Pass". Note that <domain> is "example.com".
-
- v=spf1 +all
- -- any <ip> passes
-
- v=spf1 a -all
- -- hosts 192.0.2.10 and 192.0.2.11 pass
-
-
-
-Wong & Schlitt Experimental [Page 44]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
- v=spf1 a:example.org -all
- -- no sending hosts pass since example.org has no A records
-
- v=spf1 mx -all
- -- sending hosts 192.0.2.129 and 192.0.2.130 pass
-
- v=spf1 mx:example.org -all
- -- sending host 192.0.2.140 passes
-
- v=spf1 mx mx:example.org -all
- -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
-
- v=spf1 mx/30 mx:example.org/30 -all
- -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
-
- v=spf1 ptr -all
- -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
- example.com)
- -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
- in example.com)
- -- sending host 10.0.0.4 fails (reverse IP is not valid)
-
- v=spf1 ip4:192.0.2.128/28 -all
- -- sending host 192.0.2.65 fails
- -- sending host 192.0.2.129 passes
-
-B.2. Multiple Domain Example
-
- These examples show the effect of related records:
-
- example.org: "v=spf1 include:example.com include:example.net -all"
-
- This record would be used if mail from example.org actually came
- through servers at example.com and example.net. Example.org's
- designated servers are the union of example.com's and example.net's
- designated servers.
-
- la.example.org: "v=spf1 redirect=example.org"
- ny.example.org: "v=spf1 redirect=example.org"
- sf.example.org: "v=spf1 redirect=example.org"
-
- These records allow a set of domains that all use the same mail
- system to make use of that mail system's record. In this way, only
- the mail system's record needs to be updated when the mail setup
- changes. These domains' records never have to change.
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 45]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-B.3. DNSBL Style Example
-
- Imagine that, in addition to the domain records listed above, there
- are these:
-
- $ORIGIN _spf.example.com. mary.mobile-users A
- 127.0.0.2 fred.mobile-users A 127.0.0.2
- 15.15.168.192.joel.remote-users A 127.0.0.2
- 16.15.168.192.joel.remote-users A 127.0.0.2
-
- The following records describe users at example.com who mail from
- arbitrary servers, or who mail from personal servers.
-
- example.com:
-
- v=spf1 mx
- include:mobile-users._spf.%{d}
- include:remote-users._spf.%{d}
- -all
-
- mobile-users._spf.example.com:
-
- v=spf1 exists:%{l1r+}.%{d}
-
- remote-users._spf.example.com:
-
- v=spf1 exists:%{ir}.%{l1r+}.%{d}
-
-B.4. Multiple Requirements Example
-
- Say that your sender policy requires both that the IP address is
- within a certain range and that the reverse DNS for the IP matches.
- This can be done several ways, including the following:
-
- example.com. SPF ( "v=spf1 "
- "-include:ip4._spf.%{d} "
- "-include:ptr._spf.%{d} "
- "+all" )
- ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
- ptr._spf.example.com. SPF "v=spf1 -ptr +all"
-
- This example shows how the "-include" mechanism can be useful, how an
- SPF record that ends in "+all" can be very restrictive, and the use
- of De Morgan's Law.
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 46]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-Authors' Addresses
-
- Meng Weng Wong
- Singapore
-
- EMail: mengwong+spf@pobox.com
-
-
- Wayne Schlitt
- 4615 Meredeth #9
- Lincoln Nebraska, NE 68506
- United States of America
-
- EMail: wayne@schlitt.net
- URI: http://www.schlitt.net/spf/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 47]
-\f
-RFC 4408 Sender Policy Framework (SPF) April 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- 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 provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Wong & Schlitt Experimental [Page 48]
-\f
projects / thirdparty / bind9.git / commitdiff
