Yapılandırılmış ad sunucunuzun önbelleğe alınmış bir sonucu olmadığı varsayılırsa, maps.google.com'u çözmek için ad sunucusu sorgunuzda kaç ad sunucusu sorulması gerekir? Tüm bu ad sunucularını bulmak için hangi komutları kullanırsınız? Her seviyeden bir tane listeleyin ve bu seviyenin neden gerekli olduğunu açıklayın.
Bunu bir araya getirelim.
"Yapılandırılmış ad sunucunuzun elinde herhangi bir önbellek sonucu olmadığı varsayılarak" - önce kapalı, hiç önbelleğe alınmış veri yoksa, hiçbir şeyi çözemez. Çözümleyicinin önbelleğini hazırlamak için, .(AKA kök) bölgesi için NS ve adres (A, AAAA) kayıtlarına sahip olmanız gerekir . Bu, root-servers.net.bölgede bulunan kök ad sunucularıdır . O bölge veya bu DNS sunucuları hakkında büyülü bir şey yok. Ancak, bu veriler genellikle çözümleyicinin önbelleğini hazırlamak için DNS çözümleyicisine "bant dışı" olarak sağlanır. Yalnızca yetkili ad sunucularının bu verilere ihtiyacı yoktur, ancak ad sunucularının çözümlenmesi gerekir.
Ayrıca, ne "çözmek"? Bu isimde herhangi bir RRtype var mı? Bir ARR? Veya başka bir şey? Hangi sınıf ( CH/ Chaosnet, IN/ Internet, ...)? Kesin süreç farklı olacaktır, ancak genel fikir aynı kalır.
Kök adı sunucularını nasıl bulacağımızı bildiğimizi varsayabiliriz, ancak başka bir şey değildir ve "çözmek" IN Aile adla ilişkili herhangi bir RR'nin içeriğini almak anlamına gelirsek, çok daha pratik hale gelir.
Bir DNS adını çözümlemek için, adı temel olarak etiketlere böler ve sağdan sola doğru ilerlersiniz. .Sonunda unutma ; gerçekten çözümlemek maps.google.com.yerine maps.google.com. Bu, bizi çözme gereği bırakıyor (bunu biliyoruz, ancak bir DNS çözümleyici uygulaması muhtemelen olmayacak):
.com.google.com.maps.google.com.
Nereden içerik isteyeceğinizi bulmakla başlayın .. Bu kolay; bu bilgilere zaten sahibiz: kök adı sunucu adları ve IP adresleri . Yani bir kök isim sunucumuz var. Diyelim ki a.root-servers.netisim çözümüne devam etmek için 198.41.0.4 ( , ayrıca 2001: 503: ba3e :: 2: 30) kullanmaya karar verdik . Uygulamada, çözümleyici tarafından yapılan ilk şeylerden biri, muhtemelen kök bölge sunucularından birinden kök bölge için ad sunucularının doğru bir listesini istemek için sağlanan kök sunucu verilerini kullanmak olacaktır. adlar ve IP adresleri geçerli ve erişilebilir, çözünürlük başladığında kök bölge için tam ve eksiksiz bir veri kümesine sahip olacaktır.
maps.google.com. IN A198.41.0.4 için bir DNS sorgusu çekin. Size cevap olarak "hayır, yapmayacaksınız, ama işte bilen biri" diyecektir; bu bir tavsiye. Söz NSkonusu sunucunun bildiği en yakın bölge için kayıtların yanı sıra sunucunun sahip olduğu tutkal kayıtları da içerir. Tutkal verisi yoksa, önce seçtiğiniz NS kaydında adı geçen ana bilgisayarı çözümlemeniz gerekir, bu nedenle IP adresini almak için ayrı bir ad çözümlemesi oluşturun; tutkal verisi mevcutsa, cevaba en azından "daha yakın" bir ad sunucusunun IP adresine sahip olursunuz. Bu durumda, bu com.bölge için sunucu kümesi olacaktır ve tutkal verileri de sağlanır.
com.Ad sunucularından birine aynı soruyu sorarak işlemi tekrarlayın . Onlar da bilmiyorlar, ancak sizi Google'ın yetkili ad sunucularına yönlendirecekler. Genel durumda bu noktada tutkal verilerinin sağlanmış olup olmadığı vurulur ya da özlenir; bir comalan adının yalnızca ad sunucularına sahip olmasını engelleyen hiçbir şey yoktur nl, örneğin bu durumda tutkal verilerinin gTLD sunucularından elde edilmesi olası değildir. Sağlanan tutkal verileri de eksik olabilir veya gerçekten şanssızsanız, yanlış bile olabilir! Yukarıda bahsettiğim ayrı isim çözümünü her zaman ortaya çıkarmaya hazır olmalısınız .
Temel olarak, aa(yetkili cevap) bayrak ayarıyla bir cevap alana kadar devam edersiniz . Bu cevap size ne istediğinizi ya da istediğiniz RR'nin mevcut olmadığını (ya NXDOMAINda NOERRORsıfır yanıt veri kayıtlarıyla) söyleyecektir . Gibi yanıtları aramaya devam edin SERVFAIL(ve bir adım SERVFAILgeri SERVFAILçekin ve bir tane alırsanız başka bir sunucuyu deneyin; tüm adlandırılmış sunucular geri dönerse, ad çözümleme işleminde başarısız olun ve kendinizi istemciye geri döndürün).
Her sunucudan tam RR adı istemenin alternatifi (kötü uygulama olarak kabul edilebilir), daha önce belirlediğimiz bölünmüş etiket listesini kullanmak, sunucu tarafından verilen ad sunucularından IN NSve IN A/ IN AAAARR'lerin köküne doğru sormaktır. etiketini kullanın ve ad çözümleme sürecini ilerletmek için bunları kullanın. Bu sadece pratikte marjinal olarak farklıdır ve aynı süreç hala geçerlidir.
BIND'in bir parçası olarak gelen veya içindeki yardımcı program +traceseçeneğini kullanarak bu işlemin tamamını simüle edebilirsiniz .digset debugnslookup
(Özellikle bazı RRtypes olması da hatırlatmakta fayda var NS, MXaynı zamanda, ve birkaç başka A6makul bir süre iyi kullanıldı ama kullanımdan kaldırıldı) ve referans diğer RR'lerini yapmak. Bu durumda, müşterinize eksiksiz ve faydalı bir yanıt vermek için başka bir ad çözümleme işlemi başlatmanız gerekebilir .
dig +trace, ama seviyelerle neyin kastedildiğinden emin değilim. Bu Sunucu Hatası için bir soru olabilir.