Hata raporu her zaman aynı şeyin bir versiyonudur. Burada çalışıyor, orada çalışmıyor. Wifi'de çalışıyor, hücreselde çalışmıyor. Sizde çalışıyor, müşteride çalışmıyor. Dün çalışıyordu. Hiçbir şey değişmedi.
Bir site nerede durduğunuza bağlı olarak farklı davrandığında, bakılacak ilk yer DNS'tir — DNS kırılgan olduğu için değil, "DNS" tek bir şey olmadığı için. Dizüstü bilgisayarınız, telefonunuz, CI çalıştırıcınız ve başka bir ülkedeki müşteriniz hepsi farklı sunuculara, farklı yazılımla, farklı politikalarla, farklı önbelleklerle, ve bazı durumlarda aktif olarak farklı yanıtlarla soru soruyor.
İşte gerçekte kimin yanıt verdiğinin ve neden anlaşmadıklarının haritası.
DNS ayarlarınız muhtemelen kullanılmıyor
Herkesin yaptığı varsayımla başlayın: işletim sisteminizin ağ ayarlarında yapılandırılan çözümleyicinin sorgularınıza yanıt veren olduğu. Bu, yıllardır giderek daha az doğru hale geliyor.
Tarayıcılar artık kendi DNS'lerini yapıyor. Firefox, birkaç bölgede varsayılan olarak DNS-over-HTTPS'i etkinleştiriyor, aramaları Mozilla'nın seçtiği bir çözümleyiciye şifreli bir bağlantı üzerinden yönlendiriyor — işletim sisteminizin çözümleyicisini, yönlendiricinizi ve ISS'inizi tamamen atlayarak. Chrome, yapılandırılmış çözümleyicinizin desteklediğini algıladığında otomatik olarak şifreli DNS'e yükselterek benzer bir şey yapıyor.
Pratik sonuç, ilk kez karşılaştığınızda rahatsız edicidir: işletim sistemi DNS ayarlarınızı değiştirebilirsiniz ve tarayıcınız umursamaz. İşletim sistemi önbelleğini temizlersiniz ve tarayıcı hâlâ eski değeri çözer, çünkü işletim sistemi önbelleği hiçbir zaman yolda değildi. Özel bir ana bilgisayar adı için dahili bir çözümleyiciye işaret edersiniz ve tarayıcı onu bulamaz, çünkü internetin diğer tarafındaki herkese açık bir çözümleyiciye soruyor.
Bir ana bilgisayar adı terminalde çözülüp Chrome'da çözülmüyorsa — veya tersi — bu genellikle bu yüzdendir. Aynı sunucuyla konuşmuyorlar.
Uygulamalar da kendi önbelleklerini tutar. Uzun süre çalışan süreçler genellikle bir ana bilgisayar adını başlangıçta bir kez çözer ve tutar. Bazı dil çalışma zamanları tarihsel olarak varsayılan olarak DNS sonuçlarını sürecin ömrü boyunca önbelleğe almıştır. Üç haftadır çalışan bir hizmet, değiştirdiğiniz hiçbir şeyden etkilenmeden üç hafta önceki bir IP adresini kullanıyor olabilir.
Bölünmüş ufuk: aynı ad, iki doğru yanıt
Birçok kuruluş bölünmüş ufuk (split-horizon) DNS çalıştırır: aynı alan adı, kimin sorduğuna bağlı olarak farklı adreslere çözülür. Ofis içinde, app.company.com özel bir adrese işaret eder. Dışarıda, genel olana işaret eder.
Bu kasıtlıdır ve kullanışlıdır, ve tam olarak başlıktaki belirtiyi üretir. VPN'de çalışır, VPN dışında çalışmaz. Wifi iyidir, hücresel bozuktur. Hiçbir şey yanlış yapılandırılmamıştır — iki farklı, her ikisi de doğru görünümden iki farklı yanıt alıyorsunuz, ve hangisini aldığınız hangi çözümleyiciye ulaştığınıza bağlıdır.
Bir cihaz kısmen dahili ağdayken bu gerçekten kafa karıştırıcı hale gelir: bölünmüş tünelli VPN'ler, veya işletim sistemi kurumsal olana işaret ederken herkese açık bir çözümleyiciye DoH yapan bir tarayıcı. Şimdi tek bir cihaz, kimsenin tam olarak yeniden yapılandıramayacağı bir kural setinde, bazı aramalar için dahili yanıtlar ve diğerleri için harici yanıtlar alıyor.
Çözümleyiciler yanıtlarınıza ne yapar
Her çözümleyici tarafsız bir boru değildir. Birkaçı aldığınız şeyi değiştirir:
NXDOMAIN ele geçirme. Bazı ISS çözümleyicileri "alan adı yok"u yakalar ve bunun yerine bir arama veya reklam sayfası için bir IP adresi döndürür. İstemci açısından, yazım hatalı bir alan adı artık çözülüyor, ki bu NXDOMAIN'in söylediği anlama geldiğine güvenen herhangi bir yazılımı bozar — ve posta sunucularındaki ve uygulamalardaki geri dönüş mantığını sessizce bozar.
TTL sınırlama. Bir çözümleyici, siz ne ayarlarsanız ayarlayın, ne kadar süre önbelleğe alacağı konusunda kendi tabanını veya tavanını uygulayabilir. Dikkatlice seçilmiş 300 saniyelik TTL'iniz otuz dakika olur çünkü politika budur. Bu, geçişlerin bazen bir kullanıcı alt kümesi için çarpıcı biçimde daha uzun sürmesinin nedenidir.
Filtreleme ve kara listeler. Quad9, birçok kurumsal çözümleyici ve giderek artan sayıda ISS çözümleyicisi, tehdit akışlarında görünen alan adlarını çözmeyi reddediyor. Alan adınız bir listeye düşerse — bir ihlal, kötü bir komşuyla paylaşılan bir IP, veya yanlış pozitif yoluyla — o kullanıcılar için basitçe çözülmeyecektir, her yerde başka mükemmel çalışırken. Bilgilendirilmezsiniz. Alan adınızın veya IP'nizin bir kara listede olup olmadığını kontrol etmek, başarısızlık deseni belirli kayıtlarla değil belirli ağlarla ilişkilendiğinde yapmaya değer.
DNSSEC doğrulaması, veya yokluğu. Doğrulayan bir çözümleyici, kriptografik olarak doğrulayamadığı bir yanıtı vermeyi reddeder. Doğrulamayan biri, kontrol etmeden verir. Yani süresi dolmuş bir imzaya sahip bir bölge bazı ağlardan çalışır ve diğerlerinden SERVFAIL döndürür — ve fark, coğrafya değil çözümleyici yazılımıyla ilişkilidir. Başarısızlıklar tuhaf bir şekilde kümeleniyorsa, DNSSEC zincirini kontrol etmek bunu diğer her şeyden hızlıca ayırır, çünkü süresi dolmuş imzalar tam olarak bu bölünmeyi üretir.
"Bazı ülkelerde yavaş"ı açıklayan olan
Bu incelikli ve az takdir edilen bir şeydir: genellikle ECS olarak kısaltılan EDNS Client Subnet.
Bir CDN veya herhangi bir GeoDNS kurulumu kullanıyorsanız, yetkili sunucu nerede olduğunuzu düşündüğüne göre bir yanıt seçer. Ama sizi görmez — çözümleyicinizi görür. İstanbul'daysanız ve en yakın örneği Frankfurt'ta olan bir çözümleyici kullanıyorsanız, yetkili sunucu Frankfurt'u görür ve bir Avrupa edge düğümü döndürür.
ECS bunu düzeltmek için tasarlandı: çözümleyici, sorguya istemcinin IP'sinin kesilmiş bir kısmını dahil eder, böylece yetkili sunucu çözümleyiciyi değil gerçek kullanıcıyı coğrafi olarak konumlandırabilir.
Sorun, desteğin kasıtlı olarak değişmesidir. Google'ın herkese açık çözümleyicisi ECS gönderir. Cloudflare'ın 1.1.1.1'i büyük ölçüde göndermez, kasıtlı bir gizlilik kararı olarak — her yetkili sunucuya istemci alt ağlarını ifşa etmek istemiyorlar.
Sonuç: aynı kullanıcı, aynı bağlantıda, hangi herkese açık çözümleyiciyi kullandığına bağlı olarak farklı CDN düğümlerine yönlendiriliyor. ECS ile yakındaki düğümü alırlar. Onsuz, başka bir kıtada bir tane alabilirler. Site çalışıyor — sadece bazı insanlar için açıklanamayan bir şekilde daha yavaş, ve DNS kayıtlarınızda hiçbir sorun yok.
Bölgesel performans şikayetlerini kovalıyorsanız ve DNS'iniz "iyi görünüyorsa", bu güçlü bir adaydır. Özellikle aramadığınız sürece tamamen görünmezdir de.
Mobilin kendi tuhaflık katmanı var
Hücresel ağlar, kablolu bağlantılarda bulunmayan komplikasyonlar ekler:
- Operatör çözümleyicileri agresif bir şekilde önbelleğe alır ve değişiklikleri yansıtmada genellikle daha yavaştır.
- Operatör düzeyi NAT, görünen kaynak adresinizin büyük bir abone havuzuyla paylaşıldığı anlamına gelir, ki bu ECS tabanlı coğrafi konumlandırma ve IP tabanlı hız sınırlamayla kötü etkileşir.
- Private Relay ve VPN benzeri özellikler modern telefonlarda DNS'i sağlayıcının altyapısı üzerinden yönlendirir, bu yüzden kullanıcınızın DNS'i fiziksel olarak bulunduğu yerle tamamen alakasız bir yerde oluyor.
- Dolaşım sıklıkla DNS sorgularının, cihaz başka bir yerdeyken, ev operatörünün çözümleyicisi tarafından, ev ülkesinde yanıtlandığı anlamına gelir.
Sonuncusu, bir ülkedeki kullanıcının başka bir ülke için CDN yanıtları almasının hoş durumunu üretir, çünkü operatörü DNS'i evden yanıtlıyor.
Bunu gerçekte nasıl teşhis edersiniz
Temel hamle, "DNS bozuk mu" diye sormayı bırakıp "hangi çözümleyici, ve ne dedi" diye sormaya başlamaktır.
-
Başarısız cihazın gerçekte ne kullandığını bulun. Ayarlarda ne olduğunu değil — yolda ne olduğunu. Tarayıcıda DoH'un etkin olup olmadığını kontrol edin; bir telefonda, bir gizlilik rölesi veya VPN özelliğinin aktif olup olmadığını kontrol edin.
-
Çözümleyiciler arasında yanıtları karşılaştırın. Farklı çözümleyiciler farklı kayıtlar döndürüyorsa, aynı adı farklı ağlardaki birden çok çözümleyicide kontrol edin. Ayırt edilecek iki desen: eski ve yeni değerler arasında bir bölünme önbellekleme anlamına gelir (TTL'i bekleyin). Her biri kendi içinde tutarlı olan farklı değerler arasındaki bir bölünme, bölünmüş ufuk, GeoDNS veya filtreleme anlamına gelir — ve bunlar beklemekle çözülmez.
-
Doğrudan yetkili sunucuya sorun. Doğruluk kaynağını sorgulayın ve karşılaştırın. Yetkili yanıt doğruysa ve bir çözümleyici aynı fikirde değilse, sorun çözümleyici yolundadır — önbellek, filtre veya doğrulama — bölgenizde değil.
-
Gerçekte hangi IP'yi aldığınızı kontrol edin. Farklı ağlar farklı adreslere düşüyorsa, bir IP sorgulama size her birinin hangi sağlayıcıya ve bölgeye ait olduğunu söyleyecektir. Bu, "GeoDNS tasarlandığı gibi çalışıyor"u "bu kullanıcı saçma bir yere gönderiliyor"dan hemen ayırır.
-
Kayıtlara dokunmadan önce DNSSEC'i ve kara listeleri eleyin, çünkü her ikisi de bazı ağlarda temiz başarısızlıklar ve diğerlerinde hiç üretmez.
Yeniden çerçeveleme
"Bu alan adı neye çözülüyor" diye bir şey yoktur. Sadece "bu belirli çözümleyici, bu anda, bu önbellek durumuyla, bu doğrulama politikasıyla, bu filtreleme listesiyle, ve konumunuzun bu görüşüyle, bu istemciye ne döndürdü" vardır.
Çoğu zaman tüm bu yanıtlar aynı fikirdedir, bu yüzden basitleştirme genellikle işe yarar. Aynı fikirde olmayı bıraktıklarında, soru DNS'in bozuk olup olmadığı değildir — soru gerçekte kimin DNS'ine baktığınızdır, ve bu, sormanız gerektiğini bildiğinizde yaklaşık beş dakikada cevaplayabileceğiniz bir sorudur.