Round-Robin DNS Nedir

Round-robin DNS, tek bir alan adı için birden çok IP adresi tanımlayıp gelen sorgulara bu adresleri sırayla döndürerek trafiği kabaca dağıtmaya yarayan çok eski ve çok basit bir tekniktir. Fikir son derece sadedir: www.example.com için tek bir A kaydı yerine üç, dört, hatta on tane A kaydı tanımlarsınız; ad sunucusu her sorguda listeyi bir kaydırarak farklı bir sıralamayla cevap verir. Böylece ziyaretçilerin bir kısmı birinci sunucuya, bir kısmı ikinciye, bir kısmı üçüncüye bağlanır. Ortada özel bir donanım, pahalı bir yük dengeleyici veya karmaşık bir yazılım yoktur; işi yapan sadece DNS'in kendisidir.

Bu basitlik hem round-robin DNS'in en büyük cazibesi hem de en büyük tuzağıdır. Kurulumu beş dakikalık bir iş olduğu için "ücretsiz yük dengeleme" gibi görünür, ama arka planda hiçbir sağlık kontrolü, oturum takibi veya akıllı yönlendirme yoktur. Çöken bir sunucuya trafik göndermeye devam eder, sunucuların yükünü gerçekten ölçmez ve DNS önbelleği yüzünden dağılım hiçbir zaman matematiksel olarak eşit olmaz. Bu rehberde tekniğin nasıl çalıştığını, gerçek failover'dan neden farklı olduğunu, hangi senaryolarda işe yaradığını ve nerede sizi yanılttığını kıdemli bir sistem yöneticisinin gözünden, gerçek örneklerle anlatıyoruz. DNS'in temellerine hâkim değilseniz önce DNS nedir yazımıza göz atmanızı öneririm; buradaki kavramlar oranın üzerine inşa ediliyor.

Round-Robin DNS Nasıl Çalışır#

Klasik bir DNS kaydında bir alan adına tek bir IP verirsiniz ve tüm dünya oraya bağlanır. Round-robin'de ise aynı isme birden fazla A (IPv4) veya AAAA (IPv6) kaydı eklersiniz. Ad sunucusu sorgu geldiğinde bu kayıtların tamamını döndürür, ancak her cevapta listenin sırasını bir eleman kaydırır. Yani ilk kullanıcıya [.10, .11, .12], ikinciye [.11, .12, .10], üçüncüye [.12, .10, .11] şeklinde cevap verilir.

Önemli nokta şudur: yönlendirmeyi aslında istemci yapar. DNS istemcileri (işletim sistemi ve tarayıcı) çoğunlukla dönen listenin ilk kaydını kullanır. Ad sunucusu her seferinde farklı bir kaydı başa aldığı için istatistiksel olarak trafik farklı IP'lere yayılır. Ortada trafiği tek elden yöneten bir merkez olmadığından, round-robin DNS "istemci tarafı, sırayla dağıtım" olarak düşünülmelidir. Sunucu tarafında yükü ölçen, kararı veren bir bileşen yoktur; sadece sıra kaydırma vardır.

Bu mekanizmanın kalbinde TTL (Time To Live) değeri yatar. TTL, bir cevabın ne kadar süre önbellekte tutulacağını belirtir. Round-robin'de TTL'i düşük tutmak (örneğin 300 saniye veya daha az) dağılımın taze kalmasını sağlar; çünkü yüksek TTL'de bir çözümleyici tek bir sıralamayı uzun süre önbelleğe alır ve arkasındaki binlerce kullanıcı hep aynı IP'ye gider. Yine de TTL'i çok düşürmek de ad sunucusuna gereksiz yük bindirir; makul bir denge şarttır.

Bir Alan Adına Birden Çok A Kaydı Tanımlamak#

Uygulamada round-robin kurmak tek satır iş: aynı isme birden fazla A kaydı eklemek. Örnek bir bölge (zone) dosyası şöyle görünür:

; example.com zone dosyası
www.example.com.   300   IN   A   192.0.2.10
www.example.com.   300   IN   A   192.0.2.11
www.example.com.   300   IN   A   192.0.2.12

Üç kayıt da aynı isme, aynı TTL'e (300 saniye) sahiptir; sadece IP adresleri farklıdır. Ad sunucusu bu üçlüyü her sorguda farklı sırada döndürür. Bir hosting kontrol paneli (cPanel, Plesk) veya Cloudflare gibi bir DNS sağlayıcı kullanıyorsanız, aynı www kaydı için üç ayrı satır eklemeniz yeterlidir; arayüz otomatik olarak round-robin davranışını üretir.

Kayıtların gerçekten döndüğünü dig ile doğrulayabilirsiniz. Sorguyu birkaç kez arka arkaya çalıştırın; sıranın değiştiğini görmelisiniz:

dig +short www.example.com A
# 192.0.2.11
# 192.0.2.12
# 192.0.2.10

dig +short www.example.com A
# 192.0.2.12
# 192.0.2.10
# 192.0.2.11

Bazı sağlayıcılar eşit ağırlık yerine ağırlıklı dağılıma (weighted round-robin) izin verir; orada bir IP'ye diğerlerinden daha fazla trafik yönlendirmek için o kaydı birden çok kez ya da ağırlık parametresiyle eklersiniz. Ancak saf DNS standardında ağırlık kavramı yoktur; ağırlıklandırma sağlayıcıya özgü bir eklentidir ve çoğu geleneksel BIND kurulumunda bulunmaz.

Yük Dağıtımı mı, Failover mı?#

Round-robin DNS ile ilgili en yaygın yanılgı, onu bir failover (yük devretme) çözümü sanmaktır. Bu ikisi tamamen farklı şeylerdir. Yük dağıtımı trafiği birden çok sağlıklı sunucuya yaymaktır; failover ise bir sunucu çöktüğünde trafiği otomatik olarak ayakta kalanlara yönlendirmektir. Round-robin sadece birincisini, hem de kabaca yapar; ikincisini hiç yapmaz.

Aradaki farkı görmek için üç yaklaşımı karşılaştıralım:

Tablodaki en kritik satır "çöken sunucuyu dışlama" satırıdır. Round-robin DNS bir IP'nin ayakta olup olmadığını bilmez. Üç sunucudan biri çökerse, ad sunucusu o çökmüş IP'yi sorguların yaklaşık üçte birinde vermeye devam eder. Sonuç: kullanıcılarınızın önemli bir kısmı bağlanamayan bir adrese düşer. Gerçek bir yük dengeleyici ise arka uçları sürekli yoklar, çöken makineyi havuzdan çıkarır ve hiçbir kullanıcı ölü sunucuya yönlenmez.

Sağlık Kontrolü Eksikliğinin Getirdiği Riskler#

Round-robin DNS'in "sağlık kontrolü yapmaması" cümlesi teknik bir ayrıntı gibi görünse de pratikte doğrudan gelir kaybına dönüşebilen bir sorundur. Bir e-ticaret sitesini üç sunucuya round-robin ile dağıttığınızı düşünün. Sunuculardan biri gece yarısı disk dolduğu için 500 hatası vermeye başladı. DNS bundan habersizdir; kullanıcıların üçte biri hâlâ o sunucuya yönleniyor ve ödeme adımında hata alıyor. Siz sabah panele bakana kadar saatlerce ciro kaybedersiniz.

Durum, TTL yüzünden daha da can sıkıcı hale gelir. Sunucuyu tamir edip IP'yi listeden çıkarsanız bile, dünyadaki çözümleyiciler ve tarayıcılar eski cevabı TTL süresi boyunca önbellekte tutar. TTL'i 3600 saniye (bir saat) ayarladıysanız, kaydı sildikten sonra bile bir saat boyunca bazı kullanıcılar ölü IP'ye gitmeye devam edebilir. Bu yüzden round-robin kullananlar genellikle çok düşük TTL'lerle çalışır, ama düşük TTL de tam koruma sağlamaz; sadece hasar penceresini kısaltır.

İkinci bir gizli sorun, dağılımın hiçbir zaman eşit olmamasıdır. Büyük internet servis sağlayıcıları, kurumsal DNS çözümleyicileri ve genel çözümleyiciler (8.8.8.8, 1.1.1.1) cevapları önbelleğe alır ve bazıları round-robin sırasını korumaz, hatta yeniden sıralar. Sonuçta bir sunucu diğerlerinin iki katı trafik alabilir. Yani round-robin size "eşit yük paylaşımı" sözü vermez; sadece "aşağı yukarı bir yayılma" sunar. Yüksek trafikli, hassas kapasite planlaması gereken sistemlerde bu belirsizlik kabul edilemez.

