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
szerkesztésAz 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
szerkesztésA 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
szerkesztésAz 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
szerkesztésAz 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:
- _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):[2]
- _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
szerkesztésSzolgá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.[3])
- Minecraft (az 1.3.1 verziótól kezdve,
_minecraft._tcp
) - CalDAV és CardDAV
- Client SMTP Authorization
- DNS Service Discovery (DNS-SD)
- IMPS[4]
- Kerberos[5]
- LDAP[6]
- Puppet[7]
- SIP
- XMPP[8]
- Mail submission, Post Office Protocol, and Internet Message Access Protocol[9]
- Libravatar az avatar képkiszolgálók megtalálására
- Microsoft Lync (_sipinternaltls.)[10]
- Microsoft System Center Configuration Manager (_mssms_mp_<sitecode>)
- Microsoft volume activation (KMS): _VLMCS
- Citrix Receiver[11]
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]
Kapcsolódó szócikkek
szerkesztés- DNS-rekordtípusok listája
- MX-rekord - az SMTP szervert meghatározó erőforrásrekord
Jegyzetek
szerkesztés- ↑ TechNet Klub: Rendszerfelügyelet rendszergazdáknak. [2015. szeptember 27-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. szeptember 26.)
- ↑ TechNet: SRV Resource Records
- ↑ [Suggestion] TS DNS. Forum.teamspeak.com. (Hozzáférés: 2013. október 25.)
- ↑ Archivált másolat. [2015. szeptember 29-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. szeptember 26.)
- ↑ Hostnames for the Master and Slave KDCs. Web.mit.edu. (Hozzáférés: 2012. május 23.)
- ↑ RFC 3088 - OpenLDAP Root Service An experimental LDAP referral service. Faqs.org. (Hozzáférés: 2012. május 23.)
- ↑ Puppet Docs: Using Multiple Puppet Masters, Option 4: DNS SRV Records. Puppet Labs. [2013. december 27-i dátummal az eredetiből archiválva]. (Hozzáférés: 2013. december 26.)
- ↑ XEP-0156: Discovering Alternative XMPP Connection Methods. Xmpp.org. (Hozzáférés: 2012. május 23.)
- ↑ Sablon:Cite IETF
- ↑ Microsoft Office365. Microsoft.com. (Hozzáférés: 2014. június 24.)
- ↑ Configuring Email-Based Account Discovery for Citrix Receiver. Citrix. (Hozzáférés: 2014. június 24.)
- ↑ A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service. Support.microsoft.com, 2010. május 13. (Hozzáférés: 2012. május 23.)
- ↑ RFC 6335 - Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry. ietf.org, 2011. augusztus 1. (Hozzáférés: 2013. január 28.)
Fordítás
szerkesztés- Ez a szócikk részben vagy egészben az SRV record című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
További információk
szerkesztés- 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[halott link]
- TechNet Klub: Rendszerfelügyelet rendszergazdáknak Archiválva 2015. szeptember 27-i dátummal a Wayback Machine-ben
- IETF draft using SRV records to locate whois servers[1]
- Men & Mice's DNS Glossary - SRV Record
- Rick van Rein's articles on SRV resource records Archiválva 2015. szeptember 17-i dátummal a Wayback Machine-ben
- 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
- ↑ draft-sanz-whois-srv-00 - Using DNS SRV records to locate whois servers. Tools.ietf.org, 2004. április 5. (Hozzáférés: 2013. május 20.)