Szolgáltatásrekord
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.

A rekord leírása
Az SRV rekordok a következő módon néznek ki:
 _service._proto.name. TTL class SRV priority weight port target.

 service: szolgáltatás – a keresett szolgáltatás szimbolikus neve, például ldap vagy kerberos.
 proto: protokoll – Az átviteli protokoll típusát jelzi. Ez csaknem kizárólag TCP vagy UDP, bár elméletben más protokollok is használhatók..
 name: név – A DNS-tartománynév, amelyhez az erőforrásrekord tartozik, ponttal kell végződnie.
 TTL: Time to Live – a megszokott DNS élettartam-mező.
 class: osztály – a megszokott DNS osztály mező (értéke minden esetben IN).
 priority: prioritás – a célállomás prioritása, az alacsonyabb értékű cél jobban preferált.
 weight: súly – azonos prioritású rekordok közötti relatív súlyozás, a magasabb érték jobban preferált.
 port: a TCP vagy UDP port, amin a szolgáltatás elérhető.
 target: cél – a kért szolgáltatás nyújtására képes kiszolgáló DNS-tartománynevét tartalmazza. Az itt szereplő névhez tartoznia kell egy megfelelő állomáscím (A) erőforrásrekordnak, amely alapján a kérdéses IP-cím meghatározható.

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.

Magas rendelkezésre állás 
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.

Egy szolgáltatásrekord lekérdezése
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

Microsoft DNS

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. 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:
 _sites – itt a tartományvezérlőket telephelyek szerinti bontásban találjuk, ez alapján találják meg a munkaállomások a hozzájuk legközelebb eső kiszolgálókat
 _tcp és _udp – az egyes szolgáltatások felbontása a használt protokoll szempontjából.

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):
 _ldap : LDAP szolgáltatás
 _ gc: globális katalógus szolgáltatás
 _kerberos: Kerberos KDC (Key Distribution Center)
 _kpasswd: Kerberos Password Change server

Használata az interneten
Szolgáltatásrekordokat használnak a következő szabványosított kommunikációs protokollok:
 Teamspeak 3 (a 3.0.8. verziótól kezdve sem a prioritást, sem a súlyt nem veszi figyelembe. A kliens vélhetőleg véletlenül választ az SRV rekordok között.)
 Minecraft (az 1.3.1 verziótól kezdve, _minecraft._tcp)
 CalDAV és CardDAV
 Client SMTP Authorization
 DNS Service Discovery (DNS-SD)
 IMPS
 Kerberos
 LDAP
 Puppet
 SIP
 XMPP
 Mail submission, Post Office Protocol, and Internet Message Access Protocol
 Libravatar az avatar képkiszolgálók megtalálására
 Microsoft Lync (_sipinternaltls.)
 Microsoft System Center Configuration Manager (_mssms_mp_<sitecode>)
 Microsoft volume activation (KMS): _VLMCS
 Citrix Receiver

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. 
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.

Kapcsolódó szócikkek
 DNS-rekordtípusok listája
 MX-rekord - az SMTP szervert meghatározó erőforrásrekord

Jegyzetek

Fordítás

További információk 
 RFC 2782 - definition of the SRV resource record
 TechNet: SRV Resource Records
http://sauron.inf.mit.bme.hu/Edu/IIM/iim08.nsf/a141f6e0f01d3349c1256e4c005bc395/13d88b098ef699fbc125741200595089/$FILE/IIM-Active-Directory.ppt
TechNet Klub: Rendszerfelügyelet rendszergazdáknak 
IETF draft using SRV records to locate whois servers
 Men & Mice's DNS Glossary - SRV Record
 Rick van Rein's articles on SRV resource records 
 Comprehensive list of defined SRV service types
 draft-andrews-http-srv-01.txt - Use of SRV records in conjunction with HTTP and URIs (Expired Internet-Draft)
 RFC 6186 - Use of SRV Records for Locating Email Submission/Access Services
 Search SRV records for Skype for Business

Domain Name System