Rosenberg Request for Comments: dynamicsoft Obsoletes: H. 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. All Rights Reserved. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail.
|Published (Last):||2 March 2013|
|PDF File Size:||10.76 Mb|
|ePub File Size:||1.27 Mb|
|Price:||Free* [*Free Regsitration Required]|
Esibov Microsoft Corp. 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. All Rights Reserved. Abstract This document describes a DNS RR which specifies the location of the server s for a specific protocol and domain.
Overview and rationale Currently, one must either know the exact address of a server to contact it, or broadcast a question. 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. Gulbrandsen, et al. Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record.
It also MUST include security considerations. As described in the earlier applicability section, consult the appropriate LDAP documents for the recommended procedures. If Assigned Numbers names the service indicated, that name is the only name which is legal for SRV lookups.
The Service is case insensitive. The Proto is case insensitive. Name The domain this RR refers to. The SRV RR is unique in that the name one searches for is not this name; the example near the end shows this clearly. Priority The priority of this target host. A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field. The range is This is a 16 bit unsigned integer in network byte order.
Weight A server selection mechanism. The weight field specifies a relative weight for entries with the same priority.
The range of this number is In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected. In the absence of a protocol whose specification calls for the use of other weighting information, a client arranges the SRV RRs of the same Priority in the order in which target hosts, Gulbrandsen, et al. Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order.
Then choose a uniform random number between 0 and the sum computed inclusive , and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. This process is repeated for each Priority. Port The port on this target host of this service. The range is 0- This is often as specified in Assigned Numbers but need not be. Target The domain name of the target host. Implementors are urged, but not required, to return the address record s in the Additional Data section.
Unless and until permitted by future standards action, name compression is not to be used for this field. A Target of ". Domain administrator advice Expecting everyone to update their client applications when the first server publishes a SRV RR is futile even if desirable.
Therefore SRV would have to coexist with address record lookups for existing protocols, and DNS administrators should try to provide address records to support old clients: - Where the services for a single domain are spread over several hosts, it seems advisable to have a list of address records at the same DNS node as the SRV RR, listing reasonable if perhaps Gulbrandsen, et al.
Note that some programs only try the first address they get back from e. Until all resolvers can handle larger responses, domain administrators are strongly advised to keep their SRV replies below bytes. All round numbers, wrote Dr. If an answer may be close to the limit, using a DNS query tool e. The "Weight" field Weight, the server selection field, is not quite satisfactory, but the actual load on typical servers changes much too quickly to be kept around in DNS caches.
It seems to the authors that offering administrators a way to say "this machine is three times as fast as that one" is the best that can practically be done.
For short-lived services an extra step in the connection establishment seems too expensive, and for long-lived services, the load figure may well be thrown off a minute after the connection is established when someone else starts or finishes a heavy job.
Note: There are currently various experiments at providing relative network proximity estimation, available bandwidth estimation, and similar services. Use of the SRV record with such facilities, and in particular the interpretation of the Weight field when these facilities are used, is for further study. Weight is only intended for static, not dynamic, server selection.
Server selection via SRV is only intended to express static information such as "this server has a faster CPU than that one" or "this server has a much better network connection than that one". Moving this information to the DNS makes it less necessary to update these files on every single computer of the net every time a new service is added, and makes it possible to move standard services out of the "root-only" port range on unix.
Fictional example This example uses fictional service "foobar" as an aid in understanding SRV records. If ever service "foobar" is implemented, it is not intended that it will necessarily use SRV records. This is part of the zone file for example. SOA server. NS ns1. NS ns2. SRV 0 3 9 new-fast-box.
SRV 1 0 9 server. No other IANA services are required by this document. The major change from that previous, experimental, version of this specification is that now the protocol and service labels are prepended with an underscore, to lower the probability of an accidental clash with a similar name used for unrelated purposes.
Aside from that, changes are only intended to increase the clarity and completeness of the document. This document especially clarifies the use of the Weight field of the SRV records. Security Considerations The authors believe this RR to not cause any new security problems.
Some problems become more visible, though. It becomes impossible to block internal clients from accessing specific external services, slightly harder to block internal users from running unauthorized services, and more important for the router operations and DNS operations personnel to cooperate.
This could lead to denial of service. Because this vulnerability exists already, with names and addresses, this is not a new vulnerability, merely a slightly extended one, with little practical effect.
RFC : Mockapetris, P. RFC : Partridge, C. BCP 14 : Bradner, S. RFC : Elz, R. RFC : Hamilton, M. ARM: Armijo, M. 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. Standards Track [Page 12] Html markup produced by rfcmarkup 1.
SRV (RFC 2782)
Google Network Working Group A. Esibov Microsoft Corp. 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. All Rights Reserved. Abstract This document describes a DNS RR which specifies the location of the server s for a specific protocol and domain. Overview and rationale Currently, one must either know the exact address of a server to contact it, or broadcast a question.
References from rfc2782
Esibov Microsoft Corp. 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. All Rights Reserved. Abstract This document describes a DNS RR which specifies the location of the server s for a specific protocol and domain. Overview and rationale Currently, one must either know the exact address of a server to contact it, or broadcast a question.
Vubei Oracle WebLogic Communication Services supports applications that conform to this specification. Windows platforms are supported only for development purposes. Retrieved 17 April In cases where specifications are part of a larger release plan, as with the 3GPP, Oracle prioritizes compliance with latest ratified release in this case, Release 6. Clients should use the SRV records with the lowest-numbered priority value first, and fall back to records of higher value if the connection fails.