Ugrás a tartalomhoz

Szolgáltatásrekord

Ellenőrzött
A Wikipédiából, a szabad enciklopédiából

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és]

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

[szerkeszté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

[szerkesztés]

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

[szerkesztés]
_msdcs az Active Directoryban

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:

  • _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és]

Szolgáltatásrekordokat használnak a következő szabványosított kommunikációs protokollok:

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]

Jegyzetek

[szerkesztés]
  1. TechNet Klub: Rendszerfelügyelet rendszergazdáknak. [2015. szeptember 27-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. szeptember 26.)
  2. TechNet: SRV Resource Records
  3. [Suggestion] TS DNS. Forum.teamspeak.com. (Hozzáférés: 2013. október 25.)
  4. Archivált másolat. [2015. szeptember 29-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. szeptember 26.)
  5. Hostnames for the Master and Slave KDCs. Web.mit.edu. (Hozzáférés: 2012. május 23.)
  6. RFC 3088 - OpenLDAP Root Service An experimental LDAP referral service. Faqs.org. (Hozzáférés: 2012. május 23.)
  7. 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.)
  8. XEP-0156: Discovering Alternative XMPP Connection Methods. Xmpp.org. (Hozzáférés: 2012. május 23.)
  9. Sablon:Cite IETF
  10. Microsoft Office365. Microsoft.com. (Hozzáférés: 2014. június 24.)
  11. Configuring Email-Based Account Discovery for Citrix Receiver. Citrix. (Hozzáférés: 2014. június 24.)
  12. 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.)
  13. 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]
  1. 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.)