home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-svrloc-discovery-03.txt < prev    next >
Text File  |  1997-09-15  |  32KB  |  900 lines
  1.  
  2.  
  3.  
  4.  
  5. Internet-Draft                                                Ryan Moats
  6. draft-ietf-svrloc-discovery-02.txt                                  AT&T
  7. Expires in six months                                    Martin Hamilton
  8.                                                  Loughborough University
  9.                                                            Paul J. Leach
  10.                                                                Microsoft
  11.                                                                June 1997
  12.  
  13.  
  14.                              Finding Stuff
  15.                        (How to discover services)
  16.               Filename: draft-ietf-svrloc-discovery-02.txt
  17.  
  18.  
  19. Status of This Memo
  20.  
  21.       This document is an Internet-Draft.  Internet-Drafts are working
  22.       documents of the Internet Engineering Task Force (IETF), its
  23.       areas, and its working groups.  Note that other groups may also
  24.       distribute working documents as Internet-Drafts.
  25.  
  26.       Internet-Drafts are draft documents valid for a maximum of six
  27.       months and may be updated, replaced, or obsoleted by other
  28.       documents at any time.  It is inappropriate to use Internet-
  29.       Drafts as reference material or to cite them other than as ``work
  30.       in progress.''
  31.  
  32.       To learn the current status of any Internet-Draft, please check
  33.       the ``1id-abstracts.txt'' listing contained in the Internet-
  34.       Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
  35.       (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  36.       Coast), or ftp.isi.edu (US West Coast).
  37.  
  38.  
  39. Abstract
  40.  
  41.    This document proposes a solution to the problem of finding
  42.    information about that services are being offered at a particular
  43.    Internet domain.  Therefore, it is possible for clients, using this
  44.    approach, to locate services in a domain with only prior knowledge of
  45.    the domain name.
  46.  
  47.  
  48. 1. Rationale
  49.  
  50.    Currently, there is no one single way of discovering the network
  51.    services and application protocols supported at a particular Internet
  52.    domain.  The Domain Name System (DNS) provides some basic facilities
  53.  
  54.  
  55.  
  56. Expires 12/31/97                                                [Page 1]
  57.  
  58.  
  59.  
  60.  
  61.  
  62. INTERNET DRAFT               Finding Stuff                     June 1997
  63.  
  64.  
  65.    for finding the hosts that offer particular services, such as DNS
  66.    servers themselves (NS records), mail exchangers (MX records [3]).
  67.    Recently general service records (SRV records [1]) have been proposed
  68.    for DNS, along with storing geographic information (LOC records [6]).
  69.    In addition, there are evolving methods for doing service location
  70.    via other methods [4] & [5].
  71.  
  72.    This document sets forth a process to rationalize how a client could
  73.    use these various methods for service location.  In this process, the
  74.    use of the Service Location Protocol [4] is highlighted to allow
  75.    clients to discover services by characteristics rather than by type
  76.    alone.  With the use of SRVs alone, all services are assumed to be
  77.    identical except for weight.  While this may be the case at some
  78.    locations, SLP will still be useful as it provides a dynamic
  79.    registration framework for services.
  80.  
  81.  
  82. 2. The process
  83.  
  84.    This process is an aggregation of several different ideas.  To
  85.    explicitly point out which ideas are being used, the steps of the
  86.    process have been grouped by section according to which technique is
  87.    being used.
  88.  
  89.    For a client in domain "srcdom" that wants to locate service
  90.    "service" in domain "tgtdom", the following process should be
  91.    followed.  The steps of this process are numbered and should be
  92.    explicitly followed (i.e. do step 1, then 2, etc.).
  93.  
  94. 2.1 Support for "Sites" Alias Structure (see Appendix A)
  95.  
  96.       1. If "srcdom" is of the form "<site>@<org-domain-name>" and
  97.       "<org-domain-name>" is a suffix of "tgtdom", then do steps 2
  98.       through 9 with "target" set to "<site>.sites.<domain-name>".  If
  99.       this procedure fails or the condition is not met, set "target" to
  100.       "tgtdom".
  101.  
  102. 2.2 Support for SVRLOC
  103.  
  104.       2. If "srcdom" == "target" and the client supports it, use the
  105.       Service Location Protocol to determine if the service can be found
  106.       that way.
  107.  
  108.       3. If the client supports Service Location Protocol, look for SRV
  109.       records [1] for a directory agent (i.e. da.udp."target" or
  110.       da.tcp."target").  This consists of:
  111.  
  112.       3a. Do a lookup of QNAME=da.tcp.target, QCLASS=IN, QTYPE=SRV.
  113.  
  114.  
  115.  
  116. Expires 12/31/97                                                [Page 2]
  117.  
  118.  
  119.  
  120.  
  121.  
  122. INTERNET DRAFT               Finding Stuff                     June 1997
  123.  
  124.  
  125.       3b. If the reply is NOERROR, ANCOUNT>0 and there is at least one
  126.       SRV RR that specifies the requested Service and Protocol in the
  127.       reply:
  128.  
  129.         If there is precisely one SRV RR, and its Target is "." (the
  130.         root domain), go to step 3c.
  131.  
  132.         For all SRV RR's build a list of (Priority, Weight, Target)
  133.         tuples and sort the list by priority (lowest number first).
  134.  
  135.         Create a new empty list.
  136.  
  137.         For each distinct priority level:
  138.  
  139.           For each element at this priority level:
  140.             While there are still elements left at this priority level,
  141.             select an element randomly, with probability weight, and
  142.             move it to the tail of the new list.
  143.  
  144.           For each element in the new list:
  145.             Query the DNS for A RR's for the target or use any RR's
  146.             found in the additional data section of the earlier SRV
  147.             query.
  148.  
  149.             For each A RR found, try to connect to the directory agent
  150.             using the Service Location Protocol over TCP.
  151.  
  152.       3c. Else do a lookup of QNAME=da.udp.target, QCLASS=IN, QTYPE=SRV.
  153.  
  154.       3d. Process the reply as in 3b, except that if there is precisely
  155.       one SRV RR with a target of ".", go to step 4 and connections to
  156.       the directory agent use Service Location Protocol over UDP.
  157.  
  158. 2.3 Support for SRV records
  159.  
  160.       4. Look for SRV records for service.protocol.target, where
  161.       protocol is whichever protocol (TCP or UDP) is associated with
  162.       service.  This consists of:
  163.  
  164.       4a. Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
  165.       QTYPE=SRV.
  166.  
  167.       4b. If the reply is NOERROR, ANCOUNT>0 and there is at least one
  168.       SRV RR that specifies the requested Service and Protocol in the
  169.       reply:
  170.  
  171.         If there is precisely one SRV RR, and its Target is "." (the
  172.         root domain), go to step 5.
  173.  
  174.  
  175.  
  176. Expires 12/31/97                                                [Page 3]
  177.  
  178.  
  179.  
  180.  
  181.  
  182. INTERNET DRAFT               Finding Stuff                     June 1997
  183.  
  184.  
  185.         For all SRV RR's, build a list of (Priority, Weight, Target)
  186.         tuples and sort the list by priority (lowest number first).
  187.  
  188.         Create a new empty list.
  189.  
  190.         For each distinct priority level:
  191.  
  192.           For each element at this priority level:
  193.             Query the DNS for LOC RR [6] for the Target (if not found in
  194.             the Additional Data section of the earlier SRV query).
  195.  
  196.             Find the nearest target and all targets "close" to the
  197.             nearest target (target to target distance less than 2-3% of
  198.             client to nearest target distance).
  199.  
  200.             Remove all other targets at this priority level.
  201.  
  202.             While there are still elements left at this priority level,
  203.             select an element randomly, with probability weight, and
  204.             move it to the tail of the new list.
  205.  
  206.           For each element in the new list:
  207.             Query the DNS for A RR's for the Target or use any RR's
  208.             found in the Additional Data section of the earlier SRV
  209.             query.
  210.  
  211.             For each A RR found, if the protocol is TCP (connection-
  212.             oriented) try to connect to the (protocol, address,
  213.             service); if the protocol is UDP, send a service request.
  214.  
  215.       5. If the service desired is SMTP, skip to RFC 974 (MX records)
  216.       else go to step 6.
  217.  
  218. 2.3 Support for "Well Known" Aliases
  219.  
  220.       6. If the service has a "well known" alias (see [2]) service',
  221.       look for A RRs for service'.target.  This is done in the following
  222.       way:
  223.  
  224.       6a. Do a lookup for QNAME=service'.target, QCLASS=IN, QTYPE=A.
  225.  
  226.         If no A RR's returned, go to step 7.
  227.  
  228.         For each A RR found, try to connect to the (protocol, address,
  229.         service).  If successful, stop.
  230.  
  231.         If all A RR's have been tried go to step 7.
  232.  
  233.  
  234.  
  235.  
  236. Expires 12/31/97                                                [Page 4]
  237.  
  238.  
  239.  
  240.  
  241.  
  242. INTERNET DRAFT               Finding Stuff                     June 1997
  243.  
  244.  
  245. 2.4 Support for Service Advertising via Service URLs
  246.  
  247.       7. Look for "service:" URLs stored in TXT RRs for service.target:
  248.  
  249.       7a. Do a lookup for QNAME=service.target, QCLASS=IN, QTYPE=TXT.
  250.  
  251.         If no TXT RR's returned, go to step 8.
  252.  
  253.         For each TXT RR found, try to connect to the (address, port)
  254.         specified in the service: URL. If successful, stop.
  255.  
  256.         If all TXT RR's have been tried go to step 8.
  257.  
  258.       8. Look for "service:" URLs stored in TXT RRs for target:
  259.  
  260.       8a. Do a lookup for QNAME=target, QCLASS=IN, QTYPE=TXT.
  261.  
  262.         If no TXT RR's returned, go to step 9.
  263.  
  264.         For each TXT RR found, try to connect to the (address, port)
  265.         specified in the service: URL. If successful, stop.
  266.  
  267.         If all TXT RR's have been tried go to step 9.
  268.  
  269. 2.5 Fallback
  270.  
  271.       9. Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
  272.  
  273.         For each A RR found, try to connect to the (protocol, address,
  274.         service).  If successful, stop.
  275.  
  276.  
  277. 3. Security Considerations
  278.  
  279.    Because of the suggested mechanisms for service discovery, this
  280.    document inherits all the security considerations of using DNS RR's
  281.    and the Service Location Protocol.  Implementors should consider both
  282.    [7] and the security section of [4] for appropriate methods.
  283.  
  284.  
  285. 4. Conclusion
  286.  
  287.    By following the above process, a client may be reasonably certain of
  288.    determining whether a particular service is provided for a particular
  289.    domain name, given the domain name.
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296. Expires 12/31/97                                                [Page 5]
  297.  
  298.  
  299.  
  300.  
  301.  
  302. INTERNET DRAFT               Finding Stuff                     June 1997
  303.  
  304.  
  305. 5. Acknowledgments
  306.  
  307.    This document is partially supported by the National Science
  308.    Foundation, Cooperative Agreement NCR-9218179, the UK Electronic
  309.    Libraries Programme (eLib) grant 12/39/01, and the European
  310.    Commission's Telematics for Research Programme grant RE 1004.
  311.  
  312.  
  313. 6. References
  314.  
  315.    Request For Comments (RFC) and Internet Draft documents are available
  316.    from <URL:ftp://ftp.internic.net> and numerous mirror sites.
  317.  
  318.          [1]         A. Gulbrandsen, P. Vixie, "A DNS RR for specifying
  319.                      the location of services (DNS SRV)," RFC 2052,
  320.                      October 1996.
  321.  
  322.  
  323.          [2]         M. Hamilton, R. Wright,  "Use of DNS Aliases for
  324.                      Network Services," Internet Draft (work in pro-
  325.                      gress), June 1996.
  326.  
  327.  
  328.          [3]         S. C. Partridge, "Mail routing and the domain sys-
  329.                      tem," RFC 974, January 1, 1986.
  330.  
  331.  
  332.          [4]         J. Veizades, E. Guttman, C. Perkins, S. Kaplan,
  333.                      "Service Location Protocol," Internet Draft (work
  334.                      in progress), April 3, 1997.
  335.  
  336.  
  337.          [5]         R. Moats, M. Hamilton, "Advertising Services,"
  338.                      Internet Draft (work in progress), February 1997.
  339.  
  340.  
  341.          [6]         C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A
  342.                      Means for Expressing Location Information in the
  343.                      Domain Name System," RFC 1876, January 15, 1996.
  344.  
  345.  
  346.          [7]         D. Eastlake, C. Kaufman, "Domain Name System Secu-
  347.                      rity Extensions," RFC 2065, January 3, 1997.
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356. Expires 12/31/97                                                [Page 6]
  357.  
  358.  
  359.  
  360.  
  361.  
  362. INTERNET DRAFT               Finding Stuff                     June 1997
  363.  
  364.  
  365. 7. Authors' addresses
  366.  
  367.    Ryan Moats
  368.    AT&T
  369.    15621 Drexel Circle
  370.    Omaha, NE 68135-2358
  371.    USA
  372.    Phone:  +1 402 894-9456
  373.    EMail:  jayhawk@ds.internic.net
  374.  
  375.    Martin Hamilton
  376.    Department of Computer Studies
  377.    Loughborough University of Technology
  378.    Leics. LE11 3TU, UK
  379.    Email:  m.t.hamilton@lut.ac.uk
  380.  
  381.    Paul J. Leach
  382.    Microsoft
  383.    1 Microsoft Way
  384.    Redmond, Washington, 98052, U.S.A.
  385.    Email: paulle@microsoft.com
  386.  
  387.  
  388. A. Discovery with Large numbers of replicas
  389.  
  390.    Imagine an organization (such as a bank) which has thousands of
  391.    branch offices. For reliability, each office may want to have a
  392.    replica of (at least) certain critical information in case of loss of
  393.    connectivity to the Internet. An example of such information might be
  394.    an address book for employees or an authentication database. It is
  395.    not reasonable to use the method of the previous section to locate a
  396.    replica for the information - there would be thousands of SRV entries
  397.    for the service being replicated. Instead, it would be desirable to
  398.    have a method that first looked to see if there is a replica for the
  399.    service at the branch office, and only proceed with the more general
  400.    discovery method if there weren't.
  401.  
  402.    Let us generalize the notion of branch office to that of "site" - a
  403.    site is a collection of hosts that have good enough connectivity that
  404.    use of a service instance at the site is always to be preferred to
  405.    one at another, and that there is no connectivity reason to prefer
  406.    one replica within a site to another. A site has a site name that
  407.    incorporates a site specific component and the domain name of the
  408.    organization of the form
  409.       <site>@<org-domain-name>
  410.    Then a client at site
  411.       <site>@<org-domain-name>
  412.    looking for a service for domain <domain-name>, where <org-domain-
  413.  
  414.  
  415.  
  416. Expires 12/31/97                                                [Page 7]
  417.  
  418.  
  419.  
  420.  
  421.  
  422. INTERNET DRAFT               Finding Stuff                     June 1997
  423.  
  424.  
  425.    name> is a suffix of <domain-name>, should use the name
  426.       <site>.sites.<domain-name>
  427.    as the value of "target" in the procedure described herein.  If
  428.    the procedure fails, then it should try with
  429.          <domain-name>
  430.    as the value of "target" using the procedure presented above. Note
  431.    that within a site, this means the client either uses SVRLOC (if
  432.    supported) or straight SRV records; by definition of "site", there
  433.    would be no advantage to be gained from using LOC records.
  434.  
  435.    For example, suppose a client at the site "dublin@univexports.com"
  436.    wanted to access the LDAP server for the Asian region of Universal
  437.    Exports, whose domain name was "fareast.univexports.com". It would
  438.    observe that  its <org-domain-name> of "univexports.com" was a suffix
  439.    of "fareast.univexports.com", and first build the name
  440.    "dublin.sites.fareast.univexports.com" to use as the "target" in the
  441.    procedure above; this might cause it to then lookup
  442.    SRV records for "ldap.tcp.dublin.sites.fareast.univexports.com" or
  443.    A records for "ldap.dublin.sites.fareast.univexports.com" or even
  444.    TXT records for "dublin.sites.fareast.univexports.com" (looking
  445.    for "service:" URLs of the type wp-ldap).
  446.  
  447.    Note that the list of records for a site does not have to point
  448.    at only hosts at that site - for example, the highest priority
  449.    records could be for hosts at the site, and then some lower priority
  450.    records for hosts at the best-connected alternate site for backup.
  451.  
  452.    Using this method, a client looking for a service that has an replica
  453.    at its site will only have to fetch records for its site, not for
  454.    the whole organization. The records associated with the unadorned
  455.    organization name can then be used to aid clients from outside the
  456.    organization, who have no idea of the site structure of the
  457.    organization.
  458.  
  459.  
  460.               This Internet Draft expires December 31, 1997.
  461.    Internet-Draft                                                Ryan Moats
  462.    draft-ietf-svrloc-discovery-03.txt                                  AT&T
  463.    Expires in six months                                    Martin Hamilton
  464.                                                     Loughborough University
  465.                   Paul J. Leach
  466.                       Microsoft
  467.                                                              September 1997
  468.  
  469.                                Finding Stuff
  470.                         (How to discover services)
  471.                Filename: draft-ietf-svrloc-discovery-03.txt
  472.  
  473.  
  474.  
  475.  
  476. Expires 3/31/98                                                 [Page 8]
  477.  
  478.  
  479.  
  480.  
  481.  
  482. INTERNET DRAFT               Finding Stuff                September 1997
  483.  
  484.  
  485.    Status of This Memo
  486.  
  487.       This document is an Internet-Draft.  Internet-Drafts are working
  488.       documents of the Internet Engineering Task Force (IETF), its
  489.       areas, and its working groups.  Note that other groups may also
  490.       distribute working documents as Internet-Drafts.
  491.  
  492.       Internet-Drafts are draft documents valid for a maximum of six
  493.       months and may be updated, replaced, or obsoleted by other
  494.       documents at any time.  It is inappropriate to use Internet-
  495.       Drafts as reference material or to cite them other than as
  496.       ``work in progress.''
  497.  
  498.       To learn the current status of any Internet-Draft, please check
  499.       the ``1id-abstracts.txt'' listing contained in the Internet-
  500.       Drafts Shadow Directories on ftp.is.co.za (Africa),
  501.       nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  502.       ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  503.  
  504. Abstract
  505.  
  506.    This document proposes a solution to the problem of finding
  507.    information about that services are being offered at a particular
  508.    Internet domain.  Therefore, it is possible for clients, using this approach,
  509.    to locate services in a domain with only prior knowledge of the domain name.
  510.  
  511. 1. Rationale
  512.  
  513.    Currently, there is no one single way of discovering the network services and
  514.    application protocols supported at a particular Internet domain.  The
  515.    Domain Name System (DNS) provides some basic facilities for
  516.    finding the hosts that offer particular services, such as DNS servers
  517.    themselves (NS records), mail exchangers (MX records [3]). Recently
  518.    general service records (SRV records [1]) have been proposed for DNS,
  519.    along with storing geographic information (LOC records [6]). In addition,
  520.    there are evolving methods for doing service location via other methods
  521.    [4] & [5].
  522.  
  523.    This document sets forth a process to rationalize how a client could use
  524.    these various methods for service location.  In this process,
  525.    the use of the Service Location Protocol [4] is highlighted to allow
  526.    clients to discover services by characteristics rather than by type alone.
  527.    With the use of SRVs alone, all services are assumed to be identical except
  528.    for weight.  While this may be the case at some locations, SLP
  529.    will still be useful as it provides a dynamic registration framework for
  530.    services.
  531.  
  532.  
  533.  
  534.  
  535.  
  536. Expires 3/31/98                                                 [Page 9]
  537.  
  538.  
  539.  
  540.  
  541.  
  542. INTERNET DRAFT               Finding Stuff                September 1997
  543.  
  544.  
  545. 2. The process
  546.  
  547.    This process is an aggregation of several different ideas.  To explicitly
  548.    point out which ideas are being used, the steps of the process have
  549.    been grouped by section according to which technique is being used.
  550.  
  551.    For a client in domain "srcdom" that wants to locate service "service" in
  552.    domain "tgtdom", the steps of this process are numbered and should
  553.    be explicitly followed (i.e. do step 1, then 2, etc.).
  554.  
  555. 2.1 Support for SVRLOC
  556.  
  557.       1. If "srcdom" == "target" and the client supports it, use the Service
  558.       Location Protocol to determine if the service can be found that way.
  559.  
  560. 2.2 Support for "Sites" Alias Structure (see Appendix A)
  561.  
  562.       2. If "srcdom" is of the form "<site>@<org-domain-name>" and
  563.       "<org-domain-name>" is a suffix of "tgtdom", then do steps
  564.       3 through 9 with "target" set to "<site>.sites.<domain-name>".  If
  565.       this procedure fails or the condition is not met, set "target"
  566.       to "tgtdom".
  567.  
  568.       3. If the client supports Service Location Protocol, look for SRV records [1]
  569.       for a directory agent (i.e. da.udp."target" or da.tcp."target").  This
  570.       consists of:
  571.  
  572.       3a. Do a lookup of QNAME=da.tcp.target, QCLASS=IN, QTYPE=SRV.
  573.  
  574.       3b. If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV RR
  575.       that specifies the requested Service and Protocol in the reply:
  576.  
  577.         If there is precisely one SRV RR, and its Target is "." (the root domain),
  578.         go to step 3c.
  579.  
  580.         For all SRV RR's build a list of (Priority, Weight, Target) tuples and
  581.         sort the list by priority (lowest number first).
  582.  
  583.         Create a new empty list.
  584.  
  585.         For each distinct priority level:
  586.  
  587.           For each element at this priority level:
  588.             While there are still elements left at this priority level, select an
  589.             element randomly, with probability weight, and move it to the tail of
  590.             the new list.
  591.  
  592.           For each element in the new list:
  593.  
  594.  
  595.  
  596. Expires 3/31/98                                                [Page 10]
  597.  
  598.  
  599.  
  600.  
  601.  
  602. INTERNET DRAFT               Finding Stuff                September 1997
  603.  
  604.  
  605.             Query the DNS for A RR's for the target or use any RR's found in the
  606.             additional data section of the earlier SRV query.
  607.  
  608.             For each A RR found, try to connect to the directory agent using the
  609.             Service Location Protocol over TCP.
  610.  
  611.       3c. Else do a lookup of QNAME=da.udp.target, QCLASS=IN, QTYPE=SRV.
  612.  
  613.       3d. Process the reply as in 3b, except that if there is precisely one
  614.       SRV RR with a target of ".", go to step 4 and connections to the directory
  615.       agent use Service Location Protocol over UDP.
  616.  
  617. 2.3 Support for SRV records
  618.  
  619.       4. Look for SRV records for service.protocol.target, where protocol is whichever
  620.       protocol (TCP or UDP) is associated with service.  This consists of:
  621.  
  622.       4a. Do a lookup for QNAME=service.protocol.target, QCLASS=IN, QTYPE=SRV.
  623.  
  624.       4b. If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV RR
  625.       that specifies the requested Service and Protocol in the reply:
  626.  
  627.         If there is precisely one SRV RR, and its Target is "." (the root domain),
  628.         go to step 5.
  629.  
  630.         For all SRV RR's, build a list of (Priority, Weight, Target) tuples and
  631.         sort the list by priority (lowest number first).
  632.  
  633.         Create a new empty list.
  634.  
  635.         For each distinct priority level:
  636.  
  637.           For each element at this priority level:
  638.             Query the DNS for LOC RR [6] for the Target (if not found in the Additional
  639.             Data section of the earlier SRV query).
  640.  
  641.             Find the nearest target and all targets "close" to the nearest
  642.             target (target to target distance less than 2-3% of client to nearest
  643.             target distance).
  644.  
  645.             Remove all other targets at this priority level.
  646.  
  647.             While there are still elements left at this priority level, select an
  648.             element randomly, with probability weight, and move it to the tail of the
  649.             new list.
  650.  
  651.           For each element in the new list:
  652.             Query the DNS for A RR's for the Target or use any RR's found in the
  653.  
  654.  
  655.  
  656. Expires 3/31/98                                                [Page 11]
  657.  
  658.  
  659.  
  660.  
  661.  
  662. INTERNET DRAFT               Finding Stuff                September 1997
  663.  
  664.  
  665.             Additional Data section of the earlier SRV query.
  666.  
  667.             For each A RR found, if the protocol is TCP (connection-oriented) try to
  668.             connect to the (protocol, address, service); if the protocol is UDP, send
  669.             a service request.
  670.  
  671.       5. If the service desired is SMTP, skip to RFC 974 (MX records) else go to
  672.       step 6.
  673.  
  674. 2.3 Support for "Well Known" Aliases
  675.  
  676.       6. If the service has a "well known" alias (see [2]) service', look for A RRs
  677.       for service'.target.  This is done in the following way:
  678.  
  679.       6a. Do a lookup for QNAME=service'.target, QCLASS=IN, QTYPE=A.
  680.  
  681.         If no A RR's returned, go to step 7.
  682.  
  683.         For each A RR found, try to connect to the (protocol, address, service).
  684.         If successful, stop.
  685.  
  686.         If all A RR's have been tried go to step 7.
  687.  
  688. 2.4 Support for Service Advertising via Service URLs
  689.  
  690.       7. Look for "service:" URLs stored in TXT RRs for service.target:
  691.  
  692.       7a. Do a lookup for QNAME=service.target, QCLASS=IN, QTYPE=TXT.
  693.  
  694.         If no TXT RR's returned, go to step 8.
  695.  
  696.         For each TXT RR found, try to connect to the (address, port) specified
  697.         in the service: URL. If successful, stop.
  698.  
  699.         If all TXT RR's have been tried go to step 8.
  700.  
  701.       8. Look for "service:" URLs stored in TXT RRs for target:
  702.  
  703.       8a. Do a lookup for QNAME=target, QCLASS=IN, QTYPE=TXT.
  704.  
  705.         If no TXT RR's returned, go to step 9.
  706.  
  707.         For each TXT RR found, try to connect to the (address, port) specified
  708.         in the service: URL. If successful, stop.
  709.  
  710.         If all TXT RR's have been tried go to step 9.
  711.  
  712.  
  713.  
  714.  
  715.  
  716. Expires 3/31/98                                                [Page 12]
  717.  
  718.  
  719.  
  720.  
  721.  
  722. INTERNET DRAFT               Finding Stuff                September 1997
  723.  
  724.  
  725. 2.5 Fallback
  726.  
  727.       9. Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
  728.  
  729.         For each A RR found, try to connect to the (protocol, address, service).
  730.         If successful, stop.
  731.  
  732. 3. Security Considerations
  733.  
  734.    Because of the suggested mechanisms for service discovery, this document
  735.    inherits all the security considerations of using DNS RR's and the
  736.    Service Location Protocol.  Implementors should consider both [7]
  737.    and the security section of [4] for appropriate methods.
  738.  
  739. 4. Conclusion
  740.  
  741.    By following the above process, a client may be reasonably certain of determining
  742.    whether a particular service is provided for a particular domain name,
  743.    given the domain name.
  744.  
  745. 5. Acknowledgments
  746.  
  747.    This document is partially supported by the National Science Foundation,
  748.    Cooperative Agreement NCR-9218179,
  749.    the UK Electronic Libraries
  750.    Programme (eLib) grant 12/39/01, and the European Commission's Telematics
  751.    for Research Programme grant RE 1004.
  752.  
  753. 6. References
  754.  
  755.    Request For Comments (RFC) and Internet Draft documents are available
  756.    from <URL:ftp://ftp.internic.net> and numerous mirror sites.
  757.  
  758. [1]         A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the
  759.             location of services (DNS SRV)," RFC 2052, October 1996.
  760.  
  761.  
  762. [2]         M. Hamilton, R. Wright,  "Use of DNS Aliases for Network
  763.             Services," Internet Draft (work in progress), June 1996.
  764.  
  765.  
  766. [3]         S. C. Partridge, "Mail routing and the domain system," RFC
  767.             974, January 1, 1986.
  768.  
  769.  
  770. [4]         J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service
  771.             Location Protocol," Internet Draft (work in progress), April
  772.             3, 1997.
  773.  
  774.  
  775.  
  776. Expires 3/31/98                                                [Page 13]
  777.  
  778.  
  779.  
  780.  
  781.  
  782. INTERNET DRAFT               Finding Stuff                September 1997
  783.  
  784.  
  785. [5]         R. Moats, M. Hamilton, "Advertising Services," Internet
  786.             Draft (work in progress), February 1997.
  787.  
  788.  
  789. [6]         C. Davis, P. Vixie, T. Goodwin, I. Dickinson, "A Means for
  790.             Expressing Location Information in the Domain Name System,"
  791.             RFC 1876, January 15, 1996.
  792.  
  793.  
  794. [7]         D. Eastlake, C. Kaufman, "Domain Name System Security
  795.             Extensions," RFC 2065, January 3, 1997.
  796.  
  797. 7. Authors' addresses
  798.  
  799.    Ryan Moats
  800.    AT&T
  801.    15621 Drexel Circle
  802.    Omaha, NE 68135-2358
  803.    USA
  804.    Phone:  +1 402 894-9456
  805.    EMail:  jayhawk@ds.internic.net
  806.  
  807.    Martin Hamilton
  808.    Department of Computer Studies
  809.    Loughborough University of Technology
  810.    Leics. LE11 3TU, UK
  811.    Email:  m.t.hamilton@lut.ac.uk
  812.  
  813.    Paul J. Leach
  814.    Microsoft
  815.    1 Microsoft Way
  816.    Redmond, Washington, 98052, U.S.A.
  817.    Email: paulle@microsoft.com
  818.  
  819. A. Discovery with Large numbers of replicas
  820.  
  821.    Imagine an organization (such as a bank) which has thousands of
  822.    branch offices. For reliability, each office may want to have a
  823.    replica of (at least) certain critical information in case of loss of
  824.    connectivity to the Internet. An example of such information might be
  825.    an address book for employees or an authentication database. It is
  826.    not reasonable to use the method of the previous section to locate a
  827.    replica for the information - there would be thousands of SRV entries
  828.    for the service being replicated. Instead, it would be desirable to
  829.    have a method that first looked to see if there is a replica for the
  830.    service at the branch office, and only proceed with the more general
  831.    discovery method if there weren't.
  832.  
  833.  
  834.  
  835.  
  836. Expires 3/31/98                                                [Page 14]
  837.  
  838.  
  839.  
  840.  
  841.  
  842. INTERNET DRAFT               Finding Stuff                September 1997
  843.  
  844.  
  845.    Let us generalize the notion of branch office to that of "site" - a
  846.    site is a collection of hosts that have good enough connectivity that
  847.    use of a service instance at the site is always to be preferred to
  848.    one at another, and that there is no connectivity reason to prefer
  849.    one replica within a site to another. A site has a site name that
  850.    incorporates a site specific component and the domain name of the
  851.    organization of the form
  852.       <site>@<org-domain-name>
  853.    Then a client at site
  854.       <site>@<org-domain-name>
  855.    looking for a service for domain <domain-name>, where <org-domain-
  856.    name> is a suffix of <domain-name>, should use the name
  857.       <site>.sites.<domain-name>
  858.    as the value of "target" in the procedure described herein.  If
  859.    the procedure fails, then it should try with
  860.          <domain-name>
  861.    as the value of "target" using the procedure presented above. Note
  862.    that within a site, this means the client either uses SVRLOC (if
  863.    supported) or straight SRV records; by definition of "site", there
  864.    would be no advantage to be gained from using LOC records.
  865.  
  866.    For example, suppose a client at the site "dublin@univexports.com"
  867.    wanted to access the LDAP server for the Asian region of Universal
  868.    Exports, whose domain name was "fareast.univexports.com". It would
  869.    observe that  its <org-domain-name> of "univexports.com" was a suffix
  870.    of "fareast.univexports.com", and first build the name
  871.    "dublin.sites.fareast.univexports.com" to use as the "target" in the
  872.    procedure above; this might cause it to then lookup
  873.    SRV records for "ldap.tcp.dublin.sites.fareast.univexports.com" or
  874.    A records for "ldap.dublin.sites.fareast.univexports.com" or even
  875.    TXT records for "dublin.sites.fareast.univexports.com" (looking
  876.    for "service:" URLs of the type wp-ldap).
  877.  
  878.    Note that the list of records for a site does not have to point
  879.    at only hosts at that site - for example, the highest priority
  880.    records could be for hosts at the site, and then some lower priority
  881.    records for hosts at the best-connected alternate site for backup.
  882.  
  883.    Using this method, a client looking for a service that has an replica
  884.    at its site will only have to fetch records for its site, not for
  885.    the whole organization. The records associated with the unadorned
  886.    organization name can then be used to aid clients from outside the
  887.    organization, who have no idea of the site structure of the
  888.    organization.
  889.  
  890.                 This Internet Draft expires March 31, 1998.
  891.  
  892.  
  893.  
  894.  
  895.  
  896. Expires 3/31/98                                                [Page 15]
  897.  
  898.  
  899.  
  900.