Alt kimlik
Apeks düzeyinde NS kayıtları, ana sunucu tarafından astlarını tanımlamak için kullanılır. Yetkili bir ad sunucusundaki veriler değiştiğinde, bunu DNS NOTIFYiletilerle ( RFC 1996 ) bu listedeki tüm akranlarına duyurur. Bu sunucular sırayla SOA(seri numarasını içeren) bir kayıt talebi ile geri arayacak ve o bölgenin daha yeni bir kopyasının kaldırılıp kaldırılmayacağına karar verecektir .
- Bu iletileri
NSbölümde listelenmeyen sunuculara göndermek mümkündür , ancak bu, sunucuya özgü yapılandırma yönergeleri gerektirir (ISC BIND also-notifyyönergesi gibi). Apex NS kayıtları, varsayılan bir yapılandırma altında bildirilecek temel sunucu listesini içerir.
- İkincil sunucuların da bu
NSkayıtlara dayanarak birbirlerine NOTIFY mesajları göndereceğini ve bu da genellikle kaydedilmiş reddedilmelere yol açacağını belirtmek gerekir . Bu, sunuculardan yalnızca ana oldukları oldukları bölgeler için bildirim göndermelerini (BIND:) bildirmeleri notify master;veya NSyapılandırmada açıkça tanımlanan bildirimler lehine temelli bildirimleri atlamaları talimatıyla devre dışı bırakılabilir . (Bağlanmaktadır: notify explicit;)
Yetkili tanım
Yukarıdaki soru bir yanılgı içeriyordu:
Etki alanı için yetkili sunucuları belirlemek amacıyla DNS sunucularını önbelleğe alarak kullanılmazlar. Bu, kayıt şirketi düzeyinde tanımlanan ad sunucusu tutkalı tarafından ele alınır. Kayıt şirketi tutkal kayıtlarını oluşturmak için asla bu bilgileri kullanmaz.
Bu, ulaşılması kolay bir sonuçtur, ancak doğru değildir. NSKayıtları ve uygulamalarda (örneğin kayıt kuruluşu hesabında tanımlanır olduğu gibi) tutkal kayıt verileri yetkili değildir. Yetkilinin devredildiği sunucularda bulunan verilerden "daha yetkili" olarak değerlendirilmemelerinin sebebi budur. Bu, yönlendirmelerin aa(Yetkili Cevap) bayrağının ayarlanmamış olmasıyla vurgulanmaktadır .
Örneklemek gerekirse:
$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 172800 IN A 199.43.135.53
a.iana-servers.net. 172800 IN AAAA 2001:500:8f::53
b.iana-servers.net. 172800 IN A 199.43.133.53
b.iana-servers.net. 172800 IN AAAA 2001:500:8d::53
aaYukarıdaki cevap için bayrakların eksikliğine dikkat edin. Yönlendirmenin kendisi yetkili değildir. Öte yandan, sunucu varlığa ilişkin veriler atıfta olan yetkili.
$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; ANSWER SECTION:
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
Bununla birlikte, bu ilişki, başvurunun üst tarafında tanımlanan NSyetkili olmayan kayıtlar olmadan bu kayıtların yetkili sürümleri hakkında bilgi edinmek mümkün olmadığından çok kafa karıştırıcı olabilir NS. Kabul etmezlerse ne olur?
- Kısa cevap "tutarsız davranış" tır.
- Uzun cevabı ad sunucularının başlangıçta saplama boş cache üzerinde yönlendirme (ve tutkal) kapalı her şeyi, ancak bu olacaktır
NS, Ave AAAAbunlar yenilenir zaman kayıtlar sonunda değiştirilebilir. Yenilemeler, bu geçici kayıtlardaki TTL'lerin süresi dolduğunda veya birisi bu kayıtlar için açıkça yanıt istediğinde gerçekleşir.
Ave AAAAbölge dışı verilerin (yani bölge comdışındaki veriler için yapıştırıcıyı tanımlayan ad sunucuları comgibi example.net) kayıtlar kesinlikle yenilenecektir, çünkü bir ad sunucusunun bu tür bilgilerin yetkili bir kaynağı olarak görülmemesi gerektiği iyi anlaşılmış bir kavramdır. . (RFC 2181)NSKayıtların değerleri, başvurunun üst ve alt tarafları arasında farklılık gösterdiğinde (kayıt şirketi kontrol paneline girilen ad NSsunucuları, aynı sunucularda yaşayan kayıtlardan farklı olarak ), yaşanan davranışlar, çocuğa kadar ve dahil olmak üzere tutarsız olacaktır. NSkayıtlar tamamen yok sayılıyor. Bunun nedeni, davranışın standartlar tarafından iyi tanımlanmamış olması ve uygulamanın farklı özyinelemeli sunucu uygulamaları arasında değişiklik göstermesidir. Başka bir deyişle, internet üzerindeki tutarlı davranış ancak bir alanın ad sunucusu tanımlarının bir başvurunun üst ve alt tarafları arasında tutarlı olması durumunda beklenebilir .
Uzun ve kısa, başvurunun üst tarafında tanımlanan kayıtlar bu kayıtların yetkili sürümleri ile uyuşmuyorsa, internet boyunca özyinelemeli DNS sunucularının hedefler arasında geri dönmesi olacaktır. Başlangıçta, referansta mevcut olan veriler tercih edilecektir, sadece yetkili tanımlarla değiştirilmelidir. Önbellekler sürekli olarak İnternet üzerinden sıfırdan yeniden oluşturulduğundan, bu yapılandırma ile internetin gerçekliğin tek bir versiyonuna yerleşmesi imkansızdır. Yetkili kayıtlar standartlara göre yasa dışı bir şey yapıyorsa, örneğin NSbirCNAME, bu sorunu gidermek daha da zorlaşır; etki alanı, ihlali reddeden yazılım için çalışma ve bozuk arasında değişecektir. (yani ISC BIND / adlı)
RFC 2181 §5.4.1 , bu verilerin güvenilirliği için bir sıralama tablosu sağlar ve başvurular ve yapıştırıcı ile ilişkili önbellek verilerinin, başvurdukları kayıtlar için açık bir talebin yanıtı olarak döndürülemeyeceğini açıkça belirtir.
5.4.1. Ranking data
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. An
authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply.
However additional information from a reply will be ignored if the
cache contains data from an authoritative answer or a zone file.
The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:
+ Data from a primary zone file, other than glue data,
+ Data from a zone transfer, other than glue,
+ The authoritative data included in the answer section of an
authoritative reply.
+ Data from the authority section of an authoritative answer,
+ Glue from a primary zone, or glue from a zone transfer,
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
<snip>
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.