Aslında, bundan daha karmaşıktır - bir "merkezi kayıt defteri (bu) etki alanlarını (www.mysite.com) DNS sunucularına eşleyen bir tablo tutar" yerine, birkaç hiyerarşi katmanı vardır
- tüm üst düzey alanlar için NS (alan adı sunucusu) kayıtları: bir merkezi kayıt defteri girdilerini, çok az sayıda içerirler (Kök Sunucular) var .com, .net, .org, .uk, .us, .au, vb.
Bu sunucular sadece bir sonraki seviye için NS kayıtlarını içeriyor. Bir örnek almak için, isim sunucularından .uketki sadece için giriş vardır .co.uk, .ac.ukve İngiltere'de kullanımında diğer ikinci düzey bölgelerini.
Bu sunucular sadece bir sonraki seviye için NS kayıtlarını içerirler - örneğe devam etmek için, NS kayıtlarını nerede bulacaklarını söylerler google.co.uk. Sonunda, böyle bir ana bilgisayar adı www.google.co.ukile bir IP adresi arasında bir eşleşme bulacağınız sunucularda bulunur .
Ekstra bir kırışıklık olarak, her katman aynı zamanda 'tutkal' kayıtlarını da üstlenecektir. Her bir NS kaydı bir etki alanını bir ana bilgisayar adına eşleştirir - örneğin, NS .uklisteyi nsa.nic.uksunuculardan biri olarak kaydeder . Bir sonraki seviyeye geçmek için, NS kayıtlarını bulmamız gerekiyor nic.ukve bunların da dahil nsa.nic.ukolduğu ortaya çıkıyor. Bu yüzden şimdi IP'sini bilmemiz gerekiyor nsa.nic.uk, ama bunu bulmak için bir sorgu yapmamız gerekiyor nsa.nic.uk, ama IP'yi öğrenene kadar bu sorguyu yapamayız nsa.nic.uk...
Bu açmazı aşmak için, sunucular için .ukA kaydı eklemek nsa.nic.ukiçine ADDITIONAL SECTIONtepki (kısalık için kesilmiş aşağıda yanıt) arasında:
jamezpolley@li101-70:~$dig nic.uk ns
; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;nic.uk. IN NS
;; ANSWER SECTION:
nic.uk. 172800 IN NS nsb.nic.uk.
nic.uk. 172800 IN NS nsa.nic.uk.
;; ADDITIONAL SECTION:
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
Bu ekstra yapıştırıcı kayıtları olmadan, ad sunucularını asla bulamayacağız nic.uk.ve bu nedenle orada barındırılan herhangi bir alana bakamayacağız.
Sorularınıza geri dönmek için ...
a) Avantaj nedir? Neden doğrudan bir IP adresine eşlenmiyor?
Birincisi, her bir bölgedeki düzenlemelerin dağıtılmasına izin veriyor. İçin girişi güncellemek istiyorsanız www.mydomain.co.uk, yalnızca sunucunuzun mydomain.co.ukadındaki bilgileri düzenlemeniz gerekir . Merkezi .co.uksunucuları, .uksunucuları veya kök isim sunucularını bildirmeye gerek yoktur . DNS seviyesinin zincir boyunca aşağı indiği her değişiklikten haberdar edilmesi gereken hiyerarşinin sonuna kadar tüm seviyeleri eşleyen yalnızca tek bir merkezi kayıt olsaydı, kesinlikle trafik ile dolup taşardı.
1982'den önce, aslında isim çözümlemesi böyle oldu. Merkezi kayıtlara tüm güncellemeler hakkında bilgi hosts.txtverildi ve internet üzerindeki her makinenin ana bilgisayar adını ve IP adresini içeren bir dosya dağıtıldı . Bu dosyanın yeni bir sürümü birkaç haftada bir yayınlandı ve internetteki her makinenin yeni bir kopyasını indirmesi gerekiyordu. 1982'den önce, bu sorun olmaya başlamıştı ve böylece DNS daha dağınık bir sistem sağlamak için icat edildi.
Başka bir şey için, bu Tek Hata Noktası olacaktır - eğer tek merkez kayıt defteri çökerse internetin tamamı çevrimdışı olacaktır. Dağıtık bir sisteme sahip olmak, başarısızlıkların sadece internetin küçük bölümlerini etkilediği anlamına gelir, her şeyi değil.
(Fazlalık fazlalık sağlamak için, aslında kök bölgeye hizmet eden 13 ayrı sunucu kümesi vardır. Üst düzey etki alanı kayıtlarında yapılan herhangi bir değişikliğin 13'üne basılması gerekir; her bir değişiklik için bunların 13'ünün de güncellenmesini koordine etmek zorunda olduğunuzu hayal edin. dünyanın herhangi bir yerindeki herhangi bir ana bilgisayar adına ...)
b) Bir DNS sunucusunu farklı bir IP adresine işaret edecek şekilde yapılandırdığımda değiştirmesi gereken tek kayıt DNS sunucusundaysa, işlem neden anlık olmaz?
Çünkü DNS hem işleri hızlandırmak hem de NS'ler üzerindeki yükü azaltmak için çok fazla önbellekleme kullanıyor. Önbelleğe alma olmadan, her zaman ziyaret google.co.ukBilgisayarınız için sunucuları aramak için ağa dışarı çıkmak zorunda kalacak .uk, sonra .co.uk, sonra .google.co.uk, sonra www.google.co.uk. Bu cevaplar aslında çok fazla değişmiyor, bu yüzden her zaman onları aramak zaman kaybı ve ağ trafiği anlamına geliyor. Bunun yerine, NS bilgisayarınıza kayıtlar döndürdüğünde, bilgisayarınıza birkaç saniye boyunca sonuçları önbelleğe almasını söyleyen bir TTL değeri içerecektir.
Örneğin, NS kayıtları için .uk172800 saniye TTL var - 2 gün. Google daha da muhafazakar - NS kayıtları google.co.uk4 günlük bir TTL'ye sahip. Hızlı bir şekilde güncellenmeye dayanan hizmetler çok daha düşük bir TTL seçebilir - örneğin, telegraph.co.ukNS kayıtlarında yalnızca 600 saniyelik bir TTL vardır.
Bölgenizdeki güncellemelerin anında gerçekleşmesini istiyorsanız, TTL'nizi istediğiniz kadar aşağı indirmeyi seçebilirsiniz. Ayarlarınız ne kadar düşük olursa, müşteriler kayıtlarını daha sık yeniledikçe sunucularınız o kadar çok trafik görür. Bir müşteri bir sorgu yapmak için sunucularınızla her bağlantı kurması gerektiğinde, bu durum yerel önbellekteki cevabı aramaktan daha yavaş olduğu için, bazı gecikmelere neden olacaktır; bu nedenle hızlı güncellemeler ve hızlı bir servis arasındaki tradeoffayı da göz önünde bulundurmak isteyeceksiniz.
c) Gecikmenin tek nedeni DNS önbellekleri ise, onları atlamak mümkün mü, bu yüzden gerçek zamanlı olarak ne olduğunu görebiliyor muyum?
Evet, el ile digveya benzer araçlarla test ediyorsanız bu kolaydır - sadece hangi sunucuyla bağlantı kuracağınızı söyleyin.
İşte önbelleğe alınmış bir yanıt örneği:
jamezpolley@host:~$dig telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 319 IN NS ns1-63.akam.net.
telegraph.co.uk. 319 IN NS eur3.akam.net.
telegraph.co.uk. 319 IN NS use2.akam.net.
telegraph.co.uk. 319 IN NS usw2.akam.net.
telegraph.co.uk. 319 IN NS use4.akam.net.
telegraph.co.uk. 319 IN NS use1.akam.net.
telegraph.co.uk. 319 IN NS usc4.akam.net.
telegraph.co.uk. 319 IN NS ns1-224.akam.net.
;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb 2 05:46:02 2012
;; MSG SIZE rcvd: 198
Buradaki bayraklar bölümü aabayrağı içermiyor , bu nedenle bu sonucun doğrudan yetkili bir kaynaktan ziyade bir önbellekten geldiğini görebiliyoruz. Aslında, 97.107.133.4Linode'nin yerel DNS çözümleyicilerinden biri olarak ortaya çıktığını görüyoruz . Cevabın bana çok yakın olan bir önbellekten sunulması, benim için bir cevap almamın 0msn sürdüğü anlamına gelir; ancak birazdan göreceğimiz gibi, bu hız için ödediğim fiyat, cevabın neredeyse 5 dakika eski olduğudur.
Linode çözücüsünü atlamak ve doğrudan kaynağa gitmek için, bu NS'lerden birini seçin ve doğrudan iletişime geçmesini isteyin:
jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 600 IN NS use2.akam.net.
telegraph.co.uk. 600 IN NS eur3.akam.net.
telegraph.co.uk. 600 IN NS use1.akam.net.
telegraph.co.uk. 600 IN NS ns1-63.akam.net.
telegraph.co.uk. 600 IN NS usc4.akam.net.
telegraph.co.uk. 600 IN NS ns1-224.akam.net.
telegraph.co.uk. 600 IN NS usw2.akam.net.
telegraph.co.uk. 600 IN NS use4.akam.net.
;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb 2 05:48:47 2012
;; MSG SIZE rcvd: 198
Bu sefer sonuçların doğrudan kaynaktan aageldiğini görebilirsiniz - sonuçların yetkili bir kaynaktan geldiğini gösteren bayrağa dikkat edin . Daha önceki örneğimde, sonuçlar yerel önbellekten geldi, bu yüzden aabayraktan yoksunlar. Bu etki alanının yetkili kaynağının 600 saniyelik bir TTL ayarladığını görebiliyorum. Daha önce yerel bir önbellekten aldığım sonuçların TTL değeri sadece 319 saniyeydi, bu da onları görmeden önce (yaklaşık 5 dakika) önbellekte (600-319) saniye beklediklerini söyledi.
Buradaki TTL sadece 600 saniye olsa da, bazı ISS'ler, DNS çözümleyicilerini sonuçları daha uzun süre önbelleğe almaya zorlayarak (bazı durumlarda 24 saat veya daha fazla) trafiğini daha da azaltmaya çalışacaktır. Yaptığınız herhangi bir DNS değişikliğinin her yerde görünmeyeceğini varsaymak gelenekseldir (bu, gerçekten bilmemiz gereken bir şeydir, bilmemiz gereken bir yöntemdir). 24-48 saat boyunca internet.