If you are wondering why would one want to bother with SRV records, keep reading.
SRV records provide a generic mechanism for locating services offered by a given domain.
The current method for service location is based on well-know domain labels (e.g. www) and ports (e.g. 80). To find the HTTP service for a given 'domain.tld' domain, one queries the DNS for 'www.domain.tld' and assumes the service is offered on port 80. For another service, like FTP, a different label and port are assumed (e.g. ftp.domain.tld:21).
With SRV records, one can issue a specific query for a service possibly offered by some domain and then discover the precise locations of the service in format of address/port pairs. Also, SRV records inform whether the desired service is definitely not offered.
With SRV records, it's easier to provide multiple services under the same domain name, letting to the client application the task of finding servers. This relieves the user from the need of typing "magic" prefix labels as "www" or "ftp".
A very useful property of SRV records is they allow to run services in arbitrary ports.
For example, with SRV it's possible to run many e-mail servers at the same machine, with a single IP address. Each server can host a completely different set of e-mail domains. This is valid for any service located through SRV (FTP, HTTP, etc).
Therefore SRV support is very attractive for virtual hosting, among many other applications.
SRV records provide a priority based mechanism for backup servers, in a way very similar to MX records.
Using the weight field provided by SRV records, one can distribute the service load among many servers. For instance, if one has two servers, it's possible to specify that one server should receive 2/3 of the "load" (hits referred by the name server).
By design, the deployment of SRV records does not break existing, non-SRV-compliant domains and sites.
The DNS infrastructure for SRV records is ready. A developer can start adding SRV support to his application and obtain the benefits today.
Those familiar with the simpler gethostbyname() functions would argument that SRV records are not quite easy to use.
That's why RULI is available. RULI aims to remove the burden of strictly adhering to the SRV specification from the back of the application developer. Programmers can now focus on their application development while relying on RULI to properly query and handle SRV records.
Now you understand the benefits of SRV records, please see how RULI can help you.
Handling DNS SRV is not as simple as to deal with ordinary address records. When one performs a query for A records by calling gethostbyname(), he gets a list of addresses which should be contacted in the same order as they were received. For SRV records, there is an additional logic that must be applied to the records, based on their weight and priority, to discover the correct sequence for contacting them.
The SRV logic is described in RFC 2782. Those who intend to use SRV benefits in their application are expected to implement that exact behavior. RULI can help here: it automatically performs all the SRV logic for you.
Application developers probably want to spend time on their business logic; not dealing with the details of the DNS protocol or implementing the SRV specification.
RULI is a tested framework designed to properly fetch SRV records. It saves you time and head aches.
RULI is released under GNU GPL at no cost.
Find outlined below the major RULI features.
Given a <service, protocol, domain> tuple, RULI fetches the corresponding SRV records and performs the required logic on them, issuing a ready-to-use list of records in a convenient format -- <hostname, port, addresses> tuples.
Under certain circumstances, the SRV logic demands address queries be used as last resort mechanism; in these cases, CNAME issues may rise and must be properly dealt with. RULI handles alias records (CNAMEs) transparently.
SRV logic may be affected by a service specification. For instance, SRV support for HTTP service requires special behavior to handle the port number in URIs. RULI currently obeys such HTTP requirement and is intended to implement support for other special cases as soon as they're defined.
As of version 0.25, RULI is fully able (1) to perform queries over IPv6 transport and (2) to fetch IN AAAA resource records. It's possible to disable IPv6 support if desired.
RULI's standard behavior is asynchronous. It's possible to handle many queries concurrently. This is designed for event-driven applications.
RULI provides a simpler API for synchronous (blocking) queries. It's easier to use, but blocking on name solving may not be acceptable for some applications.
Also, multi-threaded applications are supposed to use the synchronous API, for thread-safety.
RULI automatically switches to TCP mode when resquested by the truncation bit of an UDP answer.
The underlying resolver used by RULI delivers answers in dynamic buffers of correct size. This avoids: (1) the need for user-provided buffers, (2) the application job of guessing/finding proper buffer sizes, (3) wasting memory.
RULI does not impose further restrictions on the valid characters for domain names. It's up to the application to build the query name and (later) to properly deal with characters returned in domain labels.
NOTE: For interface simplicity, RULI's synchronous API DOES restrict domain names ONLY in the following ways: (1) the '.' (dot) character is used as label-separator and (2) the NULL character is used as end-of-string.
For server fail-over, RULI queries a list of name servers in a round-robin fashion. Each server is considered up to a specified number of retries.
RULI's state is stored under an opaque data structures explicitly allocated by the user. Thus a single program can manage multiple instances of the library simultaneously.