SRV Kaydı Nedir ve Servis Tanımlama

Çoğu DNS kaydı size tek bir soruya cevap verir: "Bu alan adı hangi IP adresine gidiyor?" A kaydı bunu yapar, AAAA kaydı IPv6 için aynısını yapar, CNAME bir adı başka bir ada bağlar. Ama gerçek dünyada bir hizmete bağlanmak çoğu zaman yalnızca IP adresini bilmekten ibaret değildir. Bir e-posta istemcisinin sunucunuza ulaşması için hangi porta bağlanacağını, bir sohbet uygulamasının hangi makineyle konuşacağını, bir VoIP santralinin çağrıyı nereye yönlendireceğini de bilmesi gerekir. İşte SRV kaydı tam bu boşluğu doldurmak için tasarlanmıştır: bir servisin hangi sunucuda ve hangi portta çalıştığını DNS üzerinden ilan eder.

SRV (service) kaydının güzelliği, istemci tarafındaki sabit yapılandırmayı ortadan kaldırmasıdır. Kullanıcı programına elle "sunucu adresi şu, port bu" diye girmek yerine, uygulama sadece alan adını bilir ve gerisini DNS'e sorar. Bu sayede sunucu adresini ya da portunu değiştirdiğinizde tek yapmanız gereken SRV kaydını güncellemektir; binlerce istemciye tek tek dokunmanız gerekmez. Bu rehberde SRV kaydının alanlarını tek tek açacak, _service._proto isimlendirme kuralını netleştirecek, öncelik ve ağırlık mantığının nasıl yük dengelemeye dönüştüğünü göstereceğiz ve VoIP, XMPP ile Microsoft Autodiscover için gerçek örnekler üzerinden çalışacağız. Amacımız, panelde "SRV kaydı ekle" ekranını gördüğünüzde her alanın ne işe yaradığını bilmenizi sağlamak.

SRV Kaydı Nedir ve Ne İşe Yarar#

SRV kaydı, belirli bir servisin ağ üzerinde nerede bulunduğunu tarif eden bir DNS kayıt türüdür. RFC 2782 ile standartlaştırılmıştır ve temel olarak dört bilgiyi tek satırda birleştirir: hedef sunucunun adı, bağlanılacak port numarası, birden çok sunucu varsa hangisinin önce denenmesi gerektiğini belirten öncelik ve aynı önceliğe sahip sunucular arasında trafiği paylaştıran ağırlık. A kaydından farkı burada belirginleşir; A kaydı yalnızca "bu ad şu IP'dir" der ve porttan hiç bahsetmez. SRV ise "bu servis şu sunucuda, şu portta ve şu tercih sırasıyla çalışır" diye çok daha zengin bir cevap verir.

Bu kaydın işe yaraması için istemci uygulamanın SRV'yi arayacak biçimde yazılmış olması gerekir. Yani bir tarayıcı bir web sitesini açarken SRV kaydına bakmaz; standart HTTP protokolü SRV kullanmaz. Ama Autodiscover ile posta kutusu ayarlarını çeken bir Outlook, bir XMPP sohbet istemcisi ya da bir SIP telefonu, önce ilgili SRV kaydını sorgular, dönen sunucu ve porta göre bağlantısını kurar. DNS'in genel çalışma mantığını daha temelden merak ediyorsanız DNS nedir yazısı iyi bir başlangıç olur; SRV, o mantığın üzerine "servis keşfi" katmanı ekleyen özel bir uygulamadır.

SRV'nin en pratik faydası, servis taşımayı ve yedeklemeyi görünmez kılmasıdır. Sunucunuzu yeni bir makineye taşıdınız diyelim. İstemcilerde port ve adres sabit kodlanmış olsaydı herkesin ayarını değiştirmesi gerekirdi. SRV kaydı sayesinde tek bir DNS güncellemesiyle tüm istemcileri yeni hedefe yönlendirirsiniz. Aynı biçimde birden çok SRV kaydı ekleyerek birincil sunucu düştüğünde istemcinin otomatik olarak yedeğe geçmesini de sağlayabilirsiniz.

