to the server.
4. If the names match and the credentials have integrity, there is
reasonable assurance that the correct end point has been reached.
5. The client and server establish an integrity-protected channel.
Note that this document does not define either the handshake
mechanism, the specific credential naming fields, nor the name-
matching semantics. Definitions of S-NAPTR for particular
application protocols MUST define these.
9. Acknowledgements
Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd, and Ted
Hardie for discussion and input that have (hopefully!) provoked
clarifying revisions to this document.
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] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403, October
2002.
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
2002.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
10.2. Informative References
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[9] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type
for the Internet Registry Information Service (IRIS)", RFC 3982,
January 2005.
[10] Newton, A. and M. Sanz, "Using the Internet Registry Information
Service (IRIS) over the Blocks Extensible Exchange Protocol
(BEEP)", RFC 3983, January 2005.
[11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
System", Work in Progress, April 2004.
[12] Arends, R., Larson, M., Austein, R., and D. Massey, "Protocol
Modifications for the DNS Security Extensions", Work in
Progress, May 2004.
Appendix A. Pseudo-Pseudocode for S-NAPTR
A.1. Finding the First (Best) Target
Assuming the client supports 1 protocol for a particular application
service, the following pseudocode outlines the expected process to
find the first (best) target for the client, using S-NAPTR.
target = [initial domain]
naptr-done = false
while (not naptr-done)
{
NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
[sort NAPTR-RRset by ORDER, and PREF within each ORDER]
rr-done = false
cur-rr = [first NAPTR RR]
while (not rr-done)
if ([SERVICE field of cur-rr contains desired application
service and application protocol])
rr-done = true
target= [REPLACEMENT target of NAPTR RR]
else
cur-rr = [next rr in list]
if (not empty [FLAG in cur-rr])
naptr-done = true
}
port = -1
if ([FLAG in cur-rr is "S"])
{
SRV-RRset = [DNSlookup of SRV RRs for target]
[sort SRV-RRset based on PREF]
target = [target of first RR of SRV-RRset]
port = [port in first RR of SRV-RRset]
}
; now, whether it was an "S" or an "A" in the NAPTR, we
; have the target for an A record lookup
host = [DNSlookup of target]
return (host, port)
A.2. Finding Subsequent Targets
The pseudocode in Appendix A is crafted to find the first, most
preferred host-port pair for a particular application service and
protocol. If, for any reason, that host-port pair did not work
(connection refused, application-level error), the client is expected
to try the next host-port in the S-NAPTR tree.
The pseudocode above does not permit retries -- once complete, it
sheds all context of where in the S-NAPTR tree it finished.
Therefore, client software writers could
o entwine the application-specific protocol with the DNS lookup and
RRset processing described in the pseudocode and continue the S-
NAPTR processing if the application code fails to connect to a
located host-port pair;
o use callbacks for the S-NAPTR processing; or
o use an S-NAPTR resolution routine that finds *all* valid servers
for the required application service and protocol from the
originating domain and that provides them in a sorted order for
the application to try.
Appendix B. Availability of Sample Code
Sample Python code for S-NAPTR resolution is available from
http://www.verisignlabs.com/pysnaptr-0.1.tgz
Authors’ Addresses
Leslie Daigle
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
Andrew Newton
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: anewton@verisignlabs.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.