A szolgáltatásrekord (SRV-rekord, SRV record) az internetes Domain Name Systemben egy szolgáltatás helyét, pl. az állomásnevet és portszámot meghatározó bejegyzés. Az RFC 2782 írja le, típuskódja 33. Egyes internetes protokollok, köztük a Session Initiation Protocol (SIP) és az Extensible Messaging and Presence Protocol (XMPP) megkövetelik az SRV rekordok támogatását működésükhöz.
Az SRV rekordok a következő módon néznek ki:
_service._proto.name. TTL class SRV priority weight port target.
Egy zónafájlban megtalálható példa szervizrekord például ilyen lehet:
_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.
Ez a rekord a sipserver.example.com kiszolgálóra mutat, ami az 5060-as TCP porton válaszol Session Initiation Protocol (SIP) protokoll szerinti kérésekre. A megadott prioritás 0, a súlyozás 5.
Ahogy az MX-rekordoknál, a szervizrekord „target” értéke is egy állomásnévre kell mutasson, ami címrekord – A vagy AAAA rekord lehet. A CNAME-re mutató állomásnév érték érvénytelen.
A priority mező határozza meg a rekord adatainak precedenciáját. A kliensek mindig először a legalacsonyabb prioritási értéket használják, ha ez sikertelen, akkor fordulnak a megegyező vagy magasabb prioritású rekordokban meghatározott állomásokhoz.
Ha egy szolgáltatáshoz több, azonos prioritású SRV rekord tartozik, a kliensek a weight mező alapján döntik el, melyik hosztot használják. Ez a súlyozási mező kizárólag a szolgáltatás többi súlyozási értékéhez képest értelmezhető, azon belül is csak az azonos prioritású rekordok között.
A következő példában a priority és a weight mezőket is felhasználjuk terheléselosztás és hibatűrés céljából.
# _service._proto.name. TTL class SRV priority weight port target.
_sip._tcp.example.com. 86400 IN SRV 10 60 5060 bigbox.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 20 5060 smallbox1.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 10 5060 smallbox2.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 10 5066 smallbox2.example.com.
_sip._tcp.example.com. 86400 IN SRV 20 0 5060 backupbox.example.com.
Az első négy rekord a 10-es prioritási értéken osztozik, tehát a súlyozás dönti el, hogy kliensek melyik kiszolgálóhoz (állomásnév-port kombinációhoz) csatlakozzanak. A négy súlyérték összege 100, tehát az idő 60%-ában a bigbox.example.com -ot fogják használni. A smallbox1 és a smallbox2 a lekérdezések 20–20%-ra fog válaszolni, a smallbox2-re érkező lekérdezések fele (tehát az összes lekérdezés 10%-a) az 5060-as portot, a másik fele az 5066-os portot használja. Ha a bigbox nem érhető el, a két megmaradó szerver között egyenlően fog eloszlani a terhelés, hiszen mindegyiket az idő 50%-ában fogják elérni.
Ha egyik 10-es prioritású szerver sem érhető el (például mert az elsődleges telephellyel történt valami), a kliensek a következő legkisebb prioritású értékű kiszolgálót fogják választani, ami a backupbox.example.com. Ez például egy másik telephelyen található, valószínűleg nem érintette az a szolgáltatáskiesés, ami az első három állomást igen.
A szolgáltatásrekordok segítségével eléggé korlátozott mértékű terheléselosztás érhető el, hiszen az információ lényegében statikus. A kiszolgálók pillanatnyi terhelését egyáltalán nem veszi figyelembe.
Az SRV rekordokat a megszokott hálózati adminisztrációs eszközökkel lehet lekérdezni, amilyen a Domain Information Groper (dig) vagy az nslookup.
$ dig _sip._tcp.example.com SRV
$ host -t SRV _sip._tcp.example.com
$ nslookup -querytype=srv _sip._tcp.example.com
$ nslookup
> set querytype=srv
> _sip._tcp.example.com
Az SRV-rekordok szükségesek a Microsoft Active Directory-szolgáltatásainak eléréséhez. Ilyen módon történik például az LDAP-protokoll segítségével a 389-es TCP-porton keresztül elérhető Active Directory-szolgáltatás megkeresése is.
Alaphelyzetben két címkeresési zóna található meg a tartománnyal integrált DNS-ben. Tekintsük a ceg.local nevű tartományt! A ceg.local mellett az _msdcs.ceg.local (Microsoft Domain Controllers) is tovább bontható dc, domains, gc és pdc bejegyzésekre.[1] A gc a globális katalógust jelenti, a pdc bejegyzés pedig a PDC-emulátorra utal (lásd FSMO-szerepkörök).
A ceg.local alatt az alábbi altartományokat kell találnunk:
Amennyiben ezek a bejegyzések hiányoznak, az Active Directory alapfunkcióit sem képes ellátni. A tartományi SRV-rekordok regisztrációjáért a NetLogon szolgáltatás felelős, amely a bejegyzéseket induláskor hozza létre.
A Windows tartományokban használt fő szolgáltatástípusok (általában tartományvezérlőkre mutatnak):[2]
Szolgáltatásrekordokat használnak a következő szabványosított kommunikációs protokollok:
_minecraft._tcp
)A Microsoft Windows 2000-től kezdve a kliensek a szolgáltatásrekordok segítségével találják meg a tartományvezérlőt az Active Directory szolgáltatásaihoz. Az SRV-rekordokat használja továbbá a Microsoft Outlook 2007-es és újabb verziói az Exchange Autodiscover szolgáltatásához.[12] A Microsoft Windows-alapú hálózatokban a dinamikus DNS alapvető fontosságú, mivel a tartományvezérlők regisztrálják a szolgáltatásaikat a DNS-ben, hogy a tartomány vagy erdő többi számítógépe rájuk találhasson.
A szolgáltatásrekordokban használható szolgáltatásnevek és a hozzájuk tartozó protokollok jegyzékét az RFC6335 határozza meg és az IANA tartja karban.[13]