Bu risklerin bir kısmını yumuşatmak isteyen ekipler, önüne bir CDN veya akıllı DNS katmanı koymayı tercih eder. Cloudflare DNS ve CDN gibi çözümler, saf round-robin'in aksine kayıt bazında sağlık kontrolü ve otomatik failover sunabildiği için, DNS düzeyinde bir güvenlik ağı işlevi görür.

Round-Robin DNS'i Ne Zaman Kullanmalı, Ne Zaman Kaçınmalı#

Tüm bu uyarılara rağmen round-robin DNS ölü bir teknik değildir; doğru yerde hâlâ kullanışlıdır. Anahtar, sınırlarını bilerek konumlandırmaktır. Şu senaryolarda mantıklıdır:

• Durum tutmayan (stateless) statik içerik dağıtımı. Aynı içeriği barındıran birkaç özdeş sunucu varsa ve hangisine düşüldüğü fark etmiyorsa, round-robin ucuz bir yayılma sağlar.
• Coğrafi olarak ayrık bölgelere kaba yönlendirme. Farklı bölgelerdeki ad sunucularıyla birleştirilerek basit bir dağıtım kurulabilir.
• Bir katmanın önünde ikinci savunma hattı. Zaten yük dengeleyiciler kullanıyorsanız, birden fazla yük dengeleyicinin IP'sini round-robin ile yayarak yük dengeleyici katmanında da yatay ölçek elde edebilirsiniz.
• Bütçesiz, düşük kritiklikte iç projeler. Test ortamları, dâhili araçlar ve blog türü siteler için yeterlidir.

Şu durumlarda ise round-robin'den uzak durun ya da onu tek başına kullanmayın:

• Ödeme, bankacılık, sağlık gibi kesintiye tahammülü olmayan sistemler. Sağlık kontrolü olmadan ölü sunucuya trafik düşmesi kabul edilemez.
• Oturum bağımlılığı olan uygulamalar. Sepet, oturum, oyun durumu gibi bilgileri belirli bir sunucuda tutan uygulamalarda kullanıcı her istekte farklı sunucuya düşerse oturum bozulur.
• Hassas kapasite yönetimi gereken yüksek trafikli sistemler. Dağılım belirsizliği kapasite planlamasını imkânsız kılar.

Kısacası round-robin DNS'i "yük dengeleyici" olarak değil, "birden çok IP'yi ilan etmenin basit bir yolu" olarak görün. Gerçek yüksek erişilebilirlik istiyorsanız, altında sağlık kontrolü yapan bir katman şart.

Gerçek Failover ve Yük Dengeleme Alternatifleri#

Round-robin'in bıraktığı boşluğu dolduran birkaç olgun yaklaşım vardır. En yaygını, uygulama sunucularının önüne bir ters proxy / yük dengeleyici koymaktır. Örneğin Nginx ile arka uçları sağlık kontrolüyle yönetmek, çöken sunucuyu otomatik dışlamak mümkündür:

upstream uygulama_havuzu {
    server 192.0.2.10:443 max_fails=3 fail_timeout=15s;
    server 192.0.2.11:443 max_fails=3 fail_timeout=15s;
    server 192.0.2.12:443 backup;   # yedek: yalnızca diğerleri düşünce devreye girer
}

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_pass http://uygulama_havuzu;
        proxy_next_upstream error timeout http_502 http_503;
    }
}

