Browse Prior Art Database

A DNS RR for specifying the location of services (DNS SRV) (RFC2052)

IP.com Disclosure Number: IPCOM000002603D
Original Publication Date: 1996-Oct-01
Included in the Prior Art Database: 2019-Feb-16
Document File: 10 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Gulbrandsen: AUTHOR [+1]

Related Documents

10.17487/RFC2052: DOI

Abstract

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). This memo defines an Experimental Protocol for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 19% of the total text.

Network Working Group A. Gulbrandsen Request for Comments: 2052 Troll Technologies Updates: 1035, 1183 P. Vixie Category: Experimental Vixie Enterprises October 1996

A DNS RR for specifying the location of services (DNS SRV)

Status of this Memo

This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

Abstract

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX).

Overview and rationale

Currently, one must either know the exact address of a server to contact it, or broadcast a question. This has led to, for example, ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC- level broadcasts to locate servers.

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.

Clients ask for a specific service/protocol for a specific domain (the word domain is used here in the strict RFC 1034 sense), and get back the names of any available servers.

Introductory example

When a SRV-cognizant web-browser wants to retrieve

http://www.asdf.com/

it does a lookup of

http.tcp.www.asdf.com

Gulbrandsen & Vixie Experimental [Page 1]

RFC 2052 DNS SRV RR October 1996

and retrieves the document from one of the servers in the reply. The example zone file near the end of the memo contains answering RRs for this query.

The format of the SRV RR

Here is the format of the SRV RR, whose DNS type code is 33:

Service.Proto.Name TTL Class SRV Priority Weight Port Target

(There is an example near the end of this document.)

Service The symbolic name of the desired service, as defined in Assigned Numbers or locally.

Some widely used services, notably POP, don’t have a single universal name. If Assigned Numbers names the service indicated, that name is the only name which is legal for SRV lookups. Only locally defined services may be named locally. The Service is case insensitive.

Proto TCP and UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). 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.

TTL Standard DNS meaning.

Class Standard DNS meaning.

Priority As for MX, 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 pseudorandom order. The range is 0-65535.

Gulbrandsen & Vixie Experimental [Page 2]

RFC 2052 DNS SRV RR October 1996

Weight Load balancing mechanism. When selecting a target host among the thos...

Processing...
Loading...