mail us  |  mail this page

contact us
training  | 
tech stuff  | 

BIND 9 Support

Services Record (SRV)

Defined in RFC 2782. The SRV RR identifies the host(s) that will support a particular service. The MX RR is a specialised example of service discovery while the SRV RR is a general purpose RR to discover any service. The SRV RR allows control over prioritisation of delivery and usage. It is not widely supported except notably by OpenLDAP and increasingly by SIP (VoIP) systems in conjunction with the NAPTR RR. Ugly format may not be helping!

The theory behind SRV is that, given a domain name, for instance, example.com, and a service name, for example, web (http) which runs on a protocol (tcp in the web case case), a DNS query may be issued to find the host name that provides such a service for the domain - and which may, or may not, be within the domain - see example 2 below.

SRV Syntax

srvce.prot.owner-name  ttl  class   rr  pri  weight port target
_http._tcp.example.com.       IN    SRV 0    5      80   www.example.com.
Field Description
srvce Defines the symbolic service name (see IANA port-numbers) prepended with a '_' (underscore). Case insensitive. Common values are:
  • _http - web service
  • _ftp - file transfer service
  • _ldap - LDAP service
  • _imap - IMAP mail service
  • _PKIXREP - PKIX Repository (X.509 certificates)
prot Defines the protocol name (see IANA service-names) prepended with a '_' (underscore). Case insensitive. Common values are
  • _tcp - TCP protocol
  • _udp - UDP protocol
Notes: Use of SRV in PKIX (X.509) handing. RFC 4210 defines service names of certificates, crls, pgpkeys, pgprevokations all with a protocol of tcp to indicate the use of the CMP protocol over HTTP/HTTPS. Thus, a certificate store supporting CMP may be discovered for the domain exmple.com by a query for _certificates._tcp.example.com. In a slightly bizarre variation, RFC 4386 (INFORMATIONAL status), also defines the use of the _PKIXREP service for discovery of X.509 certificate repositories and other PKIX services, the protocol field, contains what other users of the SRV define as the service name. Thus, for the service name _PKIXREP the protocol values would be:
  • _ldap - The certificate respository server uses LDAP
  • _http - The certificate respository server uses HTTP
  • _ocsp - The server provides an Online Certificate Status Protocol service
