RFC3958 日本語訳
3958 Domain-Based Application Service Location Using SRV RRs and theDynamic Delegation Discovery Service (DDDS). L. Daigle, A. Newton. January 2005. (Format: TXT=54568 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Daigle
Request for Comments: 3958 A. Newton
Category: Standards Track VeriSign, Inc.
January 2005
Network Working Group L. Daigle Request for Comments: 3958 A. Newton Category: Standards Track VeriSign, Inc. January 2005
Domain-Based Application Service Location Using SRV RRs and the
Dynamic Delegation Discovery Service (DDDS)
Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
Status of This Memo
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.
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 Notice
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
Abstract
Abstract
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port.
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port.
Table of Contents
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . . 3
2.1. Key Terms. . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. S-NAPTR DDDS Application Usage . . . . . . . . . . . . . 4
2.2.1. Ordering and Preference. . . . . . . . . . . . . 4
2.2.2. Matching and Non-matching NAPTR Records. . . . . 4
2.2.3. Terminal and Non-terminal NAPTR Records. . . . . 5
2.2.4. S-NAPTR and Successive Resolution. . . . . . . . 5
2.2.5. Clients Supporting Multiple Protocols. . . . . . 6
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Guidelines for Application Protocol Developers . . . . . 6
3.1.1. Registration of Application Service and
Protocol Tags. . . . . . . . . . . . . . . . . . 7
3.1.2. Definition of Conditions for Retry/Failure . . . 7
3.1.3. Server Identification and Handshake . . . . . . 8
3.2. Guidelines for Domain Administrators . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . . 3 2.1. Key Terms. . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. S-NAPTR DDDS Application Usage . . . . . . . . . . . . . 4 2.2.1. Ordering and Preference. . . . . . . . . . . . . 4 2.2.2. Matching and Non-matching NAPTR Records. . . . . 4 2.2.3. Terminal and Non-terminal NAPTR Records. . . . . 5 2.2.4. S-NAPTR and Successive Resolution. . . . . . . . 5 2.2.5. Clients Supporting Multiple Protocols. . . . . . 6 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Guidelines for Application Protocol Developers . . . . . 6 3.1.1. Registration of Application Service and Protocol Tags. . . . . . . . . . . . . . . . . . 7 3.1.2. Definition of Conditions for Retry/Failure . . . 7 3.1.3. Server Identification and Handshake . . . . . . 8 3.2. Guidelines for Domain Administrators . . . . . . . . . . 8
Daigle & Newton Standards Track [Page 1] RFC 3958 DDDS January 2005
Daigle & Newton Standards Track [Page 1] RFC 3958 DDDS January 2005
3.3. Guidelines for Client Software Writers . . . . . . . . . 8
4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Service Discovery within a Domain . . . . . . . . . . . 9
4.3. Multiple Protocols . . . . . . . . . . . . . . . . . . . 10
4.4. Remote Hosting . . . . . . . . . . . . . . . . . . . . . 11
4.5. Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . 12
4.6. Sample Sequence Diagram . . . . . . . . . . . . . . . . 13
5. Motivation and Discussion . . . . . . . . . . . . . . . . . . 14
5.1. So Why Not Just SRV Records? . . . . . . . . . . . . . . 15
5.2. So Why Not Just NAPTR Records? . . . . . . . . . . . . . 15
6. Formal Definition of <Application Service Location>
Application of DDDS . . . . . . . . . . . . . . . . . . . . . 16
6.1. Application-Unique String . . . . . . . . . . . . . . . 16
6.2. First Well-Known Rule . . . . . . . . . . . . . . . . . 16
6.3. Expected Output . . . . . . . . . . . . . . . . . . . . 16
6.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Service Parameters . . . . . . . . . . . . . . . . . . . 17
6.5.1. Application Services . . . . . . . . . . . . . . 17
6.5.2. Application Protocols . . . . . . . . . . . . . 17
6.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Valid Databases . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Application Service Tag IANA Registry . . . . . . . . . 18
7.2. Application Protocol Tag IANA Registry . . . . . . . . . 18
7.3. Registration Process . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A. Pseudo-pseudocode for S-NAPTR. . . . . . . . . . . . . . . 22
A.1. Finding the First (Best) Target. . . . . . . . . . . 22
A.2. Finding Subsequent Targets . . . . . . . . . . . . . 23
B. Availability of Sample Code. . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 25
3.3. Guidelines for Client Software Writers . . . . . . . . . 8 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Service Discovery within a Domain . . . . . . . . . . . 9 4.3. Multiple Protocols . . . . . . . . . . . . . . . . . . . 10 4.4. Remote Hosting . . . . . . . . . . . . . . . . . . . . . 11 4.5. Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . 12 4.6. Sample Sequence Diagram . . . . . . . . . . . . . . . . 13 5. Motivation and Discussion . . . . . . . . . . . . . . . . . . 14 5.1. So Why Not Just SRV Records? . . . . . . . . . . . . . . 15 5.2. So Why Not Just NAPTR Records? . . . . . . . . . . . . . 15 6. Formal Definition of <Application Service Location> Application of DDDS . . . . . . . . . . . . . . . . . . . . . 16 6.1. Application-Unique String . . . . . . . . . . . . . . . 16 6.2. First Well-Known Rule . . . . . . . . . . . . . . . . . 16 6.3. Expected Output . . . . . . . . . . . . . . . . . . . . 16 6.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.5. Service Parameters . . . . . . . . . . . . . . . . . . . 17 6.5.1. Application Services . . . . . . . . . . . . . . 17 6.5.2. Application Protocols . . . . . . . . . . . . . 17 6.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . 17 6.7. Valid Databases . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7.1. Application Service Tag IANA Registry . . . . . . . . . 18 7.2. Application Protocol Tag IANA Registry . . . . . . . . . 18 7.3. Registration Process . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A. Pseudo-pseudocode for S-NAPTR. . . . . . . . . . . . . . . 22 A.1. Finding the First (Best) Target. . . . . . . . . . . 22 A.2. Finding Subsequent Targets . . . . . . . . . . . . . 23 B. Availability of Sample Code. . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
1. Introduction
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS -- see [4]) Application to map domain name, application service name, and application protocol dynamically to target server and port.
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS -- see [4]) Application to map domain name, application service name, and application protocol dynamically to target server and port.
Daigle & Newton Standards Track [Page 2] RFC 3958 DDDS January 2005
Daigle & Newton Standards Track [Page 2] RFC 3958 DDDS January 2005
As discussed in section 5, existing approaches to using DNS records for dynamically determining the current host for a given application service are limited in terms of the use cases supported. To address some of the limitations, this document defines a DDDS Application to map service+protocol+domain to specific server addresses by using both NAPTR [5] and SRV ([3]) DNS resource records. This can be viewed as a more general version of the use of SRV and/or a very restricted application of the use of NAPTR resource records.
As discussed in section 5, existing approaches to using DNS records for dynamically determining the current host for a given application service are limited in terms of the use cases supported. To address some of the limitations, this document defines a DDDS Application to map service+protocol+domain to specific server addresses by using both NAPTR [5] and SRV ([3]) DNS resource records. This can be viewed as a more general version of the use of SRV and/or a very restricted application of the use of NAPTR resource records.
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 BCP 14, RFC 2119 [1].
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 BCP 14, RFC 2119 [1].
2. Straightforward-NAPTR (S-NAPTR) Specification
2. Straightforward-NAPTR (S-NAPTR) Specification
The precise details of the specification of this DDDS application are given in Section 6. This section defines the usage of the DDDS application.
The precise details of the specification of this DDDS application are given in Section 6. This section defines the usage of the DDDS application.
2.1. Key Terms
2.1. Key Terms
"Application service" is a generic term for some type of application, independent of the protocol that may be used to offer it. Each application service will be associated with an IANA-registered tag. For example, retrieving mail is a type of application service that can be implemented by different application-layer protocols (e.g., POP3, IMAP4). A tag, such as "RetMail", could be registered for it. (Note that this has not been done, and there are no plans to do so at the time of this writing.)
"Application service" is a generic term for some type of application, independent of the protocol that may be used to offer it. Each application service will be associated with an IANA-registered tag. For example, retrieving mail is a type of application service that can be implemented by different application-layer protocols (e.g., POP3, IMAP4). A tag, such as "RetMail", could be registered for it. (Note that this has not been done, and there are no plans to do so at the time of this writing.)
An "application protocol" is used to implement the application service. These are also associated with IANA-registered tags. Using the mail example above, "POP3" and "IMAP4" could be registered as application protocol tags. If multiple transports are available for the application, separate tags should be defined for each transport.
An "application protocol" is used to implement the application service. These are also associated with IANA-registered tags. Using the mail example above, "POP3" and "IMAP4" could be registered as application protocol tags. If multiple transports are available for the application, separate tags should be defined for each transport.
The intention is that the combination of application service and protocol tags should be specific enough that finding a known pair (e.g., "RetMail:POP3" would be sufficient for a client to identify a server with which it can communicate.
The intention is that the combination of application service and protocol tags should be specific enough that finding a known pair (e.g., "RetMail:POP3" would be sufficient for a client to identify a server with which it can communicate.
Some protocols support multiple application services. For example, LDAP is an application protocol and can be found supporting various services (e.g., "whitepages", "directory enabled networking".
Some protocols support multiple application services. For example, LDAP is an application protocol and can be found supporting various services (e.g., "whitepages", "directory enabled networking".
Daigle & Newton Standards Track [Page 3] RFC 3958 DDDS January 2005
Daigle & Newton Standards Track [Page 3] RFC 3958 DDDS January 2005
2.2. S-NAPTR DDDS Application Usage
2.2. S-NAPTR DDDS Application Usage
As defined in section 6, NAPTR records are used to store application service+protocol information for a given domain. Following the DDDS standard, these records are looked up, and the rewrite rules (contained in the NAPTR records) are used to determine the successive DNS lookups until a desirable target is found.
As defined in section 6, NAPTR records are used to store application service+protocol information for a given domain. Following the DDDS standard, these records are looked up, and the rewrite rules (contained in the NAPTR records) are used to determine the successive DNS lookups until a desirable target is found.
For the rest of this section, refer to the set of NAPTR resource records for example.com, shown in the figure below, where "WP" is the imagined application service tag for "white pages" and "EM" is the application service tag for an imagined "Extensible Messaging" application service.
For the rest of this section, refer to the set of NAPTR resource records for example.com, shown in the figure below, where "WP" is the imagined application service tag for "white pages" and "EM" is the application service tag for an imagined "Extensible Messaging" application service.
example.com.
;; order pref flags
IN NAPTR 100 10 "" "WP:whois++" ( ; service
"" ; regexp
bunyip.example. ; replacement
)
IN NAPTR 100 20 "s" "WP:ldap" ( ; service
"" ; regexp
_ldap._tcp.myldap.example.com. ; replacement
)
IN NAPTR 200 10 "" "EM:protA" ( ; service
"" ; regexp
someisp.example. ; replacement
)
IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp
myprotB.example.com.; replacement
)
example.com. ;; order pref flags IN NAPTR 100 10 "" "WP:whois++" ( ; service "" ; regexp bunyip.example. ; replacement ) IN NAPTR 100 20 "s" "WP:ldap" ( ; service "" ; regexp _ldap._tcp.myldap.example.com. ; replacement ) IN NAPTR 200 10 "" "EM:protA" ( ; service "" ; regexp someisp.example. ; replacement ) IN NAPTR 200 30 "a" "EM:protB" ; service "" ; regexp myprotB.example.com.; replacement )
2.2.1. Ordering and Preference
2.2.1. Ordering and Preference
A client retrieves all the NAPTR records associated with the target domain name (example.com, above). These are to be sorted in terms of increasing ORDER and increasing PREF within each ORDER.
A client retrieves all the NAPTR records associated with the target domain name (example.com, above). These are to be sorted in terms of increasing ORDER and increasing PREF within each ORDER.
2.2.2. Matching and Non-Matching NAPTR Records
2.2.2. Matching and Non-Matching NAPTR Records
Starting with the first sorted NAPTR record, the client examines the SERVICE field to find a match. In the case of the S-NAPTR DDDS application, this means a SERVICE field that includes the tags for the desired application service and a supported application protocol.
Starting with the first sorted NAPTR record, the client examines the SERVICE field to find a match. In the case of the S-NAPTR DDDS application, this means a SERVICE field that includes the tags for the desired application service and a supported application protocol.
If more than one NAPTR record matches, they are processed in increasing sort order.
If more than one NAPTR record matches, they are processed in increasing sort order.
Daigle & Newton Standards Track [Page 4] RFC 3958 DDDS January 2005
Daigle & Newton Standards Track [Page 4] RFC 3958 DDDS January 2005
2.2.3. Terminal and Non-terminal NAPTR Records
2.2.3. Terminal and Non-terminal NAPTR Records
A NAPTR record with an empty FLAG field is "non-terminal" -- that is, more NAPTR RR lookups are to be performed. Thus, to process a NAPTR record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is used as the target of the next DNS lookup -- for NAPTR RRs.
A NAPTR record with an empty FLAG field is "non-terminal" -- that is, more NAPTR RR lookups are to be performed. Thus, to process a NAPTR record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is used as the target of the next DNS lookup -- for NAPTR RRs.
In S-NAPTR, the only terminal flags are "S" and "A". These are called "terminal" NAPTR lookups because they denote the end of the DDDS/NAPTR processing rules. In the case of an "S" flag, the REPLACEMENT field is used as the target of a DNS query for SRV RRs, and normal SRV processing is applied. In the case of an "A" flag, an address record is sought for the REPLACEMENT field target (and the default protocol port is assumed).
In S-NAPTR, the only terminal flags are "S" and "A". These are called "terminal" NAPTR lookups because they denote the end of the DDDS/NAPTR processing rules. In the case of an "S" flag, the REPLACEMENT field is used as the target of a DNS query for SRV RRs, and normal SRV processing is applied. In the case of an "A" flag, an address record is sought for the REPLACEMENT field target (and the default protocol port is assumed).
2.2.4. S-NAPTR and Successive Resolution
2.2.4. S-NAPTR and Successive Resolution
As shown in the example set above, it is possible to have multiple possible targets for a single application service+protocol pair. These are to be pursued in order until a server is successfully contacted or all possible matching NAPTR records have been successively pursued through terminal lookup and server contact. That is, a client must backtrack and attempt other resolution paths in the case of failure.
As shown in the example set above, it is possible to have multiple possible targets for a single application service+protocol pair. These are to be pursued in order until a server is successfully contacted or all possible matching NAPTR records have been successively pursued through terminal lookup and server contact. That is, a client must backtrack and attempt other resolution paths in the case of failure.
"Failure" is declared, and backtracking must be used, when
"Failure" is declared, and backtracking must be used, when
o the designated remote server (host and port) fails to provide
appropriate security credentials for the *originating* domain;
o the designated remote server (host and port) fails to provide appropriate security credentials for the *originating* domain;
o connection to the designated remote server otherwise fails -- the
specifics terms of which are defined when an application protocol
is registered; or
o connection to the designated remote server otherwise fails -- the specifics terms of which are defined when an application protocol is registered; or
o the S-NAPTR-designated DNS lookup fails to yield expected results
-- e.g., no A RR for an "A" target, no SRV record for an "S"
target, or no NAPTR record with appropriate application service
and protocol for a NAPTR lookup. Except in the case of the very
first NAPTR lookup, this last is a configuration error: the fact
that example.com has a NAPTR record pointing to "bunyip.example"
for the "WP:Whois++" service and protocol means the administrator
of example.com believes that service exists. If bunyip.example
has no "WP:Whois++" NAPTR record, the application client MUST
backtrack and try the next available "WP:Whois++" option from
example.com. As there is none, the whole resolution fails.
o the S-NAPTR-designated DNS lookup fails to yield expected results -- e.g., no A RR for an "A" target, no SRV record for an "S" target, or no NAPTR record with appropriate application service and protocol for a NAPTR lookup. Except in the case of the very first NAPTR lookup, this last is a configuration error: the fact that example.com has a NAPTR record pointing to "bunyip.example" for the "WP:Whois++" service and protocol means the administrator of example.com believes that service exists. If bunyip.example has no "WP:Whois++" NAPTR record, the application client MUST backtrack and try the next available "WP:Whois++" option from example.com. As there is none, the whole resolution fails.
Daigle & Newton Standards Track [Page 5] RFC 3958 DDDS January 2005
Daigle & Newton Standards Track [Page 5] RFC 3958 DDDS January 2005
An application client first queries for the NAPTR RRs for the domain of a named application service. The first DNS query is for the NAPTR RRs in the original target domain (example.com, above).
An application client first queries for the NAPTR RRs for the domain of a named application service. The first DNS query is for the NAPTR RRs in the original target domain (example.com, above).
2.2.5. Clients Supporting Multiple Protocols
2.2.5. Clients Supporting Multiple Protocols
In the case of an application client that supports more than one protocol for a given application service, it MUST pursue S-NAPTR resolution completely for one protocol, exploring all potential terminal lookups in PREF and ORDER ranking, until the application connects successfully or there are no more possibilities for that protocol.
In the case of an application client that supports more than one protocol for a given application service, it MUST pursue S-NAPTR resolution completely for one protocol, exploring all potential terminal lookups in PREF and ORDER ranking, until the application connects successfully or there are no more possibilities for that protocol.
That is, the client MUST NOT start looking for one protocol, observe that a successive NAPTR RR set supports another of its preferred protocols, and continue the S-NAPTR resolution based on that protocol. For example, even if someisp.example offers the "EM" service with protocol "ProtB", there is no reason to believe that it does so on behalf of example.com (as there is no such pointer in example.com's NAPTR RR set).
That is, the client MUST NOT start looking for one protocol, observe that a successive NAPTR RR set supports another of its preferred protocols, and continue the S-NAPTR resolution based on that protocol. For example, even if someisp.example offers the "EM" service with protocol "ProtB", there is no reason to believe that it does so on behalf of example.com (as there is no such pointer in example.com's NAPTR RR set).
It MAY choose which protocol to try first based on its own preference, or on the PREF ranking in the first set of NAPTR records (i.e., those for the target named domain). However, the chosen protocol MUST be listed in that first NAPTR RR set.
It MAY choose which protocol to try first based on its own preference, or on the PREF ranking in the first set of NAPTR records (i.e., those for the target named domain). However, the chosen protocol MUST be listed in that first NAPTR RR set.
It MAY choose to run simultaneous DDDS resolutions for more than one protocol, in which case the requirements above apply for each protocol independently. That is, do not switch protocols mid- resolution.
It MAY choose to run simultaneous DDDS resolutions for more than one protocol, in which case the requirements above apply for each protocol independently. That is, do not switch protocols mid- resolution.
3. Guidelines
3. Guidelines
3.1. Guidelines for Application Protocol Developers
3.1. Guidelines for Application Protocol Developers
The purpose of S-NAPTR is to provide application standards developers with a more powerful framework (than SRV RRs alone) for naming service targets, without requiring each application protocol (or service) standard to define a separate DDDS application.
The purpose of S-NAPTR is to provide application standards developers with a more powerful framework (than SRV RRs alone) for naming service targets, without requiring each application protocol (or service) standard to define a separate DDDS application.
Note that this approach is intended specifically for use when it makes sense to associate services with particular domain names (e.g., e-mail addresses, SIP addresses, etc). A non-goal is having all manner of label mapped into domain names in order to use this.
Note that this approach is intended specifically for use when it makes sense to associate services with particular domain names (e.g., e-mail addresses, SIP addresses, etc). A non-goal is having all manner of label mapped into domain names in order to use this.
Daigle & Newton Standards Track [Page 6] RFC 3958 DDDS January 2005
Daigle & Newton Standards Track [Page 6] RFC 3958 DDDS January 2005
This document does not address how to select the domain for which the service+protocol is being sought. Other conventions will have to define how this might be used (e.g., new messaging standards can define what domain to use from their URIs or how to step down from foobar.example.com to example.com, if applicable).
This document does not address how to select the domain for which the service+protocol is being sought. Other conventions will have to define how this might be used (e.g., new messaging standards can define what domain to use from their URIs or how to step down from foobar.example.com to example.com, if applicable).
Although this document proposes a DDDS application that does not use all the features of NAPTR resource records, it is not intended to imply that DNS resolvers should fail to implement all aspects of the NAPTR RR standard. A DDDS application is a client use convention.
Although this document proposes a DDDS application that does not use all the features of NAPTR resource records, it is not intended to imply that DNS resolvers should fail to implement all aspects of the NAPTR RR standard. A DDDS application is a client use convention.
The rest of this section outlines the specific elements that protocol developers must determine and document to make use of S-NAPTR.
The rest of this section outlines the specific elements that protocol developers must determine and document to make use of S-NAPTR.
3.1.1. Registration of Application Service and Protocol Tags
3.1.1. Registration of Application Service and Protocol Tags
Application protocol developers who wish to make use of S-NAPTR must make provisions for registering any relevant application service and application protocol tags, as described in section 7.
Application protocol developers who wish to make use of S-NAPTR must make provisions for registering any relevant application service and application protocol tags, as described in section 7.
3.1.2. Definition of Conditions for Retry/Failure
3.1.2. Definition of Conditions for Retry/Failure
One other important aspect that must be defined is the expected behaviour for interacting with the servers that are reached via S- NAPTR. Specifically, under what circumstances should the client retry a target that was found via S-NAPTR? What should it consider a failure that causes it to return to the S-NAPTR process to determine the next serviceable target, which by definition will have a lower preference ranking.
One other important aspect that must be defined is the expected behaviour for interacting with the servers that are reached via S- NAPTR. Specifically, under what circumstances should the client retry a target that was found via S-NAPTR? What should it consider a failure that causes it to return to the S-NAPTR process to determine the next serviceable target, which by definition will have a lower preference ranking.
For example, if the client gets a "connection refused" message from a server, should it retry for some (protocol-dependent) period of time? Or should it try the next-preferred target in the S-NAPTR chain of resolution? Should it only try the next-preferred target if it receives a protocol-specific permanent error message?
For example, if the client gets a "connection refused" message from a server, should it retry for some (protocol-dependent) period of time? Or should it try the next-preferred target in the S-NAPTR chain of resolution? Should it only try the next-preferred target if it receives a protocol-specific permanent error message?
The most important thing is to select one expected behaviour and document it as part of the use of S-NAPTR.
The most important thing is to select one expected behaviour and document it as part of the use of S-NAPTR.
As noted earlier, failure to provide appropriate credentials to identify the server as being authoritative for the original target domain is always considered a failure condition.
As noted earlier, failure to provide appropriate credentials to identify the server as being authoritative for the original target domain is always considered a failure condition.
Daigle & Newton Standards Track [Page 7] RFC 3958 DDDS January 2005
Daigle & Newton Standards Track [Page 7] RFC 3958 DDDS January 2005
3.1.3. Server Identification and Handshake
3.1.3. Server Identification and Handshake
As noted in section 8, use of the DNS for server location increases the importance of using protocol-specific handshakes to determine and confirm the identity of the server that is eventually reached.
As noted in section 8, use of the DNS for server location increases the importance of using protocol-specific handshakes to determine and confirm the identity of the server that is eventually reached.
Therefore, application protocol developers using S-NAPTR should identify the mechanics of the expected identification handshake when the client connects to a server found through S-NAPTR.
Therefore, application protocol developers using S-NAPTR should identify the mechanics of the expected identification handshake when the client connects to a server found through S-NAPTR.
3.2. Guidelines for Domain Administrators
3.2. Guidelines for Domain Administrators
Although S-NAPTR aims to provide a "straightforward" application of DDDS and use of NAPTR records, it is still possible to create very complex chains and dependencies with the NAPTR and SRV records.
Although S-NAPTR aims to provide a "straightforward" application of DDDS and use of NAPTR records, it is still possible to create very complex chains and dependencies with the NAPTR and SRV records.
Therefore, domain administrators are called upon to use S-NAPTR with as much restraint as possible while still achieving their service design goals.
Therefore, domain administrators are called upon to use S-NAPTR with as much restraint as possible while still achieving their service design goals.
The complete set of NAPTR, SRV, and A RRs "reachable" through the S- NAPTR process for a particular application service can be thought of as a "tree". Each NAPTR RR that is retrieved points to more NAPTR or SRV records; each SRV record points to several A record lookups. Even though a particular client can "prune" the tree to use only those records referring to application protocols supported by the client, the tree could be quite deep, and retracing the tree to retry other targets can become expensive if the tree has many branches.
The complete set of NAPTR, SRV, and A RRs "reachable" through the S- NAPTR process for a particular application service can be thought of as a "tree". Each NAPTR RR that is retrieved points to more NAPTR or SRV records; each SRV record points to several A record lookups. Even though a particular client can "prune" the tree to use only those records referring to application protocols supported by the client, the tree could be quite deep, and retracing the tree to retry other targets can become expensive if the tree has many branches.
Therefore,
Therefore,
o fewer branches is better: For both NAPTR and SRV records, provide
different targets with varying preferences where appropriate
(e.g., to provide backup services) but don't look for reasons to
provide more; and
o fewer branches is better: For both NAPTR and SRV records, provide different targets with varying preferences where appropriate (e.g., to provide backup services) but don't look for reasons to provide more; and
o shallower is better: Avoid using NAPTR records to "rename"
services within a zone. Use NAPTR records to identify services
hosted elsewhere (i.e., where you cannot reasonably provide the
SRV records in your own zone).
o shallower is better: Avoid using NAPTR records to "rename" services within a zone. Use NAPTR records to identify services hosted elsewhere (i.e., where you cannot reasonably provide the SRV records in your own zone).
3.3. Guidelines for Client Software Writers
3.3. Guidelines for Client Software Writers
To understand DDDS/NAPTR properly, an implementor must read [4]. However, the most important aspect to keep in mind is that if the application cannot successfully connect to one target, the application will be expected to continue through the S-NAPTR tree to try the (less preferred) alternatives.
To understand DDDS/NAPTR properly, an implementor must read [4]. However, the most important aspect to keep in mind is that if the application cannot successfully connect to one target, the application will be expected to continue through the S-NAPTR tree to try the (less preferred) alternatives.
Daigle & Newton Standards Track [Page 8] RFC 3958 DDDS January 2005
Daigle & Newton Standards Track [Page 8] RFC 3958 DDDS January 2005
4. Illustrations
4. Illustrations
4.1. Use Cases
4.1. Use Cases
The basic intended use cases for which S-NAPTR has been developed are as follows
The basic intended use cases for which S-NAPTR has been developed are as follows
o Service discovery within a domain. For example, this can be used
to find the "authoritative" server for some type of service within
a domain (see the specific example in section 4.2).
o Service discovery within a domain. For example, this can be used to find the "authoritative" server for some type of service within a domain (see the specific example in section 4.2).
o Multiple protocols. This is already common today as new
application services are defined, and is increasingly a problem.
It includes the case of extensible messaging (a hypothetical
service), which can be offered with multiple protocols (see
section 4.3).
o Multiple protocols. This is already common today as new application services are defined, and is increasingly a problem. It includes the case of extensible messaging (a hypothetical service), which can be offered with multiple protocols (see section 4.3).
o Remote hosting. Each of the above use cases applies within the
administration of a single domain. However, one domain operator
may elect to engage another organization to provide an application
service. See section 4.4 for an example that cannot be served by
SRV records alone.
o Remote hosting. Each of the above use cases applies within the administration of a single domain. However, one domain operator may elect to engage another organization to provide an application service. See section 4.4 for an example that cannot be served by SRV records alone.
4.2. Service Discovery within a Domain
4.2. Service Discovery within a Domain
There are occasions when it is useful to be able to determine the "authoritative" server for a given application service within a domain. This is "discovery", as there is no a priori knowledge as to whether or where the service is offered; it is therefore important to determine the location and characteristics of the offered service.
There are occasions when it is useful to be able to determine the "authoritative" server for a given application service within a domain. This is "discovery", as there is no a priori knowledge as to whether or where the service is offered; it is therefore important to determine the location and characteristics of the offered service.
For example, there is growing discussion of having a generic mechanism for locating the keys or certificates associated with particular application (servers) operated in (or for) a particular domain. The following is a hypothetical case for storing application key or certificate data for a given domain: the premise is that a credentials registry (CredReg) service has been defined as a leaf node service holding the keys/certs for the servers operated by (or for) the domain. It is assumed that more than one protocol is available to provide the service for a particular domain. This DDDS-based approach is used to find the CredReg server that holds the information.
For example, there is growing discussion of having a generic mechanism for locating the keys or certificates associated with particular application (servers) operated in (or for) a particular domain. The following is a hypothetical case for storing application key or certificate data for a given domain: the premise is that a credentials registry (CredReg) service has been defined as a leaf node service holding the keys/certs for the servers operated by (or for) the domain. It is assumed that more than one protocol is available to provide the service for a particular domain. This DDDS-based approach is used to find the CredReg server that holds the information.
Daigle & Newton Standards Track [Page 9] RFC 3958 DDDS January 2005
Daigle & Newton Standards Track [Page 9] RFC 3958 DDDS January 2005
Thus, the set of NAPTR records for thinkingcat.example might look like this:
Thus, the set of NAPTR records for thinkingcat.example might look like this:
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "" "CREDREG:ldap:iris.beep" ( ; service
"" ; regexp
theserver.thinkingcat.example. ; replacement
thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "" "CREDREG:ldap:iris.beep" ( ; service "" ; regexp theserver.thinkingcat.example. ; replacement
Note that the application service might be offered in another domain using a different set of application protocols:
Note that the application service might be offered in another domain using a different set of application protocols:
anotherdomain.example.
;; order pref flags
IN NAPTR 100 10 "" "CREDREG:iris.lwz:iris.beep" ( ; service
"" ; regexp
foo.anotherdomain.example. ; replacement
)
anotherdomain.example. ;; order pref flags IN NAPTR 100 10 "" "CREDREG:iris.lwz:iris.beep" ( ; service "" ; regexp foo.anotherdomain.example. ; replacement )
4.3. Multiple Protocols
4.3. Multiple Protocols
Extensible messaging, a hypothetical application service, will be used for illustrative purposes. (For an example of a real application service with multiple protocols, see [9] and [10]). Assuming that "EM" was registered as an application service, this DDDS application could be used to determine the available services for delivery to a target.
Extensible messaging, a hypothetical application service, will be used for illustrative purposes. (For an example of a real application service with multiple protocols, see [9] and [10]). Assuming that "EM" was registered as an application service, this DDDS application could be used to determine the available services for delivery to a target.
Two particular features of this hypothetical extensible messaging should be noted:
Two particular features of this hypothetical extensible messaging should be noted:
1. Gatewaying is expected to bridge communications across protocols.
1. Gatewaying is expected to bridge communications across protocols.
2. Extensible messaging servers are likely to be operated out of a
different domain than that of the extensible messaging address,
and servers of different protocols may be offered by independent
organizations.
2. Extensible messaging servers are likely to be operated out of a different domain than that of the extensible messaging address, and servers of different protocols may be offered by independent organizations.
For example, "thinkingcat.example" may support its own servers for the "ProtA" extensible messaging protocol but rely on outsourcing from "example.com" for "ProtC" and "ProtB" servers.
例えば、"thinkingcat.example"は、"ProtA"広げることができるメッセージング・プロトコルのためにそれ自身のサーバをサポートしますが、"ProtC"と"ProtB"サーバのために"example.com"からアウトソーシングを当てにするかもしれません。
Using this DDDS-based approach, thinkingcat.example can indicate a preference ranking for the different types of servers for the extensible messaging service, yet the out-sourcer can independently rank the preference and ordering of servers. This independence is not achievable through the use of SRV records alone.
このDDDSベースのアプローチを使用して、thinkingcat.exampleは異なったタイプのサーバにおける、広げることができるメッセージングサービスのための幹部の優先を示すことができます、しかし、出ているsourcerが独自にサーバの好みと注文を格付けできます。 この独立はSRV記録だけの使用で達成可能ではありません。
Daigle & Newton Standards Track [Page 10] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[10ページ]。
Thus, to find the EM services for thinkingcat.example, the NAPTR records for thinkingcat.example are retrieved:
したがって、thinkingcat.exampleに関してEMサービスを見つけるために、thinkingcat.exampleのためのNAPTR記録は検索されます:
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "s" "EM:ProtB" ( ; service
"" ; regexp
_ProtB._tcp.example.com. ; replacement
)
IN NAPTR 100 30 "s" "EM:ProtC" ( ; service
"" ; regexp
_ProtC._tcp.example.com. ; replacement
)
thinkingcat.example。 ;; オーダーpref旗IN NAPTR100 10の「s」「EM: ProtA」( ; サービス、「「;」 regexp_ProtA_tcp.thinkingcat.example。 ; 交換) NAPTR100 20、「s」「EM: ProtB」( ; サービス、「「;」 regexp_ProtB_tcp.example.com。 ; 交換) NAPTR100 30、「s」「EM: ProtC」( ; サービス、「「;」 regexp_ProtC_tcp.example.com。 ; 交換)
Then the administrators at example.com can manage the preference rankings of the servers they use to support the ProtB service:
次に、example.comの管理者はそれらがProtBがサービスであるとサポートするのに使用するサーバの好みのランキングに対処できます:
_ProtB._tcp.example.com.
;; Pref Weight Port Target
IN SRV 10 0 10001 bigiron.example.com.
IN SRV 20 0 10001 backup.em.example.com.
IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
_ProtB_tcp.example.com。 ;; Pref Weight Port Target IN SRV10 0 10001bigiron.example.com。 IN SRV、20 0 10001 backup.em.example.com。 IN SRV、30 0 10001 nuclearfallout.australia-isp.example。
4.4. Remote Hosting
4.4. リモート接待
In the Instant Message hosting example in Section 4.3, the service owner (thinkingcat.example) had to host pointers to the hosting service's SRV records in the thinkingcat.example domain.
セクション4.3の例をホスティングするInstant Messageでは、サービス所有者(thinkingcat.example)はthinkingcat.exampleドメインでのホスティングサービスのSRV記録に指針を接待しなければなりませんでした。
A better approach is to have one NAPTR RR in the thinkingcat.example domain point to all the hosted services. The hosting domain has NAPTR records for each service to map them to whatever local hosts it chooses (this may change from time to time).
より良いアプローチはthinkingcat.exampleドメインの1NAPTR RRにすべての接待されたサービスを示させることです。 接待ドメインには、各サービスがそれが選ぶどんなローカル・ホストにもそれらを写像するNAPTR記録があります(これは時々変化するかもしれません)。
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service
"" ; regexp
thinkingcat.example.com. ; replacement
)
thinkingcat.example。 ;; オーダーpref旗IN NAPTR100 10の「s」「EM: ProtA」( ; サービス、「「;」 regexp_ProtA_tcp.thinkingcat.example。 ; 交換) NAPTR100 20、「「「EM:ProtB:ProtC」」( ; サービス、「「;」 regexp thinkingcat.example.com。 ; 交換)
Daigle & Newton Standards Track [Page 11] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[11ページ]。
Then the administrators at example.com can break out the individual application protocols and manage the preference rankings of the servers they use to support the ProtB service (as before):
次に、example.comの管理者は、ProtBがサービス(従来と同様)であるとサポートするために個々のアプリケーション・プロトコルを広げて、それらが使用するサーバの好みのランキングに対処できます:
thinkingcat.example.com.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtC" ( ; service
"" ; regexp
_ProtC._tcp.example.com. ; replacement
)
IN NAPTR 100 20 "s" "EM:ProtB" ( ; service
"" ; regexp
_ProtB._tcp.example.com. ; replacement
)
thinkingcat.example.com。 ;; オーダーpref旗IN NAPTR100 10の「s」「EM: ProtC」( ; サービス、「「;」 regexp_ProtC_tcp.example.com。 ; 交換) NAPTR100 20、「s」「EM: ProtB」( ; サービス、「「;」 regexp_ProtB_tcp.example.com。 ; 交換)
_ProtC._tcp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com. IN SRV 20 0 10001 backup.em.example.com. IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
_ProtC_tcp.example.com。 ;; Pref Weight Port Target IN SRV10 0 10001bigiron.example.com。 IN SRV、20 0 10001 backup.em.example.com。 IN SRV、30 0 10001 nuclearfallout.australia-isp.example。
4.5. Sets of NAPTR RRs
4.5. NAPTR RRsのセット
Note that the above sections assume that there was one service available (via S-NAPTR) per domain. Often, this will not be the case. Assuming that thinkingcat.example had the CredReg service set up as described in Section 4.2 and had the extensible messaging service set up as described in Section 4.4, then a client querying for the NAPTR RR set from thinkingcat.com would get the following answer:
上のセクションが、利用可能な(S-NAPTRを通した)1ドメインあたり1つのサービスがあったと仮定することに注意してください。 しばしば、これはそうになるというわけではないでしょう。 thinkingcat.exampleがセクション4.2で説明されるようにCredRegサービスセットを上がるようにして、セクション4.4で説明されるように広げることができるメッセージングサービスセットを上がるようにしたと仮定する場合、NAPTR RRセットのためにthinkingcat.comから質問しているクライアントは以下の答えを得るでしょう:
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service
"" ; regexp
thinkingcat.example.com. ; replacement
)
IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" ( ; service
"" ; regexp
bouncer.thinkingcat.example. ; replacement
)
thinkingcat.example。 ;; オーダーpref旗IN NAPTR100 10の「s」「EM: ProtA」( ; サービス、「「;」 regexp_ProtA_tcp.thinkingcat.example。 ; 交換) NAPTR100 20、「「「EM:ProtB:ProtC」」( ; サービス、「「;」 regexp thinkingcat.example.com。 ; 交換) NAPTR200 10、「「「CREDREG: ldap: 虹彩ビープ音」」( ; サービス、「「;」 regexp bouncer.thinkingcat.example。 ; 交換)
Daigle & Newton Standards Track [Page 12] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[12ページ]。
Sorting them by increasing "ORDER", the client would look through the SERVICE strings to determine whether there was a NAPTR RR that matched the application service it was looking for, with an application protocol it could use. The client would use the first (lowest PREF) record that matched to continue.
「オーダー」を増強することによってそれらを分類して、クライアントはそれが探していたアプリケーション・サービスに合っていたNAPTR RRがあったかどうか決定するためにサービスストリングに目を通すでしょう、それが使用できたアプリケーション・プロトコルで。 クライアントは続くように合っていた最初(最も低いPREF)の記録を使用するでしょう。
4.6. Sample sequence diagram
4.6. サンプルシーケンス線図
Consider the example in section 4.3. Visually, the sequence of steps required for the client to reach the final server for a "ProtB" service for EM for the thinkingcat.example domain is as follows:
セクション4.3で例を考えてください。 目視により、クライアントがthinkingcat.exampleドメインへのEMのための"ProtB"サービスのための最終的なサーバに達するのに必要であるステップの系列は以下の通りです:
Client NS for NS for
thinkingcat.example example.com backup.em.example.com
| | |
1 -------->| | |
2 <--------| | |
3 ------------------------------>| |
4 <------------------------------| |
5 ------------------------------>| |
6 <------------------------------| |
7 ------------------------------>| |
8 <------------------------------| |
9 ------------------------------------------------->|
10 <-------------------------------------------------|
11 ------------------------------------------------->|
12 <-------------------------------------------------|
(...)
thinkingcat.example example.com backup.em.example.comのためのNSのためのクライアントNS| | | 1 -------->|、|、| 2 <。--------| | | 3 ------------------------------>|、| 4 <。------------------------------| | 5 ------------------------------>|、| 6 <。------------------------------| | 7 ------------------------------>|、| 8 <。------------------------------| | 9 ------------------------------------------------->| 10 <。-------------------------------------------------| 11 ------------------------------------------------->| 12 <。-------------------------------------------------| (...)
1. The name server (NS) for thinkingcat.example is reached with a
request for all NAPTR records.
1. thinkingcat.exampleのためのネームサーバ(NS)にすべてのNAPTR記録に関する要求で達しています。
2. The server responds with the NAPTR records shown in section 4.3.
2. サーバはセクション4.3で示されるNAPTR記録で反応します。
3. The second NAPTR record matches the desired criteria; it has an
"s" flag and a replacement fields of "_ProtB._tcp.example.com".
So the client looks up SRV records for that target, ultimately
making the request of the NS for example.com.
3. 2番目のNAPTR記録は必要な評価基準に合っています。 「それには、」 _ProtB_tcp.example.comの「s」旗とa交換分野があります。」 それで、結局NS for example.comの要求をして、クライアントはその目標のためのSRV記録を調べます。
4. The response includes the SRV records listed in Section 4.3.
4. 応答はセクション4.3にリストアップされたSRV記録を含んでいます。
5. The client attempts to reach the server with the lowest PREF in
the SRV list -- looking up the A record for the SRV record's
target (bigiron.example.com).
5. SRV記録の目標(bigiron.example.com)のためのA記録を調べて、クライアントは、SRVリストで最も低いPREFと共にサーバに達するのを試みます。
6. The example.com NS responds with an error message -- no such
machine!
6. example.com NSはエラーメッセージで応じます--そのようなマシンでない!
Daigle & Newton Standards Track [Page 13] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[13ページ]。
7. The client attempts to reach the second server in the SRV list
and looks up the A record for backup.em.example.com.
7. クライアントは、SRVリストにおける2番目のサーバに達するのを試みて、backup.em.example.comのためのA記録を調べます。
8. The client gets the A record with the IP address for
backup.em.example.com from example.com's NS.
8. クライアントはexample.comのNSからbackup.em.example.comのためのIPアドレスがあるA記録を得ます。
9. The client connects to that IP address, on port 10001 (from the
SRV record), by using ProtB over tcp.
9. クライアントは、ポート10001(SRV記録からの)でtcpの上でProtBを使用することによって、そのIPアドレスに接続します。
10. The server responds with an "OK" message.
10. サーバは「OK」メッセージで反応します。
11. The client uses ProtB to challenge that this server has
credentials to operate the service for the original domain
(thinkingcat.example)
11. 挑戦するこのサーバが資格証明書を持っているクライアント用途ProtBは元のドメインのためのサービスを操作します。(thinkingcat.example)
12. The server responds, and the rest is EM.
12. サーバは反応します、そして、残りはEMです。
5. Motivation and Discussion
5. 動機と議論
Increasingly, application protocol standards use domain names to identify server targets and stipulate that clients should look up SRV resource records to determine the host and port providing the server. This enables a distinction between naming an application service target and actually hosting the server. It also increases flexibility in hosting the target service, as follows:
ますます、アプリケーションプロトコル標準は、サーバ目標を特定して、これがアプリケーション・サービス目標を命名することの間、そして、実際に区別を可能にするのを規定するのにサーバをホスティングしながら、ドメイン名を使用します。クライアントは、ホストとポートを決定するためにサーバを提供しながら、SRVリソース記録を調べるべきです。また、目標サービスを主催しながら、柔軟性を増やします、以下の通りです:
o The server may be operated by a completely different organization
without having to list the details of that organization's DNS
setup (SRVs).
o その組織のDNSセットアップ(SRVs)の詳細をリストアップする必要はなくて、サーバは完全に異なった組織によって運用されるかもしれません。
o Multiple instances can be set up (e.g., for load balancing or
secondaries).
o 複数のインスタンスをセットアップできます(例えば、ロードバランシングか代理人のために)。
o It can be moved from time to time without disrupting clients'
access, etc.
o クライアントのアクセスなどを混乱させないで、時々それを動かすことができます。
This approach is quite useful, but section 5.1 outlines some of its inherent limitations.
このアプローチはかなり役に立ちますが、セクション5.1は固有の制限のいくつかについて概説します。
That is, although SRV records can be used to map from a specific service name and protocol for a specific domain to a specific server, SRV records are limited to one layer of indirection and are focused on server administration rather than on application naming. Furthermore, although the DDDS specification and use of NAPTR allows multiple levels of redirection before the target server machine with an SRV record is located, this proposal requires only a subset of NAPTR strictly bound to domain names, without making use of the REGEXP field of NAPTR. These restrictions make the client's
すなわち、特定のドメインへの特定のサービス名とプロトコルから特定のサーバまでSRV記録を地図に使用できますが、SRV記録は、1つの層の間接指定に制限されて、アプリケーション命名に関してというよりむしろサーバ管理に焦点を合わせられます。 その上、SRV記録がある目標サーバマシンが見つけられる前にNAPTRのDDDS仕様と使用は複数のレベルのリダイレクションを許容しますが、この提案は厳密にドメイン名に縛られたNAPTRの部分集合だけを必要とします、NAPTRのREGEXP分野を利用しないで。 これらの制限はクライアントのものを作ります。
Daigle & Newton Standards Track [Page 14] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[14ページ]。
resolution process much more predictable and efficient than it would be with some potential uses of NAPTR records. This is dubbed "S- NAPTR" -- a "S"traightforward use of NAPTR records.
それよりはるかに予測できて効率的な解決プロセスがNAPTR記録のいくつかの潜在的用途であるでしょう。 これによるtraightforwardにa「S NAPTR」--「S」と呼ばれて、NAPTRの使用が記録するということです。
5.1. So Why Not Just SRV Records?
5.1. それで、なぜSRV記録であるだけではない?
An expected question at this point is: this is so similar in structure to SRV records, why are we doing this with DDDS/NAPTR?
ここの予期された質問は以下の通りです。 これは構造においてSRV記録ととても同様であり、私たちはなぜDDDS/NAPTRと共にこれをしていますか?
Limitations of SRV include the following:
SRVの限界は以下を含んでいます:
o SRV provides a single layer of indirection; the outcome of an SRV
lookup is a new domain name for which the A RR is to be found.
o SRVは単一層の間接指定を提供します。 SRVルックアップの結果はA RRが見つけられることになっている新しいドメイン名です。
o the purpose of SRV is to address individual server administration
issues, not to provide application naming: As stated in [3], "The
SRV RR allows administrators to use several servers for a single
domain, to move services from host to host with little fuss, and
to designate some hosts as primary servers for a service and
others as backups".
o SRVの目的はアプリケーション命名を提供するのではなく、個々のサーバ管理が問題であると扱うことです: [3]に述べられているように、「SRV RRは管理者に単一領域にいくつかのサーバを使用して、大騒ぎでサービスをホストからホストにほとんど動かさないで、バックアップとしてのサービスと他のもののためにプライマリサーバとして何人かのホストを任命させます」。
o Target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
"tcp") in a given domain. The definition of these terms implies
specific things (e.g., that protocol should be one of UDP or TCP)
without being precise. Restriction to UDP and TCP is insufficient
for the uses described here.
o 与えられたドメインの「サービス」(例えば、"ldap")と「プロトコル」(例えば、"tcp")でサーバを狙ってください。 正確でなくて、これらの用語の定義は特定のことを含意します(例えば、そのプロトコルはUDPかTCPの1つであるべきです)。 ここで説明された用途に、UDPとTCPへの制限は不十分です。
The basic answer is that SRV records provide mappings from protocol names to host and port. The use cases described herein require an additional layer -- from some service label to servers that may in be hosted within different administrative domains. We could tweak SRV to say that the next lookup could be something other than an address record, but this is more complex than is necessary for most applications of SRV.
基本的な答えはSRV記録がホスティングするプロトコル名とポートからマッピングを提供するということです。 ケースが説明した使用はあるサービスラベルから異なった管理ドメインの中で中でホスティングされるかもしれないサーバまでここに追加層を必要とします。 私たちは、次のルックアップがアドレス記録以外の何かであるかもしれませんが、これがSRVのほとんどのアプリケーションに必要とするより複雑な状態で多いと言うためにSRVをひねることができました。
5.2. So Why Not Just NAPTR Records?
5.2. それで、なぜNAPTR記録であるだけではない?
This is a trick question. NAPTR records cannot appear in the wild; see [4]. They must be part of a DDDS application.
これは落とし穴のある問題です。 NAPTR記録は荒野に現れることができません。 [4]を見てください。 それらはDDDSアプリケーションの一部であるに違いありません。
The purpose here is to define a single, common mechanism (the DDDS application) to use NAPTR when all that is desired is simple DNS- based location of services. This should be easy for applications to use -- a few simple IANA registrations, and it's done.
ここの目的がシングルを定義することであり、そのすべてが望まれているときNAPTRを使用する一般的なメカニズム(DDDSアプリケーション)はサービスの簡単なDNSベースの位置です。 そして、これがそうであるべきである、アプリケーションが使用する小休止--いくつかの簡単なIANA登録証明書、それをします。
Daigle & Newton Standards Track [Page 15] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[15ページ]。
Also, NAPTR has very powerful tools for expressing "rewrite" rules. This power (==complexity) makes some protocol designers and service administrators nervous. The concern is that these rewrites can translate into unintelligible, noodle-like rule sets that are difficult to test and administer.
また、NAPTRには、「書き直し」規則を表すための非常に強力なツールがあります。 このパワー(=複雑さ)で、何人かのプロトコルデザイナーとサービス管理者が神経質になります。 関心はこれらの書き直しにテストして、管理するのが難しい難解で、ヌードルのような規則セットに翻訳されることができるということです。
The proposed DDDS application specifically uses a subset of NAPTR's abilities. Only "replacement" expressions are allowed, not "regular expressions".
提案されたDDDSアプリケーションは明確にNAPTRの性能の部分集合を使用します。 「交換」式だけが「正規表現」でない許容されています。
6. Formal Definition of <Application Service Location> Application of
DDDS
6. DDDSの<アプリケーション・サービス位置の>アプリケーションの公式の定義
This section formally defines the DDDS application, as described in [4].
このセクションは[4]で説明されるように正式にDDDSアプリケーションを定義します。
6.1. Application-Unique String
6.1. アプリケーションユニークなストリング
The Application Unique String is domain label for which an authoritative server for a particular service is sought.
Application Unique Stringは特定のサービスのための正式のサーバが求められるドメインラベルです。
6.2. First Well-Known Rule
6.2. 最初のよく知られる規則
The "First Well-Known Rule" is identity -- that is, the output of the rule is the Application-Unique String, the domain label for which the authoritative server for a particular service is sought.
「最初のよく知られる規則」はアイデンティティです--すなわち、規則の出力はApplicationユニークなString(特定のサービスのための正式のサーバが求められるドメインラベル)です。
6.3. Expected Output
6.3. 予想された出力
The expected output of this Application is the information necessary for a client to connect to authoritative server(s) (host, port, protocol) for a particular application service within a given domain.
このApplicationの予想された出力はクライアントが与えられたドメインの中の特定用途サービスのために正式のサーバに接続する(ホスト、ポートは議定書を作ります)必要情報です。
6.4. Flags
6.4. 旗
This DDDS Application uses only 2 of the Flags defined for the URI/ URN Resolution Application ([6]): "S" and "A". No other Flags are valid.
このDDDS ApplicationはURI/URN Resolution Application([6])のために定義された2Flagsだけを使用します: 「S」と「A。」 他のどんなFlagsも有効ではありません。
Both are for terminal lookups. This means that the Rule is the last one and that the flag determines what the next stage should be. The "S" flag means that the output of this Rule is a domain label for which one or more SRV [3] records exist. "A" means that the output of the Rule is a domain name and should be used to lookup address records for that domain.
両方が端末のルックアップのためのものです。 これは、Ruleが最後のものであり、旗が、次のステージが何であるべきであるかを決定することを意味します。 「S」旗は、この規則の出力が1つ以上のSRV[3]記録が存在するドメインラベルであることを意味します。 「A」は、Ruleの出力がドメイン名であることを意味して、そのドメインにルックアップアドレス記録に使用されるべきです。
Consistent with the DDDS algorithm, if the Flag string is empty the next lookup is for another NAPTR record (for the replacement target).
DDDSアルゴリズムと一致しています、Flagストリングが空であるなら、次のルックアップは別のNAPTR記録(交換目標のための)のためのものです。
Daigle & Newton Standards Track [Page 16] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[16ページ]。
6.5. Service Parameters
6.5. サービスパラメタ
Service Parameters for this Application take the form of a string of characters that follow this ABNF ([2]):
このApplicationのためのサービスParametersはこのABNF([2])の後をつける一連のキャラクタの形を取ります:
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
ianaがサービスを登録している装置実験的なサービス/プロトコルサービス-parms=[装置サービス]*(「:」 装置プロトコル]装置サービス==「x」1*30ALPHANUMSYM実験プロトコルianaがプロトコルを登録している実験的な実験プロトコル/サービス==「x」アルファ*31ALPHANUMSYM ianaによって登録された1*30ALPHANUMSYM ianaによって登録されたサービス=プロトコル=アルファ*31ALPHANUMアルファー=%x41-5A/%x61-7A。 1Zの/1zのDIGIT=%x30-39。 0-9 SYM=%x2B/%x2D/%x2E。 "+" / "-" / "." ALPHANUMSYMはアルファ/ケタ/SYMと等しいです。 装置サービスと装置プロトコルタグは32に制限されます。 キャラクタと必須は英字から始まります。 ; サービス-parmsは大文字と小文字を区別しないと考えられます。
Thus, the Service Parameters may consist of an empty string, an app- service, or an app-service with one or more app-protocol specifications separated by the ":" symbol.
「したがって、Service Parametersが1以上がある装置プロトコル仕様が分離した空のストリング、装置サービス、または装置サービスから成るかもしれない、」、:、」 シンボル。
Note that this is similar to, but not the same as the syntax used in the URI DDDS application ([6]). The DDDS DNS database requires each DDDS application to define the syntax of allowable service strings. The syntax here is expanded to allow the characters that are valid in any URI scheme name (see [8]). As "+" (the separator used in the RFC3404 service parameter string) is an allowed character for URI scheme names, ":" is chosen as the separator here.
URI DDDSアプリケーション([6])で使用される構文と同様ですが、これが同じでないことに注意してください。 DDDS DNSデータベースは、許容できるサービスストリングの構文を定義するためにそれぞれのDDDSアプリケーションを必要とします。 ここの構文は、どんなURI体系名でも有効な状態でそうするキャラクタを許容するために広げられます。([8])を見てください。 「「+」 (RFC3404サービスパラメタストリングで使用される分離符)がURI体系名のための許容キャラクタであるので」:、」 分離符として、ここで、選ばれています。
6.5.1. Application Services
6.5.1. アプリケーション・サービス
The "app-service" must be an IANA-registered service; see Section 7 for instructions on registering new application service tags.
「装置サービス」はIANAによって登録されたサービスであるに違いありません。 新しいアプリケーション・サービスタグを登録する指示に関してセクション7を見てください。
6.5.2. Application Protocols
6.5.2. アプリケーション・プロトコル
The protocol identifiers valid for the "app-protocol" production are standard, registered protocols; see section 7 for instructions on registering new application protocol tags.
「装置プロトコル」生産に、有効なプロトコル識別子は標準の、そして、登録されたプロトコルです。 新しいアプリケーション・プロトコルタグを登録する指示に関してセクション7を見てください。
6.6. Valid Rules
6.6. 有効な規則
Only substitution Rules are permitted for this application. That is, no regular expressions are allowed.
代替だけRulesはこのアプリケーションのために受入れられます。 すなわち、正規表現は全く許容されていません。
Daigle & Newton Standards Track [Page 17] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[17ページ]。
6.7. Valid Databases
6.7. 有効なデータベース
At present only one DDDS Database is specified for this Application. [5] specifies that a DDDS Database using the NAPTR DNS resource record contain the rewrite rules. The Keys for this database are encoded as domain-names.
現在のところ、1DDDS DatabaseだけがこのApplicationに指定されます。 [5]は、NAPTR DNSリソース記録を使用するDDDS Databaseが書換規則を含むと指定します。 このデータベースのためのキーズはドメイン名としてコード化されます。
The First Well-Known Rule produces a domain name, and this is the Key used for the first look up. The NAPTR records for that domain are requested.
First Wellによって知られているRuleはドメイン名を生産します、そして、これは最初の外観において上がった状態で使用されるKeyです。 そのドメインのためのNAPTR記録は要求されています。
DNS servers MAY interpret Flag values and use that information to include appropriate NAPTR, SRV, or A records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See the Additional Information Processing section of [5] for more information on NAPTR records and the Additional Information section of a DNS response packet.
DNSサーバは、DNSパケットのAdditional情報部分に適切なNAPTR、SRV、またはA記録を含むのにFlag値を解釈して、その情報を使用するかもしれません。 クライアントは、追加情報がないかどうかチェックするよう奨励されますが、そうする必要はありません。 NAPTR記録に関する詳しい情報のための[5]のAdditional情報Processing部とDNS応答パケットのAdditional情報部を見てください。
7. IANA Considerations
7. IANA問題
This document calls for two IANA registries: one for application service tags, and one for application protocol tags.
このドキュメントは2つのIANA登録を求めます: アプリケーション・サービスタグのためのもの、およびアプリケーション・プロトコルタグのためのもの。
7.1. Application Service Tag IANA Registry
7.1. アプリケーション・サービスタグIANA登録
IANA has established and will maintain a registry for S-NAPTR Application Service Tags, listing at least the following information for each such tag:
そのような各タグのための少なくとも以下の情報をリストアップして、IANAは、確証して、S-NAPTR Application Service Tagsのために登録であると主張するでしょう:
o Application Service Tag: A string conforming with the IANA-
registered-service defined in section 6.5.
o アプリケーション・サービスタグ: セクション6.5で定義されたIANAの登録されたサービスに従う五弦。
o Defining publication: The RFC used to define the Application
Service Tag, as defined in the registration process, below.
o 公表を定義します: RFCは以前は以下の登録手続で定義されるようによくApplication Service Tagを定義していました。
An initial Application Service Tag registration is contained in [9].
初期のApplication Service Tag登録は[9]に含まれています。
7.2. Application Protocol Tag IANA Registry
7.2. アプリケーション・プロトコルタグIANA登録
IANA has established and will maintain a registry for S-NAPTR Application Protocol Tags, listing at least the following information for each such tag:
そのような各タグのための少なくとも以下の情報をリストアップして、IANAは、確証して、S-NAPTR ApplicationプロトコルTagsのために登録であると主張するでしょう:
o Application Protocol Tag: A string conforming with the iana-
registered-protocol defined in section 6.5.
o アプリケーション・プロトコルタグ: セクション6.5で定義されたianaの登録されたプロトコルに従う五弦。
Daigle & Newton Standards Track [Page 18] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[18ページ]。
o Defining publication: The RFC used to define the Application
Protocol Tag, as defined in the registration process, below.
o 公表を定義します: RFCは以前は以下の登録手続で定義されるようによくApplicationプロトコルTagを定義していました。
An initial Application Protocol Tag registration is defined in [10].
初期のApplicationプロトコルTag登録は[10]で定義されます。
7.3. Registration Process
7.3. 登録手続
All application service and protocol tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Implementors use them at their own risk.
実験的であると「x」から始まるすべてのアプリケーション・サービスとプロトコルタグを考えます、そして、同じストリングの写し使用を防ぐのを設備を全くしません。 作成者は自分の責任で彼らを使用します。
All other application service and protocol tags are registered based on the "specification required" option defined in [7], with the further stipulation that the "specification" is an RFC (of any category).
他のすべてのアプリケーション・サービスとプロトコルタグは「仕様が必要である」という[7]で定義されたオプションに基づいて登録されます、「仕様」がRFC(どんなカテゴリのも)であるというさらなる約款で。
No further restrictions are placed on the tags except that they must conform with the syntax defined below (Section 6.5).
それらが(セクション6.5)の下で定義された構文に従わなければならない以外に、さらなる制限は全くタグに関して課されません。
The defining RFC must clearly identify and describe, for each tag being registered,
RFCが登録される各タグのために明確に特定して、説明しなければならない定義
o application protocol or service tag,
o アプリケーション・プロトコルかサービスタグ
o intended usage,
o 意図している用法
o interoperability considerations,
o 相互運用性問題
o security considerations (see section 8 of this document for
further discussion of the types of considerations that are
applicable), and
o そしてセキュリティ問題(適切な問題のタイプのさらなる議論のためのこのドキュメントのセクション8を見る)。
o any relevant related publications.
o どんな関連関連する刊行物。
8. Security Considerations
8. セキュリティ問題
The security of this approach to application service location is only as good as the security of the DNS queries along the way. If any of them is compromised, bogus NAPTR and SRV records could be inserted to redirect clients to unintended destinations. This problem is hardly unique to S-NAPTR (or NAPTR in general). A full discussion of the security threats pertaining to DNS can be found in [11].
アプリケーション・サービス位置へのこのアプローチのセキュリティは単にDNSのセキュリティがずっと道について質問するのと同じくらい良いです。 それらのどれかが感染されるなら、にせのNAPTRとSRV記録は、意図しない行き先にクライアントを向け直すために挿入されるかもしれません。 この問題はS-NAPTR(または、一般に、NAPTR)にほとんどユニークではありません。 [11]で軍事的脅威がDNSに関係する十分な議論を見つけることができます。
To protect against DNS-vectored attacks, secured DNS (DNSSEC) [12] can be used to ensure the validity of the DNS records received.
DNS-vectored攻撃から守るなら、DNS記録の正当性が受信されたのを保証するのに機密保護しているDNS(DNSSEC)[12]を使用できます。
Daigle & Newton Standards Track [Page 19] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[19ページ]。
Whether or not DNSSEC is used, applications should define some form of end-to-end authentication to ensure that the correct destination has been reached. Many application protocols such as HTTPS, BEEP, and IMAP define the necessary handshake mechanisms to accomplish this task. Newly defined application protocols should take this into consideration and incorporate appropriate mechanisms.
DNSSECが使用されているか否かに関係なく、アプリケーションは、正しい目的地に達したのを保証するために終わりから終わりへの何らかの形式の認証を定義するべきです。 HTTPSや、BEEPや、IMAPなどの多くのアプリケーション・プロトコルが、このタスクを達成するために必要な握手メカニズムを定義します。 新たに定義されたアプリケーション・プロトコルは、これを考慮に入れて、適切な手段を組み込むべきです。
The basic mechanism works as follows:
基本的機構は以下の通り動作します:
1. During some portion of the protocol handshake, the client sends to
the server the original name of the desired destination (i.e., no
transformations that may have resulted from NAPTR replacements,
SRV targets, or CNAME changes). In certain cases where the
application protocol does not have such a feature but TLS may be
used, it is possible to use the "server_name" TLS extension.
1. プロトコル握手の何らかの部分の間、クライアントは必要な目的地(すなわち、NAPTR交換、SRV目標、またはCNAME変化から生じたかもしれない変換がない)のオリジナルの名前をサーバに送ります。 アプリケーション・プロトコルにはそのような特徴がありませんが、TLSが使用されるかもしれないある場合では、「サーバ_名前」TLS拡張子を使用するのは可能です。
2. The server sends back to the client a credential with the
appropriate name. For X.509 certificates, the name would be in
either the subjectDN or the subjectAltName field. For Kerberos,
the name would be a service principle name.
2. サーバは適切な名前で資格証明書をクライアントに送り返します。 X.509証明書に関しては、名前がsubjectDNかsubjectAltName分野のどちらかにあるでしょう。 ケルベロスのために、名前はサービス原則名でしょう。
3. Using the matching semantics defined by the application protocol,
the client compares the name in the credential with the name sent
to the server.
3. アプリケーション・プロトコルによって定義された合っている意味論を使用して、クライアントはサーバに送る名前に資格証明書における名前をたとえます。
4. If the names match and the credentials have integrity, there is
reasonable assurance that the correct end point has been reached.
4. 名前が合って、資格証明書に保全があるなら、正しいエンドポイントに達したという手頃な保証があります。
5. The client and server establish an integrity-protected channel.
5. クライアントとサーバは保全で保護されたチャンネルを確立します。
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.
このドキュメントが意味論を合わせながら握手メカニズム、分野を命名する特定の資格証明書、および名前を定義しないことに注意してください。 特定用途プロトコルのためのS-NAPTRの定義はこれらを定義しなければなりません。
9. Acknowledgements
9. 承認
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.
(希望をいだいて)!はっきりさせる改正を引き起こした議論と入力のためのデーヴBlacka、パトリクFaltstrom、サリー・フロイド、およびテッド・ハーディー、このドキュメントありがとうございます。
Daigle & Newton Standards Track [Page 20] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[20ページ]。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[2] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[3]Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
[4] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403, October
2002.
[5] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
2002.
[6] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)」、RFC3404、2002年10月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
10.2. Informative References
10.2. 有益な参照
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[8]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[9] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type
for the Internet Registry Information Service (IRIS)", RFC 3982,
January 2005.
[9] ニュートン、A.、およびM.サンス、「虹彩:」 「インターネット登録情報サービス(虹彩)のためのドメイン登録(かす)タイプ」、RFC3982、2005年1月。
[10] Newton, A. and M. Sanz, "Using the Internet Registry Information
Service (IRIS) over the Blocks Extensible Exchange Protocol
(BEEP)", RFC 3983, January 2005.
[10] ニュートン、A.、およびM.サンス、「インターネット登録情報サービス(虹彩)を広げることができるブロックの上使用して、プロトコルを交換してください(鳴ってください)」、RFC3983、2005年1月。
[11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
System", Work in Progress, April 2004.
[11] 「ドメインネームシステムの脅威分析」というアトキンス、D.、およびR.Austeinは進歩、2004年4月に働いています。
[12] Arends, R., Larson, M., Austein, R., and D. Massey, "Protocol
Modifications for the DNS Security Extensions", Work in
Progress, May 2004.
[12] Arends(R.、ラーソン、M.、Austein、R.、およびD.マッシー)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、処理中の作業、2004年5月。
Daigle & Newton Standards Track [Page 21] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[21ページ]。
Appendix A. Pseudo-Pseudocode for S-NAPTR
付録、S-NAPTRのためのA.疑似擬似コード
A.1. Finding the First (Best) Target
A.1。 最初に(最も良い)の目標を見つけます。
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.
特定用途サービスのためにクライアントサポートが1つのプロトコルであると仮定して、以下の擬似コードはクライアントのための最初に(最も良い)の目標を見つけるために予想された過程について概説します、S-NAPTRを使用して。
target = [initial domain] naptr-done = false
naptrによって行われた状態で、目標は[初期のドメイン]と= 虚偽で等しいです。
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]
(naptrによってされない)である、NAPTR-RRsetはrrによってされた=誤った野良犬-rr=と等しいです[目標のためのNAPTR RRsのDNSlookup][ORDERによる種類のNAPTR-RRset、および各ORDERの中のPREF]。[最初に、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]
[野良犬-rrのSERVICE分野は必要なアプリケーション・サービスとアプリケーション・プロトコルを含んでいます)rrによってされた=本当の目標が[NAPTR RRのREPLACEMENT目標]ほかの野良犬-rr=と等しいなら、ゆったり過ごします(rrによってされなかった)。[リストの次のrr]
if (not empty [FLAG in cur-rr])
naptr-done = true
}
(naptrによって行われた状態で、= 本当に[野良犬-rrのFLAG)を空にしません。
port = -1
ポートは-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]
}
[野良犬-rrのFLAGは「S」です])SRV-RRset=[目標のためのSRV RRsのDNSlookup][PREFに基づく種類のSRV-RRset]目標=[最初に、SRV-RRsetのRRの目標]ポートは[SRV-RRsetの最初のRRのポート]と等しいです。
; now, whether it was an "S" or an "A" in the NAPTR, we ; have the target for an A record lookup
; さあ、それが「S」であったかどうかかNAPTRの「A」、私たち。 A記録ルックアップのための目標を持ってください。
Daigle & Newton Standards Track [Page 22] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[22ページ]。
host = [DNSlookup of target]
ホスト=[目標のDNSlookup]
return (host, port)
リターン(ホスト、ポート)
A.2. Finding Subsequent Targets
A.2。 その後の目標を見つけます。
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.
Appendix Aの擬似コードは、特定用途サービスとプロトコルに関して1番目、ほとんどの都合のよいホストポート組を見つけるために作られます。 そのホストポート組がどんな理由でも働いていなかったなら(接続は拒否しました、アプリケーションレベル誤り)、クライアントがS-NAPTR木で隣のホストポートを試すと予想されます。
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
上記の擬似コードは再試行を可能にしません--かつて完全です、それはS-NAPTR木では、それが終わったところのすべての文脈をはじきます。 したがって、クライアントソフトウェア作者はそうすることができました。
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 DNSルックアップとRRset処理が擬似コードで説明されている状態で、アプリケーション特有のプロトコルをからませてください、そして、応用コードが見つけられたホストポート組に接しないなら、S NAPTR処理を続けてください。
o use callbacks for the S-NAPTR processing; or
o S-NAPTR処理に回収を使用してください。 または
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.
o 必要なアプリケーション・サービスとプロトコルに関して由来しているドメインから*がすべて、*有効なサーバであることがわかって、アプリケーションが試みる分類された命令にそれらを前提とするS-NAPTR解決ルーチンを使用してください。
Appendix B. Availability of Sample Code
サンプルコードの付録B.の有用性
Sample Python code for S-NAPTR resolution is available from http://www.verisignlabs.com/pysnaptr-0.1.tgz
S-NAPTR解決のためのサンプルパイソンコードは http://www.verisignlabs.com/pysnaptr-0.1.tgz から利用可能です。
Daigle & Newton Standards Track [Page 23] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[23ページ]。
Authors' Addresses
作者のアドレス
Leslie Daigle VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
レスリーDaigleベリサインInc.21355屋根の頂円のヴァージニア20166ダレス(米国)
EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
メール: leslie@verisignlabs.com; leslie@thinkingcat.com
Andrew Newton VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
アンドリューニュートンベリサインInc.21355屋根の頂円のヴァージニア20166ダレス(米国)
EMail: anewton@verisignlabs.com
メール: anewton@verisignlabs.com
Daigle & Newton Standards Track [Page 24] RFC 3958 DDDS January 2005
DaigleとニュートンStandardsはDDDS2005年1月にRFC3958を追跡します[24ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Daigle & Newton Standards Track [Page 25]
Daigleとニュートン標準化過程[25ページ]
一覧
スポンサーリンク
