SRV Kaydı Nedir? Hangi Servislerde Kullanılır?

Bir e-posta istemcisi sunucuyu otomatik buluyor, bir VoIP sistemi doğru proxy'e yönleniyor — ama DNS'e bakıldığında A veya CNAME kaydı yok. Bu davranışın arkasında SRV kaydı var; servis adresini ve portunu DNS üzerinden duyurmanın standart yolu. İstemci uygulaması, bir servise bağlanmak istediğinde doğrudan sabit bir IP veya port yerine DNS'i sorgular ve SRV kaydından hem hedefi hem de bağlantı parametrelerini öğrenir.

SRV (Service) kaydı, standart DNS kayıt türleri arasında en az tanınan ama belirli protokoller için vazgeçilmez olandır. MX kaydının e-posta sunucusunu bildirmesine benzer biçimde SRV kaydı da belirli bir servise ait sunucu ve portu bildirir — ancak tek bir domain için değil, servis ve protokol kombinasyonu için. Bu fark, SRV'nin hem daha esnek hem de daha karmaşık bir yapıya sahip olmasını açıklar.

SRV kaydının değeri yalnızca istemciye hedefi söylemesinde değil, birden fazla sunucu arasında öncelik ve ağırlık bazlı yük dağılımı yapabilmesinde yatar. Aynı servis için birkaç SRV kaydı eklendiğinde istemci bunları birer birer deneyebilir; birincil sunucu yanıt vermezse ikinciye, oradan da üçüncüye geçer. Bu mekanizma, harici bir yük dengeleyiciye gerek kalmadan DNS seviyesinde yedeklilik sağlar.

SRV kaydının sözdizimi: beş alanın anatomisi

SRV kaydının en belirgin özelliği, kayıt adının servis ve protokol bilgisini de taşımasıdır. A veya CNAME kayıtlarında kayıt adı yalnızca bir subdomain ya da apex domain olurken SRV'de ad üç bölümden oluşur: alt çizgiyle başlayan servis adı, yine alt çizgiyle başlayan protokol ve domain. Bu yapı sayesinde DNS sorgulayan istemci doğrudan ilgilendiği servisin kaydına gider.

_servis._protokol.domain.  TTL  IN  SRV  öncelik  ağırlık  port  hedef.

Örnek:
_sip._tcp.example.com.  300  IN  SRV  10  20  5060  sip1.example.com.
_sip._tcp.example.com.  300  IN  SRV  10  80  5060  sip2.example.com.
_sip._tcp.example.com.  300  IN  SRV  20  0   5060  sip-yedek.example.com.

Beş alan şunu ifade eder. Servis adı (_sip, _xmpp, _autodiscover gibi) hangi uygulama protokolünün sorgulandığını gösterir; bu isimler IANA tarafından standartlaştırılmıştır ve her protokolün resmi kaydı vardır. Protokol (_tcp ya da _udp) iletim katmanını belirtir; bazı servisler her ikisi için de ayrı kayıt yayımlar. Öncelik, sayısal olup düşük değer daha yüksek önceliği temsil eder — MX kaydındaki öncelik mantığının aynısı. Ağırlık, aynı öncelikteki sunucular arasındaki trafik dağılımını belirler; büyük ağırlık daha fazla trafik demektir. Port, servise ait TCP veya UDP portu. Hedef, sunucunun tam nitelikli alan adı — nokta ile bitmeli, IP adresi yazılamaz.

Hedef alanın IP adresi kabul etmemesi önemli bir kısıtlamadır. SRV kaydında hedef olarak her zaman bir hostname verilmeli; bu hostname'in A veya AAAA kaydı ayrıca bulunmalıdır. Yani SRV kaydı tek başına yeterli değildir; hedefe karşılık gelen adres kaydı da zone'da yer almalıdır. Bazı DNS sağlayıcıları bu "glue" kaydı ilişkisini otomatik yönetir; bazılarında A kaydını ayrıca eklemek gerekir.

TTL değeri için genel kural, diğer dinamik kayıtlarla tutarlı olmak ve değişiklik planlanıyorsa önceden düşürmektir. SRV kayıtları genellikle 300–3600 saniye arasında tutulur. Servis migrasyonu öncesinde TTL'i düşürüp propagasyonun tamamlanmasını beklemek, geçiş sırasındaki kesintiyi minimize eder.