Buradaki max_fails ve fail_timeout parametreleri Nginx'e "bir arka uç üst üste üç kez başarısız olursa 15 saniye boyunca ona istek gönderme" der. backup işaretli sunucu ise yalnızca birincil havuz tükendiğinde devreye girer. Bu, round-robin DNS'in asla yapamadığı gerçek failover davranışıdır. Benzer bir yapıyı HAProxy ile de kurabilir, hatta aktif HTTP sağlık kontrolleri (belirli bir URL'ye periyodik istek) ekleyebilirsiniz.

DNS düzeyinde failover isteyenler için ise modern yönetilen DNS sağlayıcıları "sağlık kontrollü DNS" sunar. Bu sistemler her IP'yi periyodik olarak yoklar ve sadece ayakta olanları cevaba dâhil eder. Kabaca şöyle bir mantıkla çalışır:

# yönetilen DNS'te sağlık kontrollü kayıt (kavramsal örnek)
record: www.example.com
type: A
policy: failover
ttl: 60
targets:
  - ip: 192.0.2.10
    healthcheck: { path: /saglik, interval: 30, timeout: 5 }
  - ip: 192.0.2.11
    healthcheck: { path: /saglik, interval: 30, timeout: 5 }

Bu yaklaşım round-robin'in basitliğini korurken en büyük eksiğini, yani sağlık kontrolünü kapatır. Sunucularınızın işletim ve izlenmesiyle uğraşmak istemiyorsanız, yönetimli bir altyapı da düşünebilirsiniz; sunucu yönetimi hizmetimiz tam da bu yük dengeleme ve izleme kurgusunu sizin adınıza tasarlar. Yatay ölçeklenmeyi kaldıracak güçlü bir donanım arıyorsanız VDS sunucularımız ve genel sunucu ailesi sayfamız iyi bir başlangıç.

Round-Robin DNS'i Test Etme ve Doğrulama#

Bir round-robin yapılandırmasının gerçekten çalışıp çalışmadığını gözle değil ölçerek doğrulamak gerekir. En temel araç yine dig. Aynı sorguyu bir döngüde çalıştırıp dönen ilk IP'nin dağılımına bakabilirsiniz:

# 30 sorgu at, dönen ilk IP'lerin dağılımını say
for i in $(seq 1 30); do
  dig +short www.example.com A | head -n1
done | sort | uniq -c

#  9 192.0.2.10
# 11 192.0.2.11
# 10 192.0.2.12

Çıktının kabaca eşit dağıldığını görüyorsanız round-robin devrede demektir. Dağılım tamamen tek bir IP'ye takılıysa, ya kayıtlar doğru eklenmemiş ya da araya giren bir önbellek cevabı sabitliyordur. Otoritatif ad sunucusuna doğrudan sorarak önbelleği devreden çıkarabilirsiniz:

# önbelleği atla, doğrudan otoritatif sunucuya sor
dig @ns1.saglayici.com www.example.com A +norecurse

Sağlık kontrolü eksikliğini de test etmek önemlidir. Bir sunucuyu bilerek kapatın (örneğin sudo systemctl stop nginx) ve ardından siteyi birkaç kez yenileyin; kullanıcıların bir kısmının hâlâ hata aldığını göreceksiniz. Bu, round-robin'in neden tek başına failover sağlamadığını en somut şekilde gösteren deneydir. Aynı testi yük dengeleyicili kurulumda tekrarladığınızda ise hiçbir kullanıcının etkilenmediğini görürsünüz.

Son olarak TTL değerinizi kontrol edin. Kaydınızın TTL'ini ve gerçekte önbellekte kalış süresini şöyle doğrulayabilirsiniz:

dig www.example.com A | grep -A3 "ANSWER SECTION"
# www.example.com.  287  IN  A  192.0.2.11
# www.example.com.  287  IN  A  192.0.2.12
# www.example.com.  287  IN  A  192.0.2.10

Baştaki 287 sayısı, o cevabın önbellekte kalan saniyesidir; her sorguda azalır ve sıfırlandığında taze bir sorgu yapılır. Bu değeri planlarken failover ihtiyacınızla ad sunucusu yükü arasında denge kurmanız gerekir.

Sıkça Sorulan Sorular#

Round-robin DNS gerçek bir yük dengeleyici midir?#

Hayır. Round-robin DNS yalnızca birden çok IP adresini sırayla ilan eder; trafiği ölçmez, sunucuların yükünü bilmez ve sağlık kontrolü yapmaz. Gerçek bir yük dengeleyici arka uçların durumunu sürekli izler, çöken sunucuyu havuzdan çıkarır ve isteği bağlantı bazında hassas biçimde dağıtır. Round-robin'i "birden çok IP ilan etmenin kaba bir yolu" olarak görmek, "yük dengeleme çözümü" olarak görmekten çok daha doğrudur.

Round-robin DNS sunucum çökünce otomatik yönlendirir mi?#

Kendiliğinden yönlendirmez. DNS, IP'lerin ayakta olup olmadığını bilmediği için çökmüş bir sunucunun IP'sini sorguların bir kısmında vermeye devam eder ve o kullanıcılar bağlantı hatası alır. Otomatik yönlendirme istiyorsanız ya sağlık kontrollü yönetilen DNS ya da önüne Nginx/HAProxy gibi bir yük dengeleyici koymanız gerekir. Saf round-robin sadece dağıtır, iyileştirmez.

Round-robin için ideal TTL değeri kaç olmalı?#

Genel bir kural olarak 60 ile 300 saniye arası makul bir aralıktır. Düşük TTL, bir IP'yi listeden çıkardığınızda değişikliğin hızla yayılmasını sağlar ve hasar penceresini kısaltır; ancak çok düşük değerler ad sunucusuna gereksiz sorgu yükü bindirir. Sağlık kontrolüne yaklaşan bir davranış istiyorsanız TTL'i düşük tutmak faydalıdır, ama unutmayın ki düşük TTL bile gerçek failover'ın yerini tutmaz, yalnızca gecikmeyi azaltır.

Trafik gerçekten eşit dağılır mı?#

Pratikte tam eşit dağılmaz. Ara çözümleyiciler ve büyük genel DNS servisleri cevapları önbelleğe alır, bazıları sırayı yeniden düzenler; bu yüzden bir sunucu diğerlerinin iki katı trafik alabilir. Round-robin size istatistiksel bir yayılma sunar, matematiksel eşitlik değil. Kapasite planlaması hassas olan sistemlerde bu belirsizlik başlı başına bir dezavantajdır ve daha kontrollü bir yük dengeleme katmanını gerekli kılar.

Round-robin DNS ile CDN aynı şey mi?#

Hayır, farklı katmanlarda çalışırlar. Round-robin sadece birden çok IP döndüren bir DNS tekniğidir; içerik önbellekleme, coğrafi yakınlık veya saldırı filtreleme yapmaz. CDN ise içeriği dünyanın çeşitli noktalarında önbelleğe alır, kullanıcıyı en yakın kenar sunucusuna yönlendirir ve genellikle sağlık kontrolü ile DDoS koruması sunar. İkisi birlikte de kullanılabilir; hatta bir CDN, arka uçlarına ulaşırken round-robin'den yararlanabilir.

Küçük bir WordPress sitesi için round-robin DNS gerekli mi?#

Çoğu küçük ve orta ölçekli site için gereksizdir ve fayda yerine karmaşıklık getirir. Tek bir sağlam sunucu, düzgün bir önbellek ve önünde bir CDN, round-robin'in vaat ettiğinden çok daha güvenilir bir sonuç verir. Round-robin asıl olarak birden çok özdeş sunucuyu zaten işleten, yatay ölçeklenmiş ekipler için anlamlıdır. WordPress performansı ve erişilebilirliği için önce sağlam bir hosting ve iyi bir önbellek stratejisine odaklanmak daha akıllıcadır.

Kapanış#

Round-robin DNS, yerinde kullanıldığında zarif derecede basit, yanlış kullanıldığında ise sessizce gelir kaybettiren bir tekniktir. Özünü aklınızda tutun: birden çok A kaydını sırayla döndürerek kaba bir trafik yayılımı sağlar, ama sağlık kontrolü yapmadığı için çöken sunucuya trafik göndermeye devam eder ve tek başına asla gerçek failover değildir. Doğru yaklaşım, onu bir yük dengeleyici katmanının ya da sağlık kontrollü yönetilen DNS'in yerine değil, tamamlayıcısı olarak konumlandırmaktır. DNS temellerini pekiştirmek için DNS nedir ve akıllı DNS için Cloudflare DNS ve CDN yazılarımız iyi bir devam noktasıdır.

Yüksek erişilebilirlikli bir mimariye geçmeyi düşünüyorsanız, işi tek başınıza kurmak zorunda değilsiniz. Clou.TR olarak güçlü sunucu altyapımızla (sunucu ailesi ve VDS), sağlık kontrollü yük dengeleme ve 7/24 izleme kurgusunu sizin için tasarlayan sunucu yönetimi hizmetimizle ve saldırılara karşı DDoS koruma çözümlerimizle yanınızdayız. İster küçük bir siteyi hosting paketlerimize taşıyın, ister kurumsal bir altyapıyı ölçekleyin; ekibimiz doğru mimariyi kurmanıza yardımcı olur.