Ara alt alan adlarının bulunması gerekir mi?


27

Eğer ana bilgisayarlara example.comve leaf.intermediate.example.comDNS kayıtlarına sahipsem example.comancak kendim için bir kayıt intermediate.example.comyoksa, bu bazı durumlarda bir soruna neden olur mu, yoksa bir nedenden ötürü kötü bir tarz mı yoksa görgü kuralları mı? Bu şekilde kurulmuş web sunucularım var ve her şey yolunda gibi görünüyor, ancak sadece eksik bir şey olup olmadığını kontrol etmek istedim.


4

2
Ünvanın var olduğunu sorar , organın istediği kayıt yoktur . İnce ayrımlar için aşağıdaki yorumlara bakınız
Hagen von Eitzen

Yanıtlar:


38

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):

  1. 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:

  1. 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:


Mükemmel cevap Ara alanlar için verilen yanıtların bir RFC tarafından zorunlu kılınması mı yoksa sadece fiili bir kongre mi?
Lassi,

1
@Lassi, düzeltilmiş cevabımı görüyorum, bölümlere ayırmanın yanı sıra, çözümleyici algoritmasının tam bir açıklamasını da ekledim (bu yüzden hayır, bir kongre değil, ancak gerçekten de RFC’lerin İncil'i, RFC 1034’ün incili olsa bile 1035 kesinti ve belirsizliklerle doludur, bu nedenle dili ve kuralları geliştirmek için başka birçok RFC'ye ihtiyaç duyulmaktadır) ve ilgilenirse daha fazla bilgi edinmek için faydalı bağlantılar umuyorum.
Patrick Mevzek

1
@ Lassi Altyapı kayıtlarında çılgınca KBB örnekleri ekledim: PTR, SRV, DKIM için TXT, TLSA, URI
Patrick Mevzek

İnanılmaz derecede kapsamlı iş. Çabalarınız için teşekkürler!
Lassi

11

Khaled'in cevabını yanlış anlamış olabilirim, ancak ara kayıtların olmaması hiçbir şekilde subzonlanmış adın çözümünde bir sorun olmamalıdır. Bu kazı çıkışının, teaparty.netherhangi bir alt bölgeye ait yetkili bir DNS sunucusundan veya yönlendirilmediğini unutmayın :

[me@nand ~]$ dig very.deep.host.with.no.immediate.parents.teaparty.net
[...]
;; ANSWER SECTION:
very.deep.host.with.no.immediate.parents.teaparty.net. 3600 IN A 198.51.100.200

Aslında, bunu digkendiniz yapabilmeli ve bu cevabı alabilmelisiniz - teaparty.netbenim kontrolüm altında gerçek bir alan ve gerçekten de bu Akaydı içeriyor . Sen arasında bu bölgelerin herhangi biri için hiçbir kayıt olmadığını doğrulamak veryve teaparty.netve yukarıdaki ana makine adının da çözünürlük üzerinde hiçbir etkisi olduğunu.


1
Buradaki derinliğimden çıkmaya başlıyorum, ancak Patrick'in cevabına dayanarak bu muhtemelen işe yarıyor çünkü tüm teaparty.netkayıtların hepsini tek bir bölge dosyasında tutuyorsunuz, bu nedenle ara alanlar için boş kayıtlar sentezleniyor. Biri parents.teaparty.netbir delegasyon olsaydı ve sadece very.deep.host.with.no.immediatedelege bölgesi dosyasında bir kaydı varsa ne olacağını açıklayabilir mi?
Lassi,

@ Lassi tam olarak yukarıda gördüğünüzle aynı, çünkü aynısı aynı : teaparty.netdelege edilmiş bir alt etki alanı net; Eğer kendi alanındaki tek A kaydı very.deep...olsaydı önemli olmazdı.
MadHatter, Monica'yı

1
Örnek bağlantılar RFC uyumlu örnek etki alanlarını kullanmalıdır - burada meta tartışma: meta.stackexchange.com/questions/186529/…
HomoTechsual

1
Bu bir örnek link değil. İşe yarayacak (hatta denemek için bile uğraşmadın mı?) Eldeki noktaya almanca çalışıyor. Eğer göreceğiniz gibi bu meta tartışma gereken alan adlarının bir sürü değil soru ve cevap hem de Karartılmış.
MadHatter, Monica'yı

1
Ayrıca kafam karıştı, ama denedim. Bir süredir bunun bir tür joker karakter veya benzeri olduğundan emindim ... Bu alanın DNS yöneticisi olduğunu öğrenene kadar rekoru kırdın! Bu sadece cevabı okumaktan kolay bir şey değildir, bu yüzden genel olarak @HomoTechsual ile taraftayım. Sorun şu ki, bazı gelecekte kaydı silebilir veya etki alanı vb. Bununla birlikte, halka açık DNS'de özel IP adresleri yayınlamak iyi bir fikir değildir ;-)
Patrick Mevzek

2

Doğrudan yetkili DNS sunucusunu sorguluyorsanız, sorunsuz bir şekilde yanıt alırsınız.

Ancak, geçerli bir önbelleği olmayan başka bir DNS sunucusu üzerinden sorgu yapıyorsanız geçerli bir yanıt alamazsınız. İçin sorgulama intermediate.example.com, NXDOMAINhataya neden olur .


4
Bir sonuç NXDOMAINvermemeli, bir NOERRORkod ve boş bir Cevap bölümüyle sonuçlanmalıdır .
Barmar

4
Bu cevabın amacını göremiyorum. intermediate.example.comHerhangi bir şey için kullanılmazsa, kimsenin sorgulaması gereken hiçbir sebep yoktur . Öyleyse bir hata döndürse bile (değil) ne fark eder?
Barmar

5
Almazsın NXDOMAIN, alırsın NOERROR. DNS hiyerarşisinde var olan ancak istenen türde kayıt bulunmayan bir düğümün cevabı budur.
Barmar

3
Etki alanı mevcut olsa bile, sahip olduklarından farklı bir kayıt türü isterseniz bu cevabı alırsınız; Örneğin, NSkayıtları varsa , ancak Akayıtları isterseniz NOERROR, boş bir yanıt alırsınız .
Barmar

4
Bu yanlış. RFC 8020 Başına bir yetkili nameserver yanıt verirse NXDOMAINiçin intermediate.example.comhiçbir şey "altında" olduğu anlamına gelir o zaman ve daha sonra leaf.intermediate.example.comvar olamaz. Bazı agresif özyinelemeli çözümleyici bile bunu önbelleğe alabilir ve işleri kendi başlarına çıkarabilir.
Patrick Mevzek

1

Soruyu doğrudan cevaplamak için, aslında kullanmadığınız ara isimler için kayıt eklemeniz gerekmez, ancak bu isimlerin olmadığı anlamına gelmez.

Bu isimlerin olup olmadığına gelince, bu aslında kısa ve sezgisel bir cevap vermeyi umduğum tamamen ayrı bir soru.

Her şey bir DNS yapısına göre kaynar, bir alan adındaki her bir etiket bir ağaç düğümüdür. Örneğin, www.example.com.etiketler bulunur www, example, comher bir yol köküne yolu oluşturan ağaç düğümleri ve `` (kök düğümü).

DNS'nin bu temel niteliğini açıkça belirgin olmayan şey, DNS verilerini yönetirken neredeyse her zaman görülebilecek bir ağaç bulunmadığı ve genellikle doğrudan ağaç düğümleriyle kendi başımıza çalışmadığımızdır; farklı etki alanı adlarında bulunması gereken veriler (yukarıda belirtildiği gibi etkili ağaç yolları).

Ne bu düzleştirilmiş liste kullanıldığında olur DNS sunucusu yazılımı mevcut kayıtlar esas alınarak ağacı oluşturur olması ve (için kayıtlar vardır örneğin kayıtları düğümler arasındaki boşluklar varsa foo.bar.example.com.ve example.com.ancak bar.example.com.bu sadece boş ağaç olarak kabul edilir) düğümleri. Diğer bir deyişle, bunlar aslında var olan alan adları / düğümleridir, ağaç kırılmaz, bu düğümler sadece bunlarla ilişkili veriye sahip değildir.

Sonuç olarak, bu boş düğümlerden birini sorgularsanız , istenen kayıt türünün bu düğümde bulunmadığını söyleyen bir NODATAyanıt alırsınız ( yetki alanındaki NOERRORdurum + SOA). Bunun yerine, gerçekte bulunmayan bazı adları sorgularsanız NXDOMAIN, istenen etki alanı adının ağaçta bulunmadığını söyleyerek bir yanıt alırsınız .

Şimdi, azgın kumlu detaylarını istiyorsanız, Patrick Mevzek'in çok ayrıntılı cevabını okuyun.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.