Round Robin DNS’yi Anlamak

 (blog.hyperknot.com)
3 puan yazan GN⁺ 2024-10-27 | 1 yorum | WhatsApp'ta paylaş
  • OpenFreeMap’in işletmecisi, farklı bölgelerdeki VPS’leri aynı alt alan adının A kayıtlarına bağlayarak round robin DNS kurdu ve tarayıcılar ile Cloudflare’ın gerçekte hangi sunucuyu seçtiğini test etti
  • Ayrı bir load balancer olmadan yük dağıtımı ve hata toleransı beklenebilir, ancak gerçek sonuçlar büyük ölçüde istemcinin adres sıralama ve yeniden deneme biçimine bağlıdır
  • ABD, Avrupa ve Singapur’da bulunan 3 VPS ile yapılan testte Chrome ve Firefox başlangıçta rastgele bir sunucuya sabitlenme eğilimi gösterirken, Safari ve curl tekrar eden isteklerden sonra yakındaki AB sunucusuna yakınsadı
  • Bazı sunucular çevrimdışı olduğunda tarayıcılar ve curl hızla yedek sunucuya geçti, ancak Cloudflare proxy üzerinden gelen istekler istemci IP’sine göre seçilen origin’i kullanmayı sürdürdüğü için 521 hatası oluşabildi
  • Cloudflare çevrimdışı origin’i veya daha düşük gecikmeli sunucuyu doğru seçmezse, round robin DNS tabanlı dağıtım kullanıcı konumundan bağımsız olarak yavaş bir sunucuya bağlayabilir

Round robin DNS’in temel fikri

  • Tipik bir VPS tabanlı web sitesinde DNS sağlayıcısına tek bir A kaydı eklenir ve trafik belirli bir IP’ye yönlendirilir
  • Round robin DNS, aynı alt alan adına birden fazla sunucu IP’si tanımlama yöntemidir
    • Örnekte rr-direct.hyperknot.com ve rr-cf.hyperknot.com için birden fazla A kaydı yapılandırılmıştır
  • Bu yapılandırmada yükün birden fazla sunucuya dağıtılması ve çevrimdışı sunuculardan kaçınılması beklenebilir
  • Çoğu DNS sağlayıcısında ayrı bir load balancer olmadan kurulabildiği için basit ve neredeyse ücretsiz bir yaklaşımdır
  • Cloudflare gibi hizmetlerin load balancing özellikleri maliyetli olabilir

İstemci sunucuyu hangi ölçüte göre seçebilir?

  • İlgili standartlar arasında RFC 8305 Happy Eyeballs ve RFC 6724 yer alır
  • RFC 8305’in adres sıralama bölümü, durum bilgisi tutan istemcilerin her adres yoluna ait tahmini gidiş-dönüş süresi (RTT) kaydı varsa, daha düşük RTT’li adresleri tercih eden hedef adres seçimi kuralları eklemesi gerektiğini açıklar
  • Deneyi yapan kişi bunu şu davranış olarak yorumlar
    • Sunucunun çevrimiçi mi çevrimdışı mı olduğunu kontrol etmek
    • Çevrimiçi sunucuları ping süresine göre sıralamak

Deney düzeni

  • Dünyanın 3 bölgesinde VPS kuruldu
    • ABD
    • Avrupa
    • Singapur
  • Cloudflare’da 3 proxy’li A kaydı ve 3 proxy’siz A kaydı tanımlandı
  • Her sunucu nginx ile aynı yanıt yapısını sunar
    • Tüm yol istekleri color.png dosyasına yeniden yazılır
    • /server, /etc/hostname çıktısını text/plain olarak döndürür
  • color.png, 1 piksellik bir PNG dosyasıdır ve sunucuya göre rengi değişir
    • US: yeşil
    • EU: mavi
    • SG: kırmızı
  • Ana makine adları test-eu, test-us, test-sg olarak ayrılmıştır
  • Test konumu Avrupa olduğu için beklenen davranış en yakın AB sunucusunun seçilmesidir
  • HTML test sayfası, sunucu seçimi sonuçlarını görselleştirmek için 10x10’luk bir ızgarayı rastgele görsellerle doldurur

Tüm sunucular çevrimiçiyken istemciye göre davranış

  • Chrome, birden fazla konum arasından biraz rastgele birini seçme ve seçtikten sonra o sunucuda kalma eğilimi gösterir
    • Birkaç saat sonra seçimi yeniden değerlendirebilir
    • Testte en yavaş Singapur sunucusuna saatlerce sabit kaldığı da görüldü
    • HTTP/2 kullanılmadığında iki sunucu arasında rastgele seçim yaparak desen oluşturabildi
  • Firefox da Chrome’a benzer davrandı
    • Başlangıçta rastgele bir konum seçer
    • Tarayıcı yeniden başlatılırsa başka bir rastgele konum seçebilir
  • Safari, en yakın sunucuyu her zaman doğru seçti
    • Sunucu kısa süreliğine çevrimdışı kalıp geri gelse bile birkaç yenilemeden sonra tekrar AB sunucusunu buldu
  • curl da yakındaki sunucuya uyum sağladı
    • İlk çalıştırmada böyle olmayabilir, ancak komut iki kez çalıştırıldığında her zaman en yakın sunucuya geçti
    • Örnekte ilk istek test-us, sonraki istek test-eu oldu

Cloudflare proxy üzerinden davranış

  • Cloudflare, istemci IP’sine göre rastgele bir konum seçer ve aynı konumu kullanmayı sürdürür
  • Gözlemlenen davranış client_ip_hash modulo server_num ile benzerdir
  • Ev IP’sinden hangi işlem yapılırsa yapılsın Cloudflare ABD sunucusuna bağlandı
  • Mobil hotspot ile her zaman AB sunucusuna bağlandı
  • Birden fazla VPS’te aynı curl komutu çalıştırıldığında, her VPS dünyadaki rastgele bir konuma bağlansa da hep aynı sunucuyu kullandı
    • Örnek sonuç test-sg idi

Bazı sunucular çevrimdışıyken farklar

  • ABD sunucusunda service nginx stop ile nginx durdurulduktan sonra davranış gözlemlendi
  • Chrome, Firefox, Safari ve curl çevrimdışı sunucuyu algılayıp başka bir sunucu seçti
  • Yükleme sırasında sunucu kapatılsa bile yedek bağlantı 1 saniyeden kısa sürede devreye girecek kadar hızlı çalıştı
  • Cloudflare çevrimdışı sunucuyu algılayamadı
    • İstemci IP’si için bir kez seçilen sunucuya, çevrimiçi olup olmadığına bakmadan erişmeyi sürdürdü
    • O sunucu çevrimdışıysa kullanıcı hata aldı
    • curl çıktısı error code: 521 oldu

Cloudflare hakkında soru işaretleri ve sınırlamalar

  • Cloudflare’ın çevrimdışı origin’i algılayamaması, ağdaki bir bug olabilir
  • Cloudflare belgelerindeki zero downtime failover ifadesine dayanarak, tarayıcılar ve curl gibi davranması gerektiği düşünülüyor
  • En azından çevrimdışı sunucuların algılanması gerekir
  • Safari gibi en düşük gecikmeli sunucunun seçilebilmesi daha da iyi olur
  • Mevcut davranışta 1 ABD sunucusu ve 1 Yeni Zelanda sunucusu olduğunda, ABD’deki kullanıcıların %50’si Yeni Zelanda sunucusundan yanıt alabilir
  • Safari kullanıcıları, Cloudflare kullanırken Cloudflare kullanmamaya kıyasla daha yavaş deneyim yaşayabilir
  • İlgili HN tartışmasında Cloudflare CEO’su ve CTO’su yanıt verdi
  • Deneyi sürdürmek için dünya çapında 3 VPS maliyeti olmadan HTTPS ve round robin DNS destekleyen sunucusuz bir platform olup olmadığı da soruluyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-27