Hangi servisler SRV kaydı kullanır ve neden?

SRV kaydına olan ihtiyaç, belirli bir uygulamanın standart port numarasından farklı bir portta çalışması ya da birden fazla sunucu arasında yük dağılımı gerektirmesi durumunda ortaya çıkar. Her uygulama SRV'yi desteklemez; protokol spesifikasyonunda SRV sorgusunun zorunlu ya da önerilen bir adım olarak tanımlanmış olması gerekir.

SIP (Session Initiation Protocol), VoIP altyapısının temel protokolüdür ve SRV kaydını birincil servis keşif mekanizması olarak kullanır. Bir SIP istemcisi yapılandırmada yalnızca domain adını görüp bağlanmaya çalıştığında önce _sip._tcp.domain ya da _sip._udp.domain kaydını sorgular. SRV'den aldığı bilgiyle doğru proxy'e, doğru porta yönlenir. Birden fazla SRV kaydı varsa önceliğe göre dener; birincisi yanıt vermezse diğerine geçer. Bu mekanizma, SIP altyapısını istemci yapılandırmasından bağımsız kılar: sunucu taşındığında ya da port değiştiğinde istemcilerin tek tek güncellenmesi yerine yalnızca SRV kaydı düzenlenir.

XMPP (Extensible Messaging and Presence Protocol), anlık mesajlaşma ve varlık bildirimi için kullandığı SRV kayıtlarını istemci ve sunucu bağlantıları için ayrı ayrı tanımlar. İstemci bağlantıları için _xmpp-client._tcp, sunucular arası federasyon için _xmpp-server._tcp kaydı sorgulanır. Bu ayrım, aynı domain için farklı portlarda farklı sunuculara yönlendirme yapılmasını mümkün kılar.

_xmpp-client._tcp.example.com.  300  IN  SRV  5  0  5222  xmpp.example.com.
_xmpp-server._tcp.example.com.  300  IN  SRV  5  0  5269  xmpp.example.com.

Microsoft Exchange ve Office 365 Autodiscover mekanizması, e-posta istemcilerinin hesap ayarlarını otomatik keşfetmesini SRV kaydı aracılığıyla sağlar. Outlook gibi bir istemci, hesap kurulumunda yalnızca e-posta adresini görüp önce _autodiscover._tcp.domain kaydını sorgular. Bu kayıt yoksa alternatif yöntemlere geçer — ama SRV varsa yapılandırma sunucusunu ve portunu DNS'ten öğrenir, kullanıcıdan ekstra bilgi almak gerekmez.

_autodiscover._tcp.example.com.  300  IN  SRV  0  0  443  autodiscover.example.com.

Minecraft sunucuları, oyuncuların standart port (25565) dışında bir portta çalışan sunucuya bağlanmasına izin vermek için SRV kaydını kullanır. Sunucu adresi olarak play.example.com paylaşılabilir; oyuncu bağlantı kurduğunda istemci _minecraft._tcp.play.example.com sorgular ve gerçek sunucu adresiyle portu SRV'den öğrenir. Bu, kullanıcıya play.example.com:19132 yerine yalnızca play.example.com vermek anlamına gelir.

CalDAV ve CardDAV (takvim ve rehber senkronizasyonu), LDAP (dizin servisi) ve bazı oyun platformlarının matchmaking mekanizmaları da SRV kaydı kullanan protokoller arasındadır. Ortak nokta şudur: istemci uygulaması, bağlanmadan önce DNS'i sorgulamayı protokol spesifikasyonunun bir gereği olarak uygular.

Birden fazla SRV kaydında öncelik ve ağırlık mekanizması

SRV'nin en güçlü yanı, aynı servis için birden fazla kayıt tanımlandığında istemcinin bu kayıtlar arasında nasıl seçim yapacağını belirleyen yapılandırılmış bir mekanizma sunmasıdır. Bu mekanizma iki katmanlıdır: önce öncelik, sonra ağırlık devreye girer.

İstemci önce en düşük öncelik değerine sahip kayıtları toplar ve yalnızca bu gruptaki sunucuları dener. Düşük öncelik değeri daha yüksek tercih anlamına gelir; yani öncelik 10 olan kayıt, öncelik 20 olandan önce denenir. Bu gruptaki sunuculara ulaşılamadığı durumda bir sonraki öncelik grubuna geçilir. Yapı, birincil sunucu grubu ile yedek sunucu grubu arasında net bir hiyerarşi kurar.

; Birincil grup (öncelik 10) — toplam ağırlık 100
_sip._tcp.example.com.  300  IN  SRV  10  70  5060  sip-a.example.com.
_sip._tcp.example.com.  300  IN  SRV  10  30  5060  sip-b.example.com.

; Yedek grup (öncelik 20) — birincil gruptaki tüm sunucular çevrimdışıysa
_sip._tcp.example.com.  300  IN  SRV  20  0   5060  sip-backup.example.com.

Aynı öncelik grubundaki sunucular arasında seçim yaparken ağırlık değerleri belirleyicidir. İstemci her sunucunun ağırlığını toplam ağırlığa bölerek bir olasılık hesaplar; ardından bu olasılıkla rastgele seçim yapar. Yukarıdaki örnekte sip-a trafiğin %70'ini, sip-b ise %30'unu alır. Bu, DNS seviyesinde kaba bir yük dağılımı sağlar — tam anlamıyla yük dengeleme değildir, çünkü her istemci bağımsız seçim yapar ve aktif bağlantı sayısını bilemez.

Ağırlık değeri 0 olan kayıtlar, aynı gruptaki ağırlıklı kayıtlardan sonra ve eşit olasılıkla denenir. Yedek sunucu için tipik yaklaşım, onu daha yüksek öncelik değerine koymaktır; böylece birincil grup tamamen çevrimdışı olmadan yedek hiç denenmez. Yedek sunucunun ağırlığını 0 yapmak ise yalnızca onu aynı öncelik grubundaki diğer sunuculardan sonraya almak için kullanılır.

Aynı servis için SRV kayıtlarının TTL değerleri birbirinden farklı olmamalıdır. Farklı TTL'ler önbelleğe alınan kaydın hangi sunucuyu gösterdiğini karmaşık hale getirir ve özellikle failover senaryolarında istemcinin eski bilgiyle bağlanmaya çalışmasına neden olabilir. TTL optimizasyonu açısından bakıldığında, tüm SRV kayıtlarını aynı TTL değeriyle tutmak ve değişiklik planlanıyorsa birlikte düşürmek en temiz yaklaşımdır.

SRV kaydını dig ile sorgulama ve doğrulama

SRV sorgusunda kayıt adını tam olarak vermek zorundasınız. dig example.com SRV komutu domain'in SRV kaydını aramaz; yalnızca apex domain için SRV araması yapar ve çoğu durumda boş sonuç döner. Sorgu, servis ve protokol öneklerini içeren tam ad üzerinden yapılmalıdır.

# SIP servisi için SRV sorgulama
dig _sip._tcp.example.com SRV

# XMPP istemci bağlantısı
dig _xmpp-client._tcp.example.com SRV

# Exchange Autodiscover
dig _autodiscover._tcp.example.com SRV

# Kısa çıktı formatı
dig _sip._tcp.example.com SRV +short

# Örnek çıktı:
# 10 70 5060 sip-a.example.com.
# 10 30 5060 sip-b.example.com.
# 20 0  5060 sip-backup.example.com.

Çıktıdaki sütun sırası öncelik, ağırlık, port ve hedef şeklindedir. Hedefin nokta ile bittiğini doğrulamak gerekir; noktasız bir hedef bazı resolver'larda domain soneki eklenmesi sorununa yol açar. Hedefin A kaydını ayrıca kontrol etmek de doğrulama sürecinin bir parçasıdır:

# SRV hedefinin çözümlendiğini doğrula
dig sip-a.example.com A +short
# Beklenen çıktı: 203.0.113.10

# Tüm SRV kayıtlarını ANSWER bölümüyle göster
dig _sip._tcp.example.com SRV +noall +answer

SRV kaydı eklendikten sonra propagasyonu beklemeden test yapmak için authoritative nameserver'ı doğrudan sorgulamak daha güvenilir sonuç verir:

# Authoritative nameserver'ı bul
dig NS example.com +short

# SRV'yi doğrudan authoritative'ten sorgula
dig _sip._tcp.example.com SRV @ns1.example.com +short

Bazı managed DNS sağlayıcıları SRV kaydı için ayrı bir form sunar; servis, protokol ve domain'i ayrı alanlara girdikten sonra tam kayıt adını otomatik birleştirir. Bu arayüzlerde alt çizgileri dahil etmeden yalnızca sip ya da xmpp-client yazmak yeterli olabilir. Kayıt oluşturulduktan sonra gerçekte ne yazıldığını kontrol etmek — çünkü bazı sağlayıcılar kayıt adını farklı formatlarda saklar — doğrulama adımı olarak önemlidir.

Yapılandırmada sık yapılan hatalar

SRV kaydındaki en yaygın hata, hedef alanına hostname yerine IP adresi yazmaktır. RFC 2782 bunu açıkça yasaklar; hedef mutlaka bir alan adı olmalıdır. IP adresi girildiğinde bazı DNS sağlayıcıları hata verir, bazıları kabul eder ama istemciler bu kaydı işleyemez ya da beklenmedik biçimde davranır. Doğru yaklaşım her zaman bir hostname yazmak ve o hostname için ayrı bir A kaydı oluşturmaktır.

İkinci yaygın hata, hedef alan adını nokta olmadan bitirmektir. DNS'te tam nitelikli alan adı (FQDN) her zaman nokta ile biter; noktasız bırakıldığında bazı resolver'lar zone origin'ini sonuna ekler. sip1.example.com yerine sip1.example.com. yazmak, bu sorundan korunmanın en basit yoludur. Çoğu modern DNS yönetim arayüzü bunu otomatik tamamlar, ama ham zone dosyasıyla çalışıyorsanız noktayı manuel eklemeniz gerekir.

Üçüncü hata, öncelik ve ağırlık değerlerinin mantığını karıştırmaktır. Öncelikte düşük değer yüksek tercihe karşılık gelir; ağırlıkta büyük değer daha fazla trafik alır. MX kaydındaki öncelik mantığı ile aynıdır — ama ağırlık kavramı MX'te yoktur, bu nedenle SRV'ye özgü bir karışıklık kaynağı olur. Yedek sunucuyu daha düşük önceliğe koymak yerine yanlışlıkla daha düşük ağırlığa koymak, yedek sunucunun birincil grupta düşük oranda trafik alması anlamına gelir — beklendiği gibi yalnızca birincil çevrimdışıyken devreye girmez.

Dördüncü hata, servis adı veya protokol önekini alt çizgi olmadan yazmaktır. sip._tcp.example.com geçersizdir; doğrusu _sip._tcp.example.com'dur. Alt çizgi, servis etiketini olağan subdomain'lerden ayırt etmek için RFC 2782'de zorunlu kılınmıştır. Bu olmadan sorgu doğru kayda ulaşmaz ve istemci SRV bulamadığı için alternatiflere geçer ya da bağlanamaz.

Son olarak, SRV kaydını doğruladıktan sonra istemci tarafını da test etmeyi atlamak sık görülen bir eksikliktir. DNS'te kayıt doğru görünse bile istemcinin SRV sorgusunu gerçekten gönderip göndermediği, aldığı yanıtı doğru işleyip işlemediği ayrıca doğrulanmalıdır. Bazı uygulamalar SRV sorgusunu yalnızca belirli bir yapılandırma modunda yapar; "otomatik" ya da "SRV tabanlı keşif" seçeneği açık değilse sabit sunucu adresine bağlanmaya devam eder. Subdomain yönetimi açısından bakıldığında, SRV hedefi için kullanılan subdomain'lerin zone'da eksiksiz tanımlı olduğunu da kontrol etmek gerekir.

SRV kaydı, belirli protokollerin DNS'i servis keşfi için kullandığı yapılandırılmış bir standarttır. Sözdizimi ilk bakışta karmaşık görünse de beş alanın her birinin rolü nettir ve bir kez kavrandığında yapılandırma ve sorun giderme oldukça öngörülebilir hale gelir. SRV sorgusunu destekleyen bir protokol çalıştırıyorsanız bu kaydı doğru kurmak, istemci yapılandırmasını merkezi bir DNS kaydına bağlamanın ve altyapı değişikliklerini istemcilerden bağımsız yönetmenin en temiz yoludur.