SRV Kaydının Yapısı ve Alanları#

SRV kaydı bölge dosyasında (zone file) tipik olarak şu biçimde görünür. Sol taraftaki isim özel bir kalıba uyar, sağ tarafta ise dört veri alanı sırayla dizilir:

; _servis._protokol.alanadi.   TTL   sınıf  tür   öncelik ağırlık port hedef
_sip._tls.ornek.com.           3600  IN     SRV   10      60     5061 sip1.ornek.com.

Bu satırı parça parça çözelim. _sip._tls.ornek.com. kaydın adıdır ve hangi servisi tanımladığını söyler. 3600 TTL değeridir, yani çözümleyicilerin bu cevabı kaç saniye önbellekte tutacağıdır. IN internet sınıfını, SRV de kayıt türünü belirtir. Asıl iş bundan sonraki dört alanda döner:

Öncelik ve ağırlık 0 ile 65535 arasında değer alır. Port, servisin dinlediği gerçek port numarasıdır ve buradaki en kritik ayrıntı budur; SRV'yi diğer kayıtlardan ayıran özellik zaten port bilgisini taşımasıdır. Hedef alanı ise bir IP adresi değil, bir ana bilgisayar adıdır ve genellikle sonunda nokta bulunan tam nitelikli bir addır (FQDN). İstemci bu hedef adı ayrıca bir A ya da AAAA sorgusuyla çözümleyerek gerçek IP'ye ulaşır. Yani SRV tek başına yeterli değildir; hedef sunucunun bir A/AAAA kaydının da bulunması şarttır.

Hedef alanına dair önemli bir istisna vardır. Bir servisin o alan adında hiç sunulmadığını açıkça belirtmek isterseniz, hedef olarak tek bir nokta (.) kullanılır:

_sip._tcp.ornek.com.   3600  IN  SRV   0  0  0  .

Bu kayıt "bu alan adında SIP servisi yoktur, aramayın" anlamına gelir ve istemcinin gereksiz yere bağlantı denemesini önler. Hedefe asla bir CNAME koymamalısınız; RFC gereği SRV hedefi doğrudan adres kaydına (A/AAAA) çözümlenmelidir, CNAME zinciri birçok istemcide sorun çıkarır.

_service._proto İsimlendirme Kuralı#

SRV kaydının en çok kafa karıştıran yanı, adının garip görünen _servis._protokol kalıbıdır. Bu kalıp keyfi değildir; her parçanın kesin bir anlamı vardır ve istemcinin doğru kaydı bulabilmesi için tam olarak bu biçimde yazılması gerekir. Genel şablon şöyledir:

_service._proto.name.

Buradaki _service, standartlaştırılmış bir servis adıdır ve başında alt çizgi bulunur. Örneğin SIP için _sip, XMPP sunucu bağlantısı için _xmpp-server, LDAP için _ldap kullanılır. Bu adlar IANA tarafından tutulan servis adları kaydından gelir. _proto ise taşıma protokolüdür ve neredeyse her zaman _tcp ya da _udp olur; bazı güvenli servislerde _tls de görürsünüz. name kısmı ise servisin sunulduğu alan adıdır; kök alan adı olabileceği gibi bir alt alan adı da olabilir.

Alt çizgilerin varlığı tesadüf değildir. Alt çizgiyle başlayan etiketler, geçerli bir ana bilgisayar adında bulunamaz. Bu tasarım, _sip._tcp.ornek.com gibi bir SRV adının, gerçek bir sunucu adı olan sip.ornek.com ile asla çakışmayacağını garanti eder. Böylece aynı alan adı altında hem servis keşif kayıtları hem de gerçek sunucular sorunsuzca bir arada yaşar. Aşağıdaki tablo en sık karşılaşılan servis/protokol kalıplarını özetler:

Bir istemci ornek.com için SIP servisini aradığında, doğrudan ornek.com alanına değil, _sip._tls.ornek.com adına SRV sorgusu gönderir. DNS bu adı çözer, dönen öncelik-ağırlık-port-hedef dörtlüsünü okur ve bağlantıyı ona göre kurar. Bu yüzden SRV kaydı eklerken en sık yapılan hata, servis ön ekini unutup kaydı doğrudan köke koymaktır; ön ek olmadan hiçbir istemci kaydı bulamaz.

Öncelik ve Ağırlık ile Yönlendirme#

SRV kaydının belki de en güçlü yanı, tek bir kayıt türüyle hem yedekleme (failover) hem de yük dengeleme sunabilmesidir. Bu iki davranış öncelik ve ağırlık alanlarıyla kontrol edilir ve mantığını bir kez anladığınızda çok esnek senaryolar kurabilirsiniz.

Öncelik (priority) birincil ve yedek sunucu sırasını belirler. Kural basittir: istemci her zaman en düşük öncelik değerine sahip sunucuları önce dener. Sadece o gruptaki tüm sunuculara ulaşılamadığında bir sonraki (daha yüksek sayılı) önceliğe geçer. Yani düşük sayı "daha öncelikli" demektir; bu, sezgiye biraz ters gelir ama MX kaydındaki mantığın aynısıdır. Aşağıdaki örnekte birincil SIP sunucusu 10 önceliğiyle, yedek ise 20 önceliğiyle tanımlanmıştır:

_sip._tls.ornek.com.  3600  IN  SRV  10  0  5061  sip-birincil.ornek.com.
_sip._tls.ornek.com.  3600  IN  SRV  20  0  5061  sip-yedek.ornek.com.

Burada istemci normal koşulda hep sip-birincil sunucusuna bağlanır. Yalnızca o sunucu yanıt vermediğinde sip-yedek devreye girer. Bu, servis kesintisine karşı basit ama etkili bir sigortadır.

Ağırlık (weight) ise aynı önceliğe sahip sunucular arasında trafiği paylaştırır. İki sunucu aynı öncelik değerine sahipse, istemci onları ağırlıkları oranında seçer. Örneğin daha güçlü bir sunucuya trafiğin dörtte üçünü, daha zayıf olana dörtte birini yönlendirmek isterseniz:

_sip._tls.ornek.com.  3600  IN  SRV  10  75  5061  sip-guclu.ornek.com.
_sip._tls.ornek.com.  3600  IN  SRV  10  25  5061  sip-zayif.ornek.com.

Bu iki kayıt aynı önceliktedir (10), dolayısıyla istemci ikisi arasında seçim yapar. Ağırlıklar 75 ve 25 olduğundan bağlantıların yaklaşık yüzde 75'i güçlü sunucuya, yüzde 25'i zayıf sunucuya gider. Ağırlık değerlerinin toplamının 100 olması zorunlu değildir; önemli olan orandır. 60 ve 20 yazsanız da aynı 3'e 1 dağılımını elde edersiniz. Bir sunucuya hiç trafik gitmemesini istiyorsanız ağırlığını 0 yaparsınız; ağırlık 0 olan bir sunucu yalnızca diğerlerinin hepsi ağırlık 0 olduğunda seçilebilir hâle gelir.

Öncelik ve ağırlığı birlikte kullanarak katmanlı bir mimari kurabilirsiniz: aynı öncelikte iki sunucuyu ağırlıkla dengeler, bir de daha yüksek öncelikli bir yedek eklersiniz. Bu, DNS üzerinden yük dengeleme konusuna ilgi duyanlar için sağlam bir başlangıçtır; benzer mantığı A kayıtlarıyla round-robin biçiminde de görürsünüz ama SRV, port ve tercih sırasını da eklediği için çok daha kontrollüdür. Uygulama sunucusu tarafında gerçek yük dengeleme ve yüksek erişilebilirlik kurmak isterseniz sunucu yönetimi hizmeti bu tasarımı sizin adınıza planlar.