One assumes that additional values such as _cmp, _svcp or _crl (X.509/PKIX protocols) could also be used to describe alternative PKIX services even though these are not mentioned in RFC 4386. Finally, OCSP (RFC 2560) suggests the service can run over many transport protocols such as LDAP, HTTP or SMTP and thus the SVR definition proposed for PKIXREQ service would not contain enough information - because it does not differentiate between a number of possible transports - to allow true service discovery. Altogether a strange RFC. (More info on X.509 and TLS/SSL.
owner-name Incomprehensible description in RFC 2782. Defines the base domain (or zone) name. This RR obeys the normal name rules such that leaving the entry blank (without a dot) will substitute the current the zone root (or the current $ORIGIN), or you can explicitly add it as in the above _http._tcp.example.com. (with a dot).
ttl Optional. Standard TTL parameter. For more information about TTL values.
class Optional. Standard CLASS parameter. Normally IN for Internet class. For more information.
pri The relative Priority of this service (range 0 - 65535). Lowest is highest priority, usage is the same as the MX pref field.
weight Used when more than one service has the same priority. A 16 bit unsigned integer in the range 0 - 65535. The value 0 indicates no weighting should be applied. If the weight is 1 or greater it is a relative number in which the highest is most frequently delivered, that is, given two SRV records both with Priority = 0, one with weight = 1 the other weight = 6, the one with weight 6 will have its RR delivered first 6 times out of 7 by the name server.
port Normally the port number assigned to the symbolic service but this is not a requirement, for instance, it is permissible to define a _http service with a port number of 8100 rather than the more normal port 80.
target The name of the host that will provide this service. Does not have to be in the same zone (domain). May be just a host name or a FQDN.

Examples:

This example is taken from the RFC and is designed to make everything clear(!). The second example shows a real world LDAP service definition. The third shows a mythical IMAP server example and the fourth shows a real'ish SIP example.

$ORIGIN example.com.
@               SOA server.example.com. hostmaster.example.com. (
                          1995032001 3600 3600 604800 86400 )
                NS  server.example.com.
                NS  ns1.ip-provider.net.
                NS  ns2.ip-provider.net.
; foobar - use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
_foobar._tcp    SRV 0 1 9 old-slow-box.example.com.
                SRV 0 3 9 new-fast-box.example.com.
; if neither old-slow-box or new-fast-box is up, switch to
; using the sysdmin's box and the server
                SRV 1 0 9 sysadmins-box.example.com.
                SRV 1 0 9 server.example.com.
server           A   172.30.79.10
old-slow-box     A   172.30.79.11
sysadmins-box    A   172.30.79.12
new-fast-box     A   172.30.79.13
; NO other services are supported
*._tcp          SRV  0 0 0 .
*._udp          SRV  0 0 0 .

Example 2

This example is taken from the OpenLDAP site and allows a simple discovery process of the LDAP server for the zone by interrogation of the DNS.

$ORIGIN example.com.
...
; defines an ldap service available at the host jim.example.com
_ldap._tcp.example.com.    SRV 0 0 389 jim
; if the service (LDAP) were hosted by another organization
; the reference could be external
; in this case the host ldap.example.net hosts the LDAP service for
; example.com 
_ldap._tcp.example.com.    SRV 0 0 389 ldap.example.net.

OpenLDAP publish an SRV RR which may be obtained by issuing an SRV query to _ldap._tcp.openldap.org.

Example 3

An MX RR defines the name of the host that will receive incoming mail for a domain using an SMTP service - though theorectically there is nothing to stop an alternate MX RR definition using an SRV RR with a symbolic service name of _smtp and a protocol of _tcp - if it were supported, which it is not. This example would allow a mail client (assuming it supported such a service) to find an IMAP server for a domain in order to read the mail using the IMAP protocol in this case (it could equally have been pop3, in which case, simply substitute _pop3 for _imap in the examples below):

$ORIGIN example.com.
...
; defines an IMAP service available at the host imap.example.com
; using the normal imap port number
_imap._tcp.example.com.    SRV 0 0 143 imap
; above could have written as
; _imap._tcp    SRV 0 0 143 imap
; OR even
; _imap._tcp.example.com.    SRV 0 0 143 imap.example.com.
; the imap service could be hosted on a non-standard 
; port number - in the case below port 8800
_imap._tcp    SRV 0 0 8800 imap
; if the service (IMAP) were hosted by another organization
; the reference could be external
; in the case below the host imap2.example.net provides 
; the IMAP service for example.com 
_imap._tcp    SRV 0 0 143 imap2.example.net.

To use such an SRV would require that the mail client support the feature. As far as we know none do. But it is a nifty idea.

Example 4

The next example shows the use of the SRV for provision of SIP (VoIP) services for a domain.

$ORIGIN example.com.
...
; defines an SIP service available at the host sip.example.com
; using a port number of 6201 with the normal sip udp protocol
_sip._udp.example.com.    SRV 0 0 6201 sip
; above could have written as
; _sip._udp    SRV 0 0 6201 sip
; OR even
; _sip._udp.example.com.    SRV 0 0 6201 sip.example.com.
; adding a second SRV RR with a lower priority allows failover
; to sip2 in the case that sip is not available
_sip._udp    SRV 1 0 5523 sip2.example.com.


Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.

Pro DNS and BIND by Ron Aitchison

Contents

tech info
guides home
dns articles
intro
contents
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
quickstart
5 install bind
6 samples
reference
7 named.conf
8 zone records
operations
9 howtos
10 tools
11 trouble
programming
12 bind api's
security
13 dns security
bits & bytes
15 messages
resources
notes & tips
registration FAQ
dns resources
dns rfcs
change log

Creative Commons License
This work is licensed under a Creative Commons License.

If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox

Search

web zytrax.com

Share

Icons made by Icomoon from www.flaticon.com is licensed by CC 3.0 BY
share page via facebook tweet this page

Page

email us Send to a friend feature print this page Display full width page Decrease font size Increase font size

Resources

Systems

FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Linux.org
Debian Linux

Software

LibreOffice
OpenOffice
Mozilla
GitHub
GNU-Free SW Foundation
get-dns

Organizations

Open Source Initiative
Creative Commons

Misc.

Ibiblio - Library
Open Book Project
Open Directory
Wikipedia

Site

CSS Technology SPF Record Conformant Domain
Copyright © 1994 - 2024 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
hosted by javapipe.com
web-master at zytrax
Page modified: January 20 2022.