Hacker News yorumları

  • Hmm, yetkili DNS ekibinden burada neler olduğunu açıklamalarını istedim.
    Kesin bir yanıt alırsam HN'de bildireceğim. Koda bakmayalı birkaç yıl oldu ve bu süre içinde pek çok kişi onu değiştirmeye devam etti :-)
    Tahminim, yazarın blogda bahsettiği gibi istemci IP'si ile arka uç sunucu tercihini korumaya yönelik davranışla ilgili olduğu yönünde. Asıl soru şu: “Arka uç sunucu çökerse bu tercihi bozmak gerekir mi?” Daha fazlasını öğrenirsem kendi yorumuma yanıt olarak yazacağım.

    • Oturum tercihi adı altında gerçekten çok günah işlendi.
    • Güncelleme: Ücretsiz hesaplarda da kesintisiz failover çalışacak şekilde değişiklik dağıtıma alınıyor.

  • Bu soruna yönelik ilk çözümlerden biri SRV DNS kaydıydı. MX kaydına benzerdi ama yalnızca e-posta için değil, tüm servisler için uygulanması amaçlanmıştı.
    MX ve SRV kayıtlarında istemcinin deneyeceği sunucu listesini ve öncelikleri belirleyebilirsiniz; SRV'de yük dengeleme için bir weight parametresi de vardı. Ancak SRV, fiilen tüm standart protokollere müdahale edip tüm istemcileri SRV kontrol etmeye zorlayacak siyasi mücadeleden kaçınmak için, yalnızca ilgili protokol standardı SRV kullanımını açıkça belirttiğinde kullanılacak şekilde tanımlandı. Bu yüzden teknik olarak HTTP istemcileri SRV kullanamaz hale geldi. Daha sonra HTTP/2 ve sonrasındaki HTTP standartları hazırlanırken de Google vb. kaynaklardan gelen uygunsuz gerekçeler nedeniyle yeni HTTP protokolünde SRV açıkça belirtilemedi. SRV yeni geliştirmelerde fiilen öldü; görünüşe göre yalnızca bazı eski standartlarda kullanılıyor.
    Yeni yük dengeleme çözümü HTTPS ve SVCB DNS kayıtları gibi görünüyor. Anladığım kadarıyla, TLS 1.3 el sıkışmasını daha hızlı başlatıp gidiş-geliş sayısını azaltmak için DNS'e ek parametreler koymak isteyen kişiler tarafından standartlaştırıldı. SVCB kayıt türü HTTPS ile aynı, ama SRV gibi genelleştirilmiş bir biçim. HTTPS ve SVCB'de SRV ve MX'teki öncelik parametresi var, ancak SRV'deki weight parametresi yok. Standart yayımlandı ve bazı tarayıcılarda destek eklenmiş gibi görünüyor, fakat herkes etkinleştirmiş değil. Yakın gelecekte tarayıcıların gerçekten ne yapacağını görmek gerekecek.

    • HTTPS kaydının bir diğer büyük avantajı, domain apex'te düzgün bir CNAME benzeri devir sağlaması.
      GeoDNS'i anycast ile birlikte veya onun yerine kullanan CDN'lerde yönlendirme sorunlarına yol açabilecek CNAME flattening hilesini gerektirmez. Bazı platformların apex domain yerine www alt alan adını kullanmanızı önerdiğini gördüyseniz nedeni budur; Akamai'nin GeoDNS kullanması da HTTPS kaydı standardizasyonunu itmesinin sebeplerinden biriydi.
    • HTTP için kullanılabilecek SRV veya MX tarzı kayıtların düzgün biçimde benimsenmesini gerçekten isterim.
      İnsanların sık sık domain apex üzerinde web sitesi barındırmak istemesi nedeniyle, böyle kayıtların olmaması özellikle can sıkıcı. Yine de DNSSEC'e güvenemiyorsanız MX tarzı kayıtları güvenli kullanmak zor olabilir.

  • DNS yük dengelemesinde gerçekten kirli uç durumlar var. Go HTTP/2 istemcisinin round-robin DNS kullandığı bir durumu ele aldım ve sorun çıktı.
    Go HTTP/2 istemcisi, bağlanabildiği ilk sunucuyu sürekli yeniden kullanıyor ve DNS'i yeniden çözümlemiyor. Bu yüzden havuza yeni bir sunucu ekleseniz bile istemci yeni sunucuyu keşfedemeyebilir.
    Özellikle patolojik durum şu: Tüm arka uçlar çöktükten sonra ilk arka uçlardan biri yeniden ayağa kalkarsa, istemcilerin tamamı o sunucuya sabitlenip oradan ayrılmayabiliyor. Diğer sunucular ayağa kalksa bile zaten ilk sunucuya bağlı olduklarından, yeni bağlantı kuran istemci çok az oluyor.
    grpc-go tarafında da benzer bir sorun oluşuyor. gRPC DNS çözümleyicisi yalnızca arka uç bağlantısı koptuğunda yeniden çözümleme yapıyor. Bu yüzden gRPC istemcileri bir host'a yığılıp orada kalabiliyor. Sunucu tarafında MAX_CONNECTION_AGE ayarlayıp belirli bir süre sonra istemcileri düzenli olarak koparmak ve istemcinin DNS'i yeniden çözümlemesini sağlamak öneriliyor.
    Servis keşfi için daha iyi bir standart çözüm olmasını isterdim. Sonuçta yapılabilecek en iyi şey sanal IP tabanlı, istek başına yük dengeleyici uygulamak ve yük dengeleyicinin sağlık kontrollerini yapmasını sağlamak gibi görünüyor. Ama bu da sorunu yalnızca sanal IP'yi uygulayan sisteme itiyor. Yönlendirme sisteminin arka uçlara kıyasla daha statik olduğu varsayılıyor ve kazancın buradan geldiği düşünülüyor gibi.
    Bare metal'de bunun nasıl yapıldığını merak ediyorum. AWS/GCP vb. ortamlarda dahili yük dengeleyiciler olduğunu biliyorum ama bunu uygulamanın püf noktasının ne olduğunu merak ediyorum. Konuyla ilgili blog yazısı veya teknik rapor önerileri de iyi olur.

    • DNS uzmanı değilim ama TTL süresi dolduğunda yeniden çözümleme yapılması gerekmez mi?

  • “Bir sunucu çevrimdışıysa ne olur? ABD sunucusunu durdurduğumuzu varsayalım: service nginx stop” denmiş, ama böyle test edilmemeli.
    İstemci bağlantı reddini görür ve sonraki IP'ye geçer. Ancak gerçekte sunucu hiç yanıt vermeyebilir ya da bağlantıyı kabul edip sessiz kalabilir.
    O zaman istemci zaman aşımına bağımlı hale gelirsiniz ve güvenilirliği artırması beklenen round-robin DNS bir anda çok daha az cazip görünür.

    • Doğru. İlgili IP'ye sahip fiziksel makinenin veya VM'in gücünü keserek ya da kablosunu çekerek test edebilirsiniz.
      Servisi durdurmak planlı bir işlemdir; bu durumda önce DNS'i güncelleyerek bunu yönetebilirsiniz.
    • SIG_STOP veya ip/nftables ile DROP çok daha gerçekçi bir testtir.

  • “Gördüğünüz gibi tüm istemciler bunu doğru şekilde algılayıp alternatif sunucuyu seçiyor” ifadesi, meselenin dağınık özünü oluşturuyor. Güvenilirlik istemci tarafında belirleniyor
    Örneğin systemd-resolved bir dönem, teknik olarak mümkün olduğunca doğru davrandığını söyleyerek her zaman en düşük IP adresini döndürüyordu. Mantık şuydu: DNS round robin iyi tanımlanmış değildir; dolayısıyla her zaman en düşük IP’yi döndürmek de yanlış sayılmaz. Kopan gürültüden sonra bu değiştirildi, ama bildiğim kadarıyla Debian 11 bu davranışa bağlıydı ya da uzun süre öyle kaldı
    Ayrıca yeniden deneme davranışı çok kötü olan ya da hiç olmayan pek çok uygulamayla da uğraştım. “Bir bağlantı reddi aldık, her şeyi iptal edip çıkalım ve bir daha denemeyelim” gibi davranıyorlar. Bu durumda toplam isteklerin %20-30’u yanıp gidiyor
    Başka seçeneğiniz yoksa kabul edilebilir bir çözüm. Yazıda söylendiği gibi, tarayıcılar gibi birkaç yeniden denemesi ayarlanmış kaliteli bir HTTP istemciniz varsa DNS round robin, durum denetimleri vb. olan gerçek bir yük dengeleyiciyi bulmak için gayet iyi olabilir ve %100 başarı oranı sağlayabilir
    Ama DNS round robin bir yük dengeleyici değildir ve yük dengeleyici daha iyidir

    • Buna karşılık, istemcileri kontrol edebiliyor ve davranışlarını garanti edebiliyorsanız DNS yük dengeleme çok etkilidir
      Eskiden çalıştığım yerde yüz milyonlarca kaydı ve 60 saniyelik TTL’si olan dahili bir DNS sunucusu vardı; müşterilerin gelen bağlantılarını ağ içindeki doğru kaynaklara yönlendiren özel bir dahili yönlendirme sisteminde kullanılıyordu. Gerçekten harikaydı. Yönlendirme değişiklikleri DDNS güncellemesi kadar basitti ve NOTIFY ile değişiklik tüm alt sunuculara itilerek tam yayılımda ortalama gecikme 60 saniyenin altındaydı. Bu sayede daha karmaşık araçlar yapmak kolaylaştı; tek bir sunucudan tüm veri merkezine kadar her şeyi tek düğmeyle hizmet dışına alabilen bir kontrol paneli de yapabildik
      O sistemin de elbette pürüzlü tarafları vardı, ama o tür bir sisteme göre hızlıydı, içini görmek kolaydı ve nispeten kurşun geçirmezdi
    • Güvenilirliği istemcinin ya da onun arkasındaki rastgele bir önbellekleyen DNS çözümleyicisinin ellerine bırakmış oluyorsunuz
      Yük devretme de aynı. Bir bölge çökerse trafiğin diğer bölgelere eşit dağılmasını mı istersiniz, yoksa bir sonraki en yakın komşu bölgeye yığılmasını mı? Bu davranış önemliyse trafik yönetiminin kontrolünü elinizde tutmalısınız; başkasına devretmemelisiniz
    • “Başka seçeneğiniz yoksa kabul edilebilir bir çözüm” ifadesine de katılmakta zorlanıyorum
      Günümüzde o “başka seçenek yok” noktasına gelmeden çok önce seçmeniz gereken başka çözümler var

  • “Yükü birden fazla sunucuya dağıtabilir ve hangi sunucunun çevrimdışı olduğunu otomatik olarak algılayıp çevrimiçi sunucuyu seçebilir” ifadesindeki DNS’in otomatik çevrimdışı algılaması konusunda dikkatli bir şekilde itiraz edecek olursam, varsayılan haliyle round robin DNS yalnızca yük dengeleme için işe yarar
    İstemciye akıllı bir mantık koymadığınız sürece kullanılabilirlik durumunu algılama açısından otomatik olarak gerçekleşen bir şey yoktur. Yazının giriş kısmı bunu bir ölçüde söylüyor, ama ne demek istediğini anlamak için birkaç kez okumam gerekti. Adil olmak gerekirse bu benim anlama sorunum da olabilir. Sonrasında yazının geri kalanını okuyunca hepsinin o akıllı mantıkla ilgili olduğunu gördüm
    Tarayıcının seçtiği 1/N sunucu kaydı kullanılamıyorsa, protokol düzeyinde otomatik kurtarma ya da yeniden deneme gerçekleşmez
    Ayrıca “ilgili eğlencelik”: Java’nın DNS TTL [1] ve .equals() [2] davranışını da unutmayın
    [1] https://stackoverflow.com/questions/1256556/how-to-make-java...
    [2] https://news.ycombinator.com/item?id=21765788 (5 yıl önce, 168 yorum)

    • Route53’te sunucu sağlıklı durumda değilse DNS yanıtından kaldırılarak ve tüm yanıtlar çok düşük TTL ile verilerek bu ele alınıyor
      TTL’yi yok sayan istemciler de var, ama oldukça nadir
    • Biraz tanıtım yapacak olursam, round robin DNS’e yük devretme sağlayan özgür ve açık kaynaklı bir proje; NLnet tarafından destekleniyor: https://codeberg.org/FedericoCeratto/rrdnsd

  • Bir sunucu kapanırsa, dünyaya dağılmış ve önbelleğe alınmış IP adresleri kalır; insanların o adrese erişmesini engelleyemezsiniz
    https://www.cloudflare.com/learning/dns/glossary/round-robin...

    • Gereksiz ara katmanları atlamayı düşünmeye değer
      Yük dengelemenin de bir maliyeti var; yük dengeleyicilerin bağlantıları ince ya da apaçık biçimde bozması gibi sorunlar da var. Bazı sağlayıcılarda yük dengeleyicinin erişilebilirliğinin bizim hostlarımızdan daha kötü olduğu bile olmuştu
      İstemciyi kontrol ediyorsanız, platform DNS API'sini çağırıp IP listesini alarak uygun şekilde karıştırıp sırayla dolaşmak da makul bir yöntem. DNS'in bozulmasına karşı, istemci ikilisine güvenilir biçimde atanmış birkaç IP koyabiliyorsanız daha da iyi. Ama DNS genelde bozuk olmaz ve küme her güncellendiğinde yeni yapılandırma ya da ikili dağıtmadan operasyonel değişiklikler için kullanışlıdır
      İstemci bir tarayıcıysa varsayılan davranış fena sayılmaz. Genelde IP'leri sırayla kullandığı için sorun olabilir [1], ama bunun dışında yeniden deneme davranışı iyidir. Bağlantı reddedilirse hemen başka bir IP dener; zaman aşımı olursa en azından birkaç farklı IP'yi dener. İdeal değil; bu yüzden tarayıcılar için bir yük dengeleyici kullanırdım ve mümkünse en azından ilk sayfa yüklemesinde bunu yapardım. WebSocket vb. için DNS round robin ve bir miktar akıllı JS istemci mantığı kullanılabilir. Yine de tüm site için DNS round robin kullanmak da mümkündür
      İstemci ne tarayıcıysa ne de sizin kontrolünüzdeyse, şans dilemekten başka çare yok
      Bazen birilerinin DNS önbellekleyici çözümleyici yazarken TTL alanını saniye değil gün sayısı olarak yorumlayacağını varsaymak gerektiğini %100 kabul ediyorum. Böyle çözümleyicilerin arkasındaki istemciler DNS'i güncellerken sorun yaşar. Ama yük dengeleyici bir DNS adının arkasındaysa ve bir gün o adresi değiştirmeniz gerekirse, o sorunu o zaman yaşarsınız; üstelik o konuda deneyiminiz de olmaz
      [1] RFC'lerden biri, OS API'sinin yanıtları önek eşleşmesine göre sıralamasını önerir. IP önekleri hiyerarşikse ve ağ mesafesi olarak en yakın sunucuyu seçmek için bir vekil göstergeyse bu mantıklı olabilir. Ama gerçekte sayısal olarak bitişik /24'ler çoğu zaman ağ üzerinde bitişik değildir. Sunucu adresleri geniş biçimde dağılmışsa, bazı istemci IP'lerinden gelen trafiğin sayısal olarak benzer sunucu IP'lerine yığıldığını görebilirsiniz
    • Yazıda test edilen istemciler doğru davrandı ve erişilebilir sunuculardan birini seçti
      Elbette birileri yerel DNS'i yanlış yapılandırmak ya da kötü bir istemci kullanmak zorunda kalacaktır. Bozuk yapılandırmaya sahip kişiler için kesintiyi göze almanız ya da IP'yi aynı veri merkezindeki başka bir sunucuya yeniden atamanız gerekir
    • Günümüzde standart yaklaşım, görece düşük bir TTL kullanmak ve DNS sunucusunun havuz üyeleri için sağlık kontrolü yapmasıdır

  • Merhaba. Ben Cloudflare CTO'suyum. Cloudflare'ın tüm ücretsiz hesaplarına, ücretli hesaplarla aynı davranışı gösterecek bir değişiklik dağıttık
    Burada bahsedilen sorun düzeltildi; Zero Downtime Failover tüm hesap türlerinde çalışmalı. Tekrar test edebilir misiniz?
    Bunu yazıya döktüğünüz için teşekkürler. Bu davranışı herkes için değiştirebildiğimize sevindim

    • Tekrar test ettim ve çok iyi çalışıyor
      Yazıyı da buna göre güncelleyeceğim. Ücretsiz hesaplara da uyguladığınız için teşekkürler; harika bir sonuç

  • Bunun karanlık remiks sürümü fast flux hosting ve birçok bulletproof hosting sağlayıcısının kullandığı yöntem
    https://unit42.paloaltonetworks.com/fast-flux-101/

  • Kesintisiz failover'ın Pro ve üzeri bir özellik olduğunu belirtmeye değer olabilir
    Eskiden origin sunucu koruma belgeleri plan seviyelerine göre ayrılmışken de böyle belgelendiğini hatırlıyorum. Bu yüzden davranış ya da yeniden denemeler farklı görünebilir