VoIP, XMPP ve Microsoft için Gerçek Örnekler#

SRV kaydını gerçekten anlamanın en iyi yolu, onu günlük hayatta kullanan servislere bakmaktır. Üç yaygın senaryoyu somut değerlerle ele alalım.

VoIP / SIP santralı. Kurumsal telefon sistemleri SIP protokolü üzerinden çalışır ve istemcilerin santralı bulması için SRV kaydına başvurur. Genellikle hem şifreli (TLS) hem de şifresiz sinyalleşme için ayrı kayıtlar tanımlanır. Aşağıdaki örnek, bir alan adının SIP servisini birincil ve yedek sunucularla ilan eder:

_sip._tls.ornek.com.   3600  IN  SRV  10  60  5061  pbx1.ornek.com.
_sip._tls.ornek.com.   3600  IN  SRV  10  40  5061  pbx2.ornek.com.
_sip._udp.ornek.com.   3600  IN  SRV  20  0   5060  pbx1.ornek.com.
_sips._tcp.ornek.com.  3600  IN  SRV  10  60  5061  pbx1.ornek.com.

Bir IP telefonu ya da yazılım tabanlı softphone, ornek.com hesabıyla oturum açtığında _sip._tls.ornek.com kaydını sorgular, 10 önceliğindeki iki santral arasında ağırlığa göre seçim yapar ve 5061 portundan güvenli bağlantı kurar. Kullanıcı hiçbir sunucu adresi ya da port girmez.

XMPP sohbet sunucusu. Kendi mesajlaşma altyapısını kuran ekipler XMPP protokolünü sıkça kullanır. XMPP iki tür SRV kaydına ihtiyaç duyar: biri istemcilerin bağlanması için (_xmpp-client), diğeri sunucular arası federasyon için (_xmpp-server).

_xmpp-client._tcp.ornek.com.  3600  IN  SRV  5  0  5222  chat.ornek.com.
_xmpp-server._tcp.ornek.com.  3600  IN  SRV  5  0  5269  chat.ornek.com.

Bu iki kayıt sayesinde [email protected] biçiminde bir hesap oluşturduğunuzda, istemci _xmpp-client._tcp.ornek.com sorgusuyla chat.ornek.com sunucusunu 5222 portunda bulur; başka bir XMPP sunucusu sizinle federasyon kurmak istediğinde ise 5269 portunu kullanır. Kendi barındırdığınız mesajlaşma, takvim ya da bulut uygulamalarını denemek isterseniz uygulama merkezi üzerinden hazır kurulumlar ilgili SRV kayıtlarını da içeren yapılandırma önerileriyle gelir.

Microsoft Autodiscover. Outlook ve Exchange dünyasında Autodiscover, kullanıcının yalnızca e-posta adresini ve parolasını girmesiyle tüm posta kutusu ayarlarının otomatik bulunmasını sağlar. Bu keşfin bir adımı SRV kaydıdır:

_autodiscover._tcp.ornek.com.  3600  IN  SRV  0  0  443  autodiscover.ornek.com.

Outlook, kullanıcı [email protected] yazdığında Autodiscover uç noktasını bulmak için _autodiscover._tcp.ornek.com kaydını sorgular, dönen hedefe 443 portundan bağlanır ve posta kutusu ayarlarını çeker. Microsoft 365 kullanıyorsanız benzer biçimde Teams/Skype federasyonu için _sipfederationtls._tcp ve _sip._tls SRV kayıtları da tanımlanır. Bu tür e-posta ve iş birliği altyapısını kurarken SRV kayıtları, SPF, DKIM ve DMARC gibi TXT tabanlı kayıtlarla birlikte çalışır; biri istemci yapılandırmasını, diğerleri gönderim güvenliğini üstlenir. Kurumsal profesyonel e-posta hizmetini devreye alırken sağlayıcının verdiği SRV ve TXT değerlerini birlikte eklemeniz gerekir.

SRV Kaydı Nasıl Oluşturulur ve Doğrulanır#

SRV kaydı eklemek panelden panele biraz farklı görünse de mantık her yerde aynıdır. Çoğu kontrol panelinin DNS/Zone Editor bölümünde SRV için ayrı alanlar bulunur; öncelik, ağırlık, port ve hedefi ayrı kutulara girersiniz, ad kısmına da _servis._protokol ön ekini yazarsınız. Tipik bir akış şöyle işler:

1. DNS bölgesine erişin. Hosting ya da alan adı yönetim panelinizde ilgili alan adının DNS Editor bölümünü açın.
2. Kayıt türü olarak SRV seçin. Yeni kayıt ekle deyip tür listesinden SRV'yi işaretleyin.
3. Servis ve protokolü girin. Ad alanına _sip._tls gibi ön eki yazın. Bazı paneller servis ve protokolü ayrı kutularda ister; o zaman Service alanına _sip, Protocol alanına _tls yazarsınız.
4. Öncelik, ağırlık ve portu girin. İlgili kutulara sayısal değerleri (örneğin 10, 60, 5061) yazın.
5. Hedefi girin. Servisin çalıştığı sunucunun tam adını (pbx1.ornek.com) yazın; bir IP değil, ad girin ve o adın bir A/AAAA kaydı olduğundan emin olun.
6. TTL belirleyin ve kaydedin. Yaygın varsayılan 3600 saniyedir; test aşamasında 300 gibi düşük bir değer yayılmayı hızlandırır.

Kaydın gerçekten yayına çıkıp çıkmadığını komut satırından doğrulamak, panelin "kaydedildi" mesajına güvenmekten çok daha güvenilirdir. dig bu iş için idealdir:

# SIP SRV kaydını sorgula
dig +short SRV _sip._tls.ornek.com

# XMPP istemci kaydını sorgula
dig SRV _xmpp-client._tcp.ornek.com +noall +answer

# Autodiscover kaydını belirli bir çözümleyiciden sorgula
dig @1.1.1.1 SRV _autodiscover._tcp.ornek.com +short

dig +short SRV komutunun çıktısı tam olarak dört alanı sırayla gösterir: öncelik, ağırlık, port ve hedef. Örneğin 10 60 5061 pbx1.ornek.com. gibi bir satır görürseniz kayıt doğru yapılandırılmış demektir. Windows tarafında aynı sorguyu nslookup ile yapabilirsiniz:

nslookup -type=SRV _sip._tls.ornek.com

Kendi DNS sunucunuzu işletiyorsanız bölge dosyasını elle düzenlerken sözdizimini named-checkzone gibi araçlarla doğrulamak, hatalı bir SRV satırının tüm bölgeyi geçersiz kılmasını önler. SRV satırındaki alanların sırası kritik olduğu için, öncelik ve port değerlerini yanlışlıkla yer değiştirmek çok sık yapılan bir hatadır; doğrulama adımı bunları erken yakalar.

Yaygın Hatalar ve Sorun Giderme#

SRV kayıtları küçük ama etkili hatalara açıktır çünkü tek bir yanlış alan bütün servis keşfini bozar. En sık karşılaşılan sorunları ve çözümlerini bir arada toplamak, sorun giderme sürecini hızlandırır.

En yaygın hata, servis ön ekini yanlış ya da eksik yazmaktır. _sip._tls yerine sip.tls yazmak (alt çizgileri unutmak) ya da protokolü karıştırmak (_tcp gerekirken _udp yazmak) istemcinin kaydı hiç bulamamasına yol açar. İkinci sık hata, hedef olarak IP adresi girmektir. SRV hedefi bir ana bilgisayar adı olmalıdır; IP yazarsanız birçok çözümleyici kaydı geçersiz sayar. Üçüncüsü, hedefe CNAME koymaktır. RFC hedefin doğrudan A/AAAA kaydına çözümlenmesini şart koşar; CNAME zinciri bazı istemcilerde sessizce başarısız olur.

Aşağıdaki tablo tipik belirtileri olası nedenlerle eşleştirir:

Bir de güvenlik duvarı boyutu vardır. SRV kaydı doğru olsa bile, hedef sunucuda ilgili port dışarıya kapalıysa istemci yine bağlanamaz. Bu yüzden SRV kaydını doğruladıktan sonra portun gerçekten erişilebilir olduğunu da sınamak gerekir; örneğin nc -vz pbx1.ornek.com 5061 komutuyla portun açık olup olmadığını hızlıca test edebilirsiniz. Sunucu güvenlik duvarı ve port yönetimi konusunda desteğe ihtiyaç duyarsanız, hosting altyapınızı uygun bir barındırma paketiyle yönetmek ya da tam kontrol için sunucu çözümlerine geçmek bu tür yapılandırmaları çok daha rahat hâle getirir. Alan adı tarafında da SRV dahil tüm kayıtları tek panelden yönetmek isterseniz alan adı hizmetimiz DNS düzenleyicisiyle birlikte gelir.

Sıkça Sorulan Sorular#

SRV kaydı ile A kaydı arasındaki fark nedir?#

A kaydı bir alan adını yalnızca bir IP adresine bağlar ve port bilgisi taşımaz; bu yüzden hangi servisin hangi portta çalıştığı hakkında hiçbir şey söylemez. SRV kaydı ise bir servisin hangi sunucuda, hangi portta ve hangi tercih sırasıyla çalıştığını birlikte belirtir. Aslında ikisi çoğu zaman birlikte kullanılır: SRV kaydı hedef olarak bir ana bilgisayar adı gösterir, o adın gerçek IP'sini bulmak için ayrıca bir A ya da AAAA kaydı gerekir. Kısacası A kaydı "bu ad neredeyi", SRV ise "bu servis nerede ve hangi porttayı" cevaplar.

Her hizmet SRV kaydını kullanır mı?#

Hayır, SRV kaydını yalnızca onu arayacak biçimde tasarlanmış uygulamalar kullanır. Web tarayıcıları standart HTTP ve HTTPS için SRV sorgusu yapmaz; bir web sitesini açmak için A/AAAA ve gerektiğinde CNAME kayıtları yeterlidir. Buna karşılık SIP tabanlı VoIP istemcileri, XMPP sohbet uygulamaları, Microsoft Autodiscover, LDAP ve Kerberos gibi servisler SRV kaydına başvurur. Bu yüzden bir servis için SRV kaydı eklemeden önce o servisin gerçekten SRV kullanıp kullanmadığını sağlayıcının dokümanından kontrol etmek gerekir.

SRV kaydında öncelik ve ağırlık nasıl çalışır?#

Öncelik sunucuların denenme sırasını belirler ve düşük sayı daha önceliklidir; istemci önce en düşük öncelikteki sunuculara bağlanmayı dener, hepsi başarısız olursa bir üst önceliğe geçer. Ağırlık ise aynı önceliğe sahip sunucular arasında trafiği oransal olarak paylaştırır. Örneğin ikisi de 10 önceliğinde olan iki sunucudan biri 75, diğeri 25 ağırlığındaysa, bağlantıların yaklaşık dörtte üçü birinci sunucuya gider. Böylece öncelikle yedekleme, ağırlıkla da yük dengeleme aynı kayıt türüyle sağlanmış olur.

SRV kaydının hedefine IP adresi yazabilir miyim?#

Bunu yapmamalısınız; SRV kaydının hedef alanı bir IP adresi değil, bir ana bilgisayar adı beklemek üzere tasarlanmıştır. Hedefe doğrudan IP yazarsanız birçok çözümleyici ve istemci kaydı geçersiz kabul eder. Doğru yaklaşım, hedef olarak pbx1.ornek.com gibi bir ad girmek ve o adın bir A ya da AAAA kaydıyla ilgili IP'ye çözümlenmesini sağlamaktır. Bu ekstra adım gereksiz görünebilir ama sunucunun IP'si değiştiğinde tek bir A kaydını güncellemeniz yeterli olur, SRV'ye dokunmanız gerekmez.

SRV kaydı eklediğimde neden hemen çalışmıyor?#

DNS değişiklikleri önbellek nedeniyle anında yayılmaz; kaydın eski TTL süresi boyunca çözümleyiciler önceki cevabı bellekten sunmaya devam edebilir. Bu yüzden yeni bir SRV kaydı bazen birkaç dakika, bazen bir saate kadar süren bir gecikmeyle görünür hâle gelir. Beklemek yerine dig +short SRV _servis._protokol.alanadiniz.com komutuyla kaydın gerçekten yayına çıkıp çıkmadığını doğrulayabilirsiniz. Kayıt dig çıktısında doğru öncelik, ağırlık, port ve hedefle göründükten sonra da istemci hâlâ bağlanamıyorsa, sorun büyük olasılıkla DNS'te değil hedef sunucuda ya da güvenlik duvarındadır.

Bir servis için birden fazla SRV kaydı olabilir mi?#

Evet, aynı _servis._protokol adı altında birden fazla SRV kaydı bulunması hem mümkün hem de çok yaygındır. Yedekleme ve yük dengeleme zaten bu şekilde kurulur: aynı ad altında farklı öncelik ve ağırlıklarla birden çok hedef tanımlarsınız. Örneğin bir birincil, bir de yedek santral için iki _sip._tls kaydı ekleyebilir, ya da yükü paylaştırmak üzere aynı öncelikte iki sunucuyu farklı ağırlıklarla listeleyebilirsiniz. İstemci bu kayıtların tümünü alır ve öncelik ile ağırlık kurallarına göre hangisine bağlanacağına karar verir.

Kapanış#

SRV kaydı, DNS'in "servis keşfi" katmanıdır. A kaydının bıraktığı boşluğu doldurarak bir servisin yalnızca hangi sunucuda değil, aynı zamanda hangi portta çalıştığını ve birden çok sunucu arasında hangi tercih sırasıyla bağlanılması gerektiğini ilan eder. _servis._protokol isimlendirme kuralını, öncelik ile ağırlığın nasıl yedekleme ve yük dengelemeye dönüştüğünü ve hedefin neden bir IP değil ad olması gerektiğini içselleştirdiğinizde, VoIP santralından XMPP sohbetine, Microsoft Autodiscover'dan dizin servislerine kadar pek çok modern hizmetin altyapısını rahatça yapılandırabilirsiniz.

Alan adı, DNS ve servis kayıtlarını tek bir yerden profesyonelce yönetmek hem işleri hızlandırır hem de bu tür ince hataların önüne geçer. Clou.TR ile alan adınızı ve tüm DNS kayıtlarınızı tek panelden düzenleyebilir, SIP, XMPP ya da e-posta gibi servislerinizi barındırmak için hosting paketlerinden ya da tam kontrol sunan sunucu çözümlerinden yararlanabilir, kurumsal e-posta hizmetini Autodiscover ve gönderim güvenliği kayıtları hazır şekilde devreye alabilirsiniz. Kurulum ve bakım yükünü uzman bir ekibe bırakmak isterseniz sunucu yönetimi hizmetimiz SRV kayıtlarınızdan güvenlik duvarı kurallarınıza kadar her ayrıntıyı sizin adınıza güvenle üstlenir.