route to the domain identified by an address-of-record; clients
however MUST NOT make the same ENUM query recursively (if the URI
returned by ENUM is or contains a tel URL, see [8]).
Note that SIP requests based on the use of NAPTR records may fail for
any number of reasons. If there are multiple NAPTR records relevant
to SIP present in an ENUM record set, then after a failure has
occurred on an initial attempt with one NAPTR record, SIP user agents
MAY try their request again with a different NAPTR record from the
ENUM record set.
7. Compatibility with RFC 2916
The ENUM specification is currently undergoing a revision in the ENUM
WG. The new specification, RFC 3761 [1], is based on the Dynamic
Delegation Discovery System [5] revision to the NAPTR resource record
specified in RFC 2915 [12]. For the most part, DDDS is an
organizational revision that makes the algorithmic aspects of record
processing separable from any underlying database format (such as the
NAPTR DNS resource record).
The most important revision in RFC 3761 is the concept of
enumservices. The original ENUM specification, RFC 2916, specified a
number of "service" values that could be used for ENUM, including the
"sip+E2U" service field. RFC 3761 introduces an IANA registration
system with new guidelines for the registration of enumservices,
which are no longer necessarily divided into discreet "service" and
"protocol" fields, and which admit of more complex structures. In
order to differentiate enumservices in RFC 3761 from those in RFC
2916, the string "E2U" is the leading element in an enumservice
field, whereas by RFC 2916 it was the trailing element.
An enumservice for SIP addresses-of-record is described in [7]. This
enumservice uses the enumservice field "E2U+sip". RFC 3761-compliant
authors of ENUM records for SIP MUST therefore use the "E2U+sip"
enumservice field instead of the "sip+E2U" field. For backwards
compatibility with existing legacy records, however, the ’sip+E2U’
field SHOULD be supported by an ENUM client that support SIP.
Also note that the terminology of DDDS differs in a number of
respects from the initial NAPTR terminology in RFC 2916. DDDS
introduces the concept of an Application, an Application Specific
String, a First Well Known Rule, and so on. The terminology used in
this document is a little looser (it refers to a ’starting string’,
for example, where ’Application Specific String’ would be used for
DDDS). The new terminology is reflected in RFC 3761.
8. Security Considerations
DNS does not make policy decisions about the records that it shares
with an inquirer. All DNS records must be assumed to be available to
all inquirers at all times. The information provided within an ENUM
record set must therefore be considered to be open to the public -
which is a cause for some privacy considerations.
Ordinarily, when you give someone your telephone number, you don’t
expect that they will be able to trivially determine your full name
and place of employment. If, however, you create a NAPTR record for
use with ENUM that maps your telephone number to a SIP URI like
’julia.roberts@example.com’, expect to get a lot of calls from
excited fans.
Unlike a traditional telephone number, the target of a SIP URI may
require that callers provide cryptographic credentials for
authentication and authorization before a user is alerted. In this
respect, ENUM in concert with SIP can actually provide far greater
protection from unwanted callers than the existing PSTN, despite the
public availability of ENUM records.
Users of ENUM who are nevertheless uncomfortable with revealing their
names may, since identities on the Internet are not exactly at a
premium, publish a less revealing SIP URI, like
’sip:anonymous00045@example.com’ or even
’sip:anonymous00045@anonymous-redirector.example.org’, which could in
turn point to their internal URI.
An analysis of threats specific to the dependence of ENUM on the DNS,
and the applicability of DNSSEC [18] to these, is provided in [1].
9. References
9.1. Normative References
[1] Faltstrom, P. and M. Mealling, "E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD13, RFC 1034, November 1987.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[7] Peterson, J., "enumservice registration for SIP Addresses-of-
Record", RFC 3764, April 2004.
[8] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
9.2. Informative References
[10] International Telecommunications Union, "Recommendation E.164:
The international public telecommunication numbering plan", May
1997, <http://www.itu.int>.
[11] Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
Work in Progress, June 2003.
[12] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[13] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[14] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol:
Locating SIP Servers", RFC 3263, June 2002.
[15] Rosenberg, J., Squire, M., and H. Salama, "Telephony Routing
over IP (TRIP)", RFC 3219, August 2001.
[16] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[17] Peterson, J., "Enumservice Registration for Presence Services",
Work in Progress, February 2003.
[18] Arends, R., et al., "Protocol Modifications for the DNS
Security Extensions", Work in Progress, May 2004.
Appendix A. Acknowledgments
The authors would like to thank Richard Shockey for his input on
privacy issues, and Tom McGarry and Rohan Mahy for overall comments
and analysis. Thanks are due as well to Juan Heinanen and Lawrence
E. Conroy for advice on updating this document to better reflect RFC
3761. Special thanks are given to Patrik Faltstrom and Michael
Mealling for significantly reducing the size of this document by
producing a tight and well-specified successor to RFC 2916. Richard
Stastny and Patrik Faltstrom also provided valuable notes on the
valid usage of non-greedy regexp antecedents.
Authors’ Addresses
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Hong Liu
NeuStar, Inc.
46000 Center Oak Plaza
Sterling, VA 20166
USA
EMail: hong.liu@neustar.biz
URI: http://www.neustar.biz/
James Yu
NeuStar, Inc.
46000 Center Oak Plaza
Sterling, VA 20166
USA
Phone: +1 571/434-5572
EMail: james.yu@neustar.biz
URI: http://www.neustar.biz/
Ben Campbell
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
USA
EMail: bcampbell@dynamicsoft.com
URI: http://www.dynamicsoft.com/
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.