TL; DR: evet orta alt alan adlarının, en azından DNS tanımına göre, en azından istendiğinde; Onlar yine de bölge dosyasında bulunmayabilir.
İlk ortadan kaldırmak için olası bir karışıklık; "Boş Terminal Olmayan" un tanımı
Diğer cevapların da yaptığı gibi iki şeyi karıştırıyor olabilirsiniz. Yani, ad sorguladığınızda, ad sunucunuzu ve bölge dosyasının içeriğini nasıl yapılandırdığınıza karşı ad sorgusu sırasında ne olur.
DNS hiyerarşiktir. Herhangi bir yaprak düğümünün var olması için, kendisine yönlendirilen tüm bileşenler mevcut olması GEREKİR, istenirse, sorumlu yetkili ad sunucusunun kendileri için hatasız cevap vermesi gerektiği anlamına gelmelidir.
RFC 8020'de açıklandığı gibi (bu sadece her zaman kuralın ne olduğunun bir tekrarıdır, ancak sadece bazı DNS sağlayıcıları bir hatırlatmaya ihtiyaç duyuyordu), eğer herhangi bir sorgu için yetkili bir ad sunucusu yanıtı NXDOMAIN (yani: bu kaynak kaydı mevcut değil), o zaman bu kaynağın "altındaki" herhangi bir etiketin de olmadığı anlamına gelir.
İçin bir sorgu eğer örnekte, intermediate.example.comiadeler NXDOMAIN, daha sonra herhangi bir uygun özyinelemeli adsunucusu derhal cevap verecektir NXDOMAINiçin leaf.intermediate.example.combu kayıt var olamaz çünkü tüm etiketler kayıtları olarak var yoksa.
Bu daha önce RFC 4592'de joker karakterlerle ilgili (burada ilgisiz) belirtilmişti:
Alan adı alanı bir ağaç yapısıdır. Ağaçtaki düğümler
en az bir RRSet'e sahiptir ve / veya toplu olarak
en az bir RRSet'e sahip olan soyundan vardır . Bir düğüm, yalnızca bunu yapan
torunları varsa, hiçbir RRSet olmadan mevcut olabilir ; bu düğüm boş bir terminal değil.
Torunları olmayan bir düğüm bir yaprak düğümüdür. Boş yaprak düğümleri mevcut değil.
.US alan adlarıyla pratik bir örnek
Tarihsel olarak pek çok etiketi olan TLD'den çalışan bir örnek ele alalım, yani .US. Çevrimiçi herhangi bir örnek alarak, kullanalım www.teh.k12.ca.us.
Tabi eğer bu ismi sorgularsanız veya kayıtları teh.k12.ca.usgeri alabilirsiniz A. Burada amacımız için kesin olan hiçbir şey yok (ortasında bir CNAME bile var, ama bunu umursamıyoruz):
$ dig www.teh.k12.ca.us A +short
CA02205882.schoolwires.net.
107.21.20.201
35.172.15.22
$ dig teh.k12.ca.us A +short
162.242.146.30
184.72.49.125
54.204.24.19
54.214.44.86
Şimdi k12.ca.ussorgulayalım: (Yetkili ad sunucusunu sorgulamıyorum, ancak bu sonucu değiştirmiyor):
$ dig k12.ca.us A
; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> k12.ca.us A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;k12.ca.us. IN A
;; AUTHORITY SECTION:
us. 3587 IN SOA a.cctld.us. hostmaster.neustar.biz. 2024847624 900 900 604800 86400
;; Query time: 115 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: mer. juil. 03 01:13:20 EST 2019
;; MSG SIZE rcvd: 104
Bu cevaptan ne öğreniyoruz?
İlk olarak, bu bir başarı çünkü durum böyle NOERROR. Başka bir şey olsaydı ve özellikle NXDOMAINo zaman teh.k12.ca.us, ya da www.teh.k12.ca.usolamazdı.
İkincisi, CEVAP bölümü boş. İçin Akayıt yok k12.ca.us. Bu bir hata Adeğil, bu kayıt ( ) bu kayıt için mevcut değil, fakat bu kayıt için başka kayıt türleri de var ya da bu kayıt bir KBB, yani "Boş Terminal Yok": boş, ancak bir yaprak değil, “altında” olan şeyler var ( RFC 7719'daki tanımlamaya bakınız ), zaten bildiğimiz gibi (fakat normalde çözünürlük yukarıdan aşağıya doğru gidiyor, bu nedenle gösteri için yaptığımız gibi bir seviyenin altına düşmeden önce bu adıma ulaşacağız. amaç).
Bu nedenle, kısayol olarak durum kodunun şöyle olduğunu söylüyoruz NODATA: bu gerçek bir durum kodu değildir, sadece NOERROR+ boş CEVAP bölümü anlamına gelir, bu, bu belirli kayıt türü için veri olmadığı anlamına gelir, ancak diğerleri için de olabilir.
Bir sonraki "yukarı" etiketini kullanarak sorguladığınızda, aynı deneyi, aynı sonuç için tekrarlayabilirsiniz ca.us.
Sorguların sonuçları - zonefile içeriği
Karışıklık nereden gelebilir? Bir DNS adındaki herhangi bir noktanın bir delegasyon olduğu anlamına geldiği konusunda yanlış bir fikirden gelebileceğine inanıyorum. Bu yanlış. Farklı şekilde example.comsöylendiği gibi, bölge dosyalarınız böyle olabilir ve bu tamamen geçerli ve çalışıyor:
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
Böyle bir bölge dosyasıyla, bu ad sunucusunu sorgulamak, yukarıda gözlemlenen davranışı tam olarak alır: bir sorgu boş bir cevapla intermediate.example.comgeri döner NOERROR. Özellikle bölge dosyasında oluşturmanız gerekmez (başka nedenlerden dolayı ihtiyacınız yoksa), yetkili ad sunucusu "ara" yanıtları sentezlemeye özen gösterir, çünkü bu boş olmayan terminale ihtiyacı olduğunu görür (ve herhangi bir diğer etiketler olsaydı diğerleri arasında "aralarında") yaprak adını gördüğü gibi leaf.intermediate.example.com.
Bunun aslında bazı alanlarda yaygın bir durum olduğunu, ancak insanların maruz kalmadığı "altyapı" kayıtlarını hedeflediği için göremeyebileceğinizi unutmayın:
- tersi bölgelerde
in-addr.arpveya ip6.arpaözellikle sonuncusu gibi. Gibi kayıtlara sahip olacaksınız 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1h IN PTR text-lb.eqiad.wikimedia.org.ve açıkça her noktada bir delegasyon ya da her bir etikette eklenmiş kaynak kayıtları yok
- içinde
SRVkayıtları gibi _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., etki alanı çok olabilir _proto._tcp.example.comve _proto._udp.example.com SRVtasarımla bu formu olması gerekir, çünkü ancak aynı zamanda, kayıtları _tcp.example.comve _udp.example.comkayıtları gibi hiç kullanılmamış çünkü Boş Sigara Terminalleri kalacaktır
- Aslında DKIM gibi çeşitli protokoller için "alt çizgi etiketlerine" dayanan birçok özel yapım isminiz var. DKIM, sizin gibi DNS kayıtlarına sahip olmanızı zorunlu kılar
whatever._domainkey.example.com, ancak açık bir _domainkey.example.comşekilde asla kullanılmayacak, bu nedenle boş bir terminal olmayacaktır. Bu aynıdır TLSA: (eski DANE kayıtların _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==ya) URIkayıtları (örn: _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public")
İsim sunucusu davranışı ve ara cevapların oluşturulması
Ad sunucusu neden bu tür ara cevapları otomatik olarak sentezliyor? DNS için çekirdek çözünürlük algoritması, RFC 1034 bölüm 4.3.2'de ayrıntılı olarak açıklandığı gibi , bunun nedenidir, adı alalım ve bizim için yukarıdaki yetkili ad sunucusu sorulurken özetleyelim intermediate.example.com( QNAMEaşağıdaki protokolde budur):
- QNAME'ye en yakın ata olan bölge için kullanılabilir bölgeleri arayın. Böyle bir bölge bulunursa, 3. adıma gidin, aksi takdirde 4. adım.
example.comAd sunucusu, QNAME'nin en yakın atası olarak bölgeyi bulur , bu nedenle 3. adıma geçebiliriz.
Şimdi bu var:
- Bölgede aşağı doğru, etikete göre etiketlemeye başlayın. [..]
a. Eğer tüm QNAME eşleşirse, düğümü bulduk. [..]
b. Bir eşleşme bizi yetkili verilerden çıkarırsa, bir yönlendirmemiz gerekir. Bu, NS RR'leri bir bölgenin altındaki kesiklere işaretleyen bir düğümle karşılaştığımızda olur. [..]
c. Bir etikette eşleşme imkansız ise (yani ilgili etiket yoksa), "*" etiketi olup olmadığını kontrol edin. [..]
B ve c durumlarını ortadan kaldırabiliriz, çünkü bölge dosyamızda delegasyon yoktur (bu nedenle hiçbir zaman diğer ad sunucularına yönlendirmeler yapılmayacaktır, b davası yok), ya da joker karakterler (yani c davası olmaz).
Burada sadece bir dava ile uğraşmamız gerekiyor.
Bölgede etiket etiketine göre aşağı doğru eşleştirmeye başlıyoruz. Bu yüzden uzun bir sub.sub.sub.sub.sub.sub.sub.sub.example.comisme sahip olsak bile, bir noktada, şu duruma vardık: bir yönlendirme ya da joker karakter bulamadık, ancak sonuçta istediğimiz son isme ulaştık.
Ardından, dava a'nın kalan kısmını uygularız:
Düğümdeki veriler bir CNAME ise
Bizim durumumuz değil, bunu atlıyoruz.
Aksi takdirde, QTYPE ile eşleşen tüm RR'leri cevap bölümüne kopyalayın ve 6. adıma gidin.
(Biz seçmek QTYPE ne olursa olsun A, AAAA, NSbiz hiçbir RR'lerini var, vs.) intermediate.example.como alan dosyalarının görünmüyor olarak. Yani buradaki kopya boş. Şimdi adım 6'da bitiriyoruz:
Yalnızca yerel verileri kullanarak, sorgunun ek bölümüne faydalı olabilecek başka RR'ler eklemeye çalışın. Çıkış.
Burada bizim için önemli değil, bu yüzden başarı ile bitiriyoruz.
Bu, gözlemlenen davranışı tam olarak açıklar: bu tür sorgular da döndürülür, NOERRORancak veri de olmaz.
Şimdi kendinize şu soruyu sorabilirsiniz: "ama sonra herhangi bir isim kullanırsam another.example.com, yukarıdaki algoritma ile olduğu gibi aynı cevabı almalıyım (hata yok)", ancak gözlemler bunun yerine NXDOMAINbu durumu bildirir .
Niye ya?
Çünkü açıklandığı gibi tüm algoritma bununla başlar:
Aşağıdaki algoritma, RR'lerin her bölge için biri diğeri önbellek için birkaç ağaç yapısında düzenlendiğini varsayar.
Bu, yukarıdaki bölge dosyasının bu ağaca dönüştürüldüğü anlamına gelir:
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
: Üstten, algoritma aşağıdaki Yani, gerçekten bir yol bulabilirsiniz com > example > intermediate(yol nedeniyle com > example > intermediate > leafiçin var) Ama another.example.comsonra com > examplesen bulmuyorum anotherağacında etiketi çocuklar arasında düğüm olarak, example. Dolayısıyla yukarıdan c seçeneğinin bir parçası haline geliriz:
"*" Etiketi yoksa, aradığımız adın sorgudaki orijinal QNAME veya CNAME nedeniyle takip ettiğimiz bir ad olup olmadığını kontrol edin. Ad orijinalse, yanıtta yetkili bir ad hatası ayarlayın ve çıkın. Aksi takdirde sadece çıkın.
Etiket *mevcut değil ve CNAMEa'yı takip etmedik , dolayısıyla biz durumdayız:, set an authoritative name error in the response and exitaka NXDOMAIN.
Yukarıdakilerin hepsinin geçmişte karışıklık yarattığına dikkat edin. Bu, bazı RFC'lerde toplanır. Örneğin, beklenmedik yerlere (DNS özelliklerinin neşesi bu kadar zorlanamaz) joker karakterleri tanımlamaya bakın: RFC 4592 "Etki Alanı Adı Sistemindeki Joker Karakterlerin Rolü" ve özellikle de "Başına Dönme Kuralları" adlı bölüm 2.2. cevabım ama burada daha tamamlandı:
Boş olmayan terminaller [RFC2136, bölüm 7.16], kaynak kaydına sahip olmayan ancak alt etki alanlarına sahip alan adlarıdır. Bölüm 2.2.1'de
"_tcp.host1.example." boş olmayan bir terminal adı örneğidir.
Boş olmayan terminaller bu metin tarafından RFC 1034'ün 3.1 bölümünde verilmiştir:
# The domain name space is a tree structure. Each node and leaf on
# the tree corresponds to a resource set (which may be empty). The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.
"Boş olabilen" parantez içinde, boş olmayan
terminallerin açıkça tanındığını ve boş olmayan terminallerin
"var olduğunu" belirtir .
Yukarıdaki paragrafı bilerek okumak,
bir alan adı için
önerilen
255 oktet sınırına kadar olası tüm alan adlarının mevcut olduğu yorumuna yol açabilir [RFC1035]. Örneğin,
www.example. Bir A RR'ye sahip olabilir ve pratik olarak,
etki alanı ağacının bir yaprağıdır. Fakat tanım, bu alt örnek
ile ifade edilebilir . veri olmadan da var. Ek olarak, tüm olası alanlar kökten aşağıya doğru mevcuttur.
RFC 1034 ayrıca bölüm 4.3.1'de "adın bulunmadığını gösteren yetkili bir ad hatası" tanımladığından, bu nedenle bu, bir sonraki bölümde güncellenmiş tanım ihtiyacını haklı çıkaracak şekilde, orijinal tanımın amacı değildir.
Ve bir sonraki bölümdeki tanım, başlangıçta alıntı yaptığım paragraftır.
(RFC 8020 geldiğini hatırlatırız NXDOMAINgerçekten anlam NXDOMAINYanıtladığınızda eğer olduğunu NXDOMAINiçin intermediate.example.comdaha sonra leaf.intermediate.example.comçeşitli DNS sağlayıcıları bu yorumlanması ve bu yaratılan tahribat takip etmedi, ya da sadece hatalar vardı, örneğin bu bir bakınız çünkü var olamaz) bölümünde zorunlu tutulduğundan 2013 yılında bir açık kaynaklı yetkili ad sunucusu kodunda düzeltildi: https://github.com/PowerDNS/pdns/issues/127
İnsanların sadece kendileri için belirli karşı tedbirler koymaları gerekiyordu: bu, agresif bir şekilde önbelleğe alma değil, NXDOMAINçünkü bu sağlayıcılar için eğer NXDOMAINbir düğüme gelirseniz, yine de NXDOMAINaltındaki düğümden başka bir şey aldığınız anlamına gelebilir .
Ve bu, QNAME minimizasyonu (RFC 7816) elde etmeyi imkansız hale getirdi ( daha fazla ayrıntı için https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdf bakın) , iken gizliliği artırmak istedi. DNSSEC durumunda boş olmayan terminallerin varlığı da geçmişte, varolmayanların ele alınmasıyla ilgili sorunlar yarattı (bkz. Https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647). /AFNIC_OARC_Dallas.pdf ilgileniyorsanız, ancak daha önce DNSSEC'yi gerçekten iyi anlamanız gerekir).
Aşağıdaki iki mesaj, bir sağlayıcının Terminalleri Boş Olmayanlar için bu kuralı uygun şekilde uygulayabilmesi gereken sorunlara bir örnek teşkil etmekte olup, meseleler ve neden orada olduğumuzla ilgili bir bakış açısı sunmaktadır: