aboutsummaryrefslogtreecommitdiff
path: root/doc/draft/draft-daigle-napstr-04.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/draft/draft-daigle-napstr-04.txt')
-rw-r--r--doc/draft/draft-daigle-napstr-04.txt1232
1 files changed, 0 insertions, 1232 deletions
diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt
deleted file mode 100644
index fffa8a5f20b3..000000000000
--- a/doc/draft/draft-daigle-napstr-04.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-Network Working Group L. Daigle
-Internet-Draft A. Newton
-Expires: August 15, 2004 VeriSign, Inc.
- February 15, 2004
-
-
- Domain-based Application Service Location Using SRV RRs and the
- Dynamic Delegation Discovery Service (DDDS)
- draft-daigle-napstr-04.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 15, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-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 to target
- server and port, dynamically.
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 1]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . 4
- 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . . 5
- 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . . . . 5
- 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . . . . 5
- 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . . . . 5
- 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . . . . 6
- 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . . . . 6
- 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.1 Guidelines for Application Protocol Developers . . . . . . . 7
- 3.1.1 Registration of application service and protocol tags . . . 7
- 3.1.2 Definition of conditions for retry/failure . . . . . . . . . 8
- 3.1.3 Server identification and handshake . . . . . . . . . . . . 8
- 3.2 Guidelines for Domain Administrators . . . . . . . . . . . . 8
- 3.3 Guidelines for Client Software Writers . . . . . . . . . . . 9
- 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . 9
- 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 4.2 Service Discovery within a Domain . . . . . . . . . . . . . 10
- 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
- 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
- 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 12
- 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . . 12
- 5. Motivation and Discussion . . . . . . . . . . . . . . . . . 14
- 5.1 So, why not just SRV records? . . . . . . . . . . . . . . . 15
- 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . . 15
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 16
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
- References . . . . . . . . . . . . . . . . . . . . . . . . . 17
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
- A. Application Service Location Application of DDDS . . . . . . 18
- A.1 Application Unique String . . . . . . . . . . . . . . . . . 18
- A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 18
- A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 18
- A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
- A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
- A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 20
- A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 20
- A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 20
- B. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . 20
- B.1 Finding the first (best) target . . . . . . . . . . . . . . 20
- B.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 21
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 2]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-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 [6]) Application to
- map domain name, application service name, and application protocol
- to target server and port, dynamically.
-
- As discussed in Section 5, existing approaches to using DNS records
- to 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 using both
- NAPTR [7] and SRV ([5]) 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 RFC2119 ([2]).
-
-2. Straightforward-NAPTR (S-NAPTR) Specification
-
- The precise details of the specification of this DDDS application are
- given in Appendix A. This section defines the usage of the DDDS
- application.
-
-2.1 Key Terms
-
- An "application service" is a generic term for some type of
- application, indpendent of the protocol that may be used to offer it.
- Each application service will be associated with an IANA-registered
- tag. For example, instant messaging is a type of application
- service, which can be implemented by many different application-layer
- protocols, and the tag "IM" (used as an illustration here) could be
- registered for it.
-
- An "application protocol" is used to implement the application
- service. These are also associated with IANA-registered tags. In
- the case where 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., "IM:ProtC") is sufficient for a client to identify a server
- with which it can communicate.
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 3]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- 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", etc).
-
-2.2 S-NAPTR DDDS Application Usage
-
- As outlined in Appendix A, 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.
-
- example.com.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "WP:whois++" "" bunyip.example.
- IN NAPTR 100 20 "s" "WP:ldap" "" _ldap._tcp.myldap.example.com.
- IN NAPTR 200 10 "" "IM:protA" "" someisp.example.
- IN NAPTR 200 30 "a" "IM:protB" "" myprotB.example.com.
-
-
-2.2.1 Ordering and Preference
-
- A client retrieves all of 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
-
- 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, that 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.
-
-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.
-
- In S-NAPTR, the only terminal flags are "S" and "A". These are
- called "terminal" NAPTR lookups because they denote the end of the
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 4]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- 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
-
- As shown in the example NAPTR RR 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 to terminal lookups and servers contacted.
- 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
-
- o the designated remote server (host and port) fail 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
-
- 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.
-
- An application client first queries for the NAPTR RRs for the domain
- of a named application service. The application client MUST select
- one protocol to choose The PREF field of the NAPTR RRs may be used by
- the domain administrator to The first DNS query is for the NAPTR RRs
- in the original target domain (example.com, above).
-
-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 before trying another.j It MAY
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 5]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- choose which protocol to try first based on its own preference, or
- from 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.
-
- That is, what the client MUST NOT do is 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 "IM"
- service with protocol "ProtB", there is no reason to believe it does
- so on behalf of example.com (since there is no such pointer in
- example.com's NAPTR RR set).
-
-3. Guidelines
-
-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.
-
- 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.
-
- Specifically not addressed in this document is how to select the
- domain for which the service+protocol is being sought. It is up to
- other conventions to define how that might be used (e.g., instant
- messaging standards can define what domain to use from IM URIs, how
- to step down from foobar.example.com to example.com, and so on, if
- that is applicable).
-
- Although this document proposes a DDDS application that does not use
- all the features of NAPTR resource records, it does not mean 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 in order to make use of S-
- NAPTR.
-
-3.1.1 Registration of application service and protocol tags
-
- Application protocol developers that wish to make use of S-NAPTR must
- make provision to register any relevant application service and
- application protocol tags, as described in Section 6.
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 6]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-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 (a less preferred target)?
-
- For example, if the client gets a "connection refused" 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.
-
- As noted earlier, failure to provide appropriate credentials to
- identify the server as being authoritative for the original taret
- domain is always considered a failure condition.
-
-3.1.3 Server identification and handshake
-
- As noted in Section 7, 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.
-
-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.
-
- 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 that are "reachable" through
- the S-NAPTR process for a particular application service can be
- thought of as a "tree". Each NAPTR RR 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
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 7]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- 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,
-
- 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, etc), but don't look for
- reasons to provide more.
-
- 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
-
- To properly understand DDDS/NAPTR, an implementor must read [6].
- However, the most important aspect to keep in mind is that, if one
- target fails to work for the application, it is expected that the
- application will continue through the S-NAPTR tree to try the (less
- preferred) alternatives.
-
-4. Illustrations
-
-4.1 Use Cases
-
- The basic intended use cases for which S-NAPTR has been developed
- are:
-
- 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 increasingly common as new
- application services are defined. This includes the case of
- instant messaging (a 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.
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 8]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-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", because 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. Here's a hypothetical case for storing application key or
- certificate data for a given domain. The premise is that some
- credentials registry (CredReg) service has been defined to be a leaf
- node service holding the keys/certs for the servers operated by (or
- for) the domain. Furthermore, 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.
-
- Thus, the set of NAPTR records for thinkingcat.example might look
- like this:
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" theserver.thinkingcat.example.
-
- Note that another domain, offering the same application service,
- might offer it using a different set of application protocols:
-
- anotherdomain.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" foo.anotherdomain.example.
-
-
-4.3 Multiple Protocols
-
- As it stands, there are several different protocols proposed for
- offering "instant message" services. Assuming that "IM" was
- registered as an application service, this DDDS application could be
- used to determine the available services for delivering to a target.
-
- Two particular features of instant messaging should be noted:
-
- 1. gatewaying is expected to bridge communications across protocols
-
- 2. instant messaging servers are likely to be operated out of a
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 9]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- different domain than the instant 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" instant messaging protocol, but rely on outsourcing from
- "example.com" for "ProtC" and "ProtB" servers.
-
- Using this DDDS-based approach, thinkingcat.example can indicate a
- preference ranking for the different types of servers for the instant
- messaging service, and 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.
-
- Thus, to find the IM services for thinkingcat.example, the NAPTR
- records for thinkingcat.example are retrieved:
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
- IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com.
- IN NAPTR 100 30 "s" "IM:ProtC" "" _ProtC._tcp.example.com.
-
- and then the administrators at example.com can manage the preference
- rankings of the servers they use to support the ProtB service:
-
- _ProtB._tcp.example.com.
- ;; Pref Weight Port Target
- IN SRV 10 0 10001 bigiron.example.com
- IN SRV 20 0 10001 backup.im.example.com
- IN SRV 30 0 10001 nuclearfallout.australia-isp.example
-
-
-4.4 Remote Hosting
-
- 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.
-
- A better way to approach this is to have one NAPTR RR in the
- thinkingcat.example domain pointing to all the hosted services, and
- the hosting domain has NAPTR records for each service to map them to
- whatever local hosts it chooses (and may change from time to time).
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 10]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
- IN NAPTR 100 20 "" "IM:ProtB:ProtC" "" thinkingcat.example.com.
-
-
- and 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):
-
- thinkingcat.example.com.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtC" "" _ProtC._tcp.example.com.
- IN NAPTR 100 20 "s" "IM:ProtB" "" _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.im.example.com
- IN SRV 30 0 10001 nuclearfallout.australia-isp.example
-
-
-4.5 Sets of NAPTR RRs
-
- Note that the above sections assumed that there was one service
- available (via S-NAPTR) per domain. Often, that will not be the
- case. Assuming thinkingcat.example had the CredReg service set up as
- described in Section 4.2 and the instant 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:
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
- IN NAPTR 100 20 "" "IM:ProtB:ProtC:" "" thinkingcat.example.com.
- IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.
-
- Sorting them by increasing "ORDER", the client would look through the
- SERVICE strings to determine if there was a NAPTR RR that matched the
- application service it was looking for, with an application protocol
- it could use. The first (lowest PREF) record that so matched is the
- one the client would use to continue.
-
-4.6 Sample sequence diagram
-
- Consider the example in Section 4.3. Visually, the sequence of steps
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 11]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- required for the client to reach the final server for a "ProtB"
- service for IM for the thinkingcat.example domain is as follows:
-
-
- Client NS for NS for
- thinkingcat.example example.com backup.im.example.com
- | | |
- 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
-
- 2. the server responds with the NAPTR records shown in Section 4.3.
-
- 3. the second NAPTR record matches the desired criteria; that 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.
-
- 4. the response includes the SRV records listed in Section 4.3.
-
- 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).
-
- 6. the example.com NS responds with an error message -- no such
- machine!
-
- 7. the client attempts to reach the second server in the SRV list,
- and looks up the A record for backup.im.example.com
-
- 8. the client gets the A record with the IP address for
- backup.im.example.com from example.com's NS.
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 12]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- 9. the client connects to that IP address, on port 10001 (from the
- SRV record), using ProtB over tcp.
-
- 10. the server responds with an "OK" message.
-
- 11. the client uses ProtB to challenge that this server has
- credentials to operate the service for the original domain
- (thinkingcat.example)
-
- 12. the server responds, and the rest is IM.
-
-
-5. Motivation and Discussion
-
- Increasingly, application protocol standards are using domain names
- to identify server targets, and stipulating 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:
-
- 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 multiple instances can be set up (e.g., for load balancing or
- secondaries)
-
- o it can be moved from time to time without disrupting clients'
- access, etc.
-
- This is quite useful, but Section 5.1 outlines some of the
- limitations inherent in the approach.
-
- That is, while 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. And, while
- the DDDS specification and use of NAPTR allows multiple levels of
- redirection before locating the target server machine with an SRV
- record, 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 resolution process much more
- predictable and efficient than with some potential uses of NAPTR
- records. This is dubbed "S-NAPTR" -- a "S"traightforward use of
- NAPTR records.
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 13]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-5.1 So, why not just SRV records?
-
- An expected question at this point is: this is so similar in
- structure to SRV records, why are we doing this with DDDS/NAPTR?
-
- Limitations of SRV include:
-
- 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 the purpose of SRV is focused on individual server administration,
- not application naming: as stated in [5] "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 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.
-
- 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
- fact 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 that is more complex than is necessary for
- most applications of SRV.
-
-5.2 So, why not just NAPTR records?
-
- That's a trick question. NAPTR records cannot appear in the wild --
- see [6]. They must be part of a DDDS application.
-
- 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 -- some simple IANA registrations and it's done.
-
- Also, NAPTR has very powerful tools for expressing "rewrite" rules.
- That power (==complexity) makes some protocol designers and service
- administrators nervous. The concern is that it can translate into
- unintelligible, noodle-like rule sets that are difficult to test and
- administer.
-
- This proposed DDDS application specifically uses a subset of NAPTR's
- abilities. Only "replacement" expressions are allowed, not "regular
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 14]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- expressions".
-
-6. IANA Considerations
-
- This document calls for 2 IANA registries: one for application
- service tags, and one for application protocol tags.
-
- Application service and protocol tags should be defined in an RFC
- (unless the "x-" experimental form is used, in which case they are
- unregistered). There are no restrictions placed on the tags other
- than that they must conform with the syntax defined below (Appendix
- A.5). The IANA registries should list the tags and the RFC that
- defines their use.
-
-7. Security Considerations
-
- The security of this approach to application service location is only
- as good as the security of the DNS servers 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).
-
- To protect against DNS-vectored attacks, 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, IMAP, etc... define the necessary handshake mechansims
- to accomplish this task.
-
- The basic mechanism works in the following way:
-
- 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.
-
- 2. The server sends back to the client a credential with the
- appropriate name. For X.509 certificates, the name would either
- be in the subjectDN or subjectAltName fields. For Kerberos, the
- name would be a service principle name.
-
- 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.
-
- 4. If the names match, there is reasonable assurance that the
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 15]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- correct end point has been reached.
-
- It is important to note that this document does not define either the
- handshake mechanism, the specific credenential naming fields, nor the
- name matching semantics. Definitions of S-NAPTR for particular
- application protocols MUST define these.
-
-8. Acknowledgements
-
- Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
- discussion and input that has (hopefully!) provoked clarifying
- revisions of this document.
-
-References
-
- [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
- Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [4] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
- [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- One: The Comprehensive DDDS", RFC 3401, October 2002.
-
- [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- Three: The Domain Name System (DNS) Database", RFC 3403, October
- 2002.
-
- [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
- 2002.
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 16]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-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
-
-Appendix A. Application Service Location Application of DDDS
-
- This section defines the DDDS application, as described in [6].
-
-A.1 Application Unique String
-
- The Application Unique String is domain label for which an
- authoritative server for a particular service is sought.
-
-A.2 First Well Known Rule
-
- 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.
-
-A.3 Expected Output
-
- The expected output of this Application is the information necessary
- to connect to authoritative server(s) (host, port, protocol) for an
- application service within a given a given domain.
-
-A.4 Flags
-
- This DDDS Application uses only 2 of the Flags defined for the
- URI/URN Resolution Application ([8]): "S" and "A". No other Flags
- are valid.
-
- 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
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 17]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- "S" flag means that the output of this Rule is a domain label for
- which one or more SRV [5] 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.
-
- Consistent with the DDDS algorithm, if the Flag string is empty the
- next lookup is for another NAPTR record (for the replacement target).
-
-A.5 Service Parameters
-
- Service Parameters for this Application take the form of a string of
- characters that follow this ABNF ([3]):
-
- 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.
-
- Thus, the Service Parameters may consist of an empty string, just an
- app-service, or an app-service with one or more app-protocol
- specifications separated by the ":" symbol.
-
- Note that this is similar to, but not the same as the syntax used in
- the URI DDDS application ([8]). 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 [1]). Since "+" (the separator used in the
- RFC3404 service parameter string) is an allowed character for URI
- scheme names, ":" is chosen as the separator here.
-
-A.5.1 Application Services
-
- The "app-service" must be a registered service [this will be an IANA
- registry; this is not the IANA port registry, because we want to
- define services for which there is no single protocol, and we don't
- want to use up port space for nothing].
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 18]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-A.5.2 Application Protocols
-
- The protocol identifiers that are valid for the "app-protocol"
- production are any standard, registered protocols [IANA registry
- again -- is this the list of well known/registered ports?].
-
-A.6 Valid Rules
-
- Only substitution Rules are permitted for this application. That is,
- no regular expressions are allowed.
-
-A.7 Valid Databases
-
- At present only one DDDS Database is specified for this Application.
- [7] specifies a DDDS Database that uses the NAPTR DNS resource record
- to contain the rewrite rules. The Keys for this database are encoded
- as domain-names.
-
- The First Well Known Rule produces a domain name, and this is the Key
- that is used for the first lookup -- the NAPTR records for that
- domain are requested.
-
- 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 [7] for more
- information on NAPTR records and the Additional Information section
- of a DNS response packet.
-
-Appendix B. Pseudo pseudocode for S-NAPTR
-
-B.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]
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 19]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- 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)
-
-
-
-B.2 Finding subsequent targets
-
- The pseudocode in Appendix B is crafted to find the first, most
- preferred, host-port pair for a particular application service an
- 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;
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 20]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- o use callbacks for the S-NAPTR processing;
-
- o use an S-NAPTR resolution routine that finds *all* valid servers
- for the required application service and protocol from the
- originating domain, and provides them in sorted order for the
- application to try in order.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 21]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 22]
-