Jika saya memiliki host example.com
dan leaf.intermediate.example.com
dalam catatan DNS untuk example.com
, tetapi tidak memiliki catatan untuk intermediate.example.com
dirinya sendiri, apakah itu menyebabkan masalah dalam beberapa situasi atau apakah itu gaya atau etiket yang buruk karena alasan tertentu? Saya memiliki server web yang diatur seperti ini dan semuanya tampaknya berfungsi dengan baik, tetapi hanya ingin memeriksa apakah ada sesuatu yang saya lewatkan.
27
Jawaban:
TL; DR: ya subdomain menengah perlu ada, setidaknya ketika ditanya untuk, per definisi DNS; mereka mungkin tidak ada di zonefile.
Kemungkinan kebingungan untuk dihilangkan terlebih dahulu; Definisi "Empty Non-Terminal"
Anda mungkin membingungkan dua hal, karena jawaban lain tampaknya juga bisa dilakukan. Yaitu, apa yang terjadi ketika menanyakan nama versus cara Anda mengonfigurasi server nama Anda dan konten zonefile.
DNS bersifat hierarkis. Untuk setiap simpul daun ada, semua komponen yang mengarah padanya HARUS ada, dalam arti bahwa jika ditanya, server nama yang bertanggung jawab harus menjawabnya tanpa kesalahan.
Sebagaimana dijelaskan dalam RFC 8020 (yang hanya merupakan pengulangan dari apa yang selalu menjadi aturan, tetapi hanya beberapa penyedia DNS yang membutuhkan pengingat), jika untuk permintaan apa pun, server nama yang berwenang membalas NXDOMAIN (yaitu: catatan sumber daya ini tidak ada), maka itu berarti label apa pun "di bawah" sumber ini juga tidak ada.
Dalam contoh Anda, jika permintaan untuk
intermediate.example.com
pengembalianNXDOMAIN
, maka setiap nameserver rekursif yang tepat akan segera membalasNXDOMAIN
untukleaf.intermediate.example.com
karena catatan ini tidak bisa eksis jika semua label di dalamnya tidak ada sebagai catatan.Ini sudah dinyatakan di masa lalu dalam RFC 4592 tentang wildcard (yang tidak terkait di sini):
Contoh praktis dengan nama domain .US
Mari kita ambil contoh kerja dari TLD dengan banyak label secara historis, yaitu
.US
. Memilih contoh apa pun secara online, mari kita gunakanwww.teh.k12.ca.us
.Tentu saja jika Anda mencari nama ini, atau bahkan
teh.k12.ca.us
Anda bisa mendapatkan kembaliA
catatan. Tidak ada yang konklusif di sini untuk tujuan kami (bahkan ada CNAME di tengahnya, tetapi kami tidak peduli tentang itu):Marilah kita kueri sekarang untuk
k12.ca.us
(Saya tidak meminta server nama otoritatif untuk itu, tapi itu sebenarnya tidak mengubah hasilnya):Apa yang kita pelajari dari jawaban ini?
Pertama, ini sukses karena statusnya
NOERROR
. Seandainya ada hal lain dan khususNXDOMAIN
saat ituteh.k12.ca.us
, tidakwww.teh.k12.ca.us
akan ada.Kedua, bagian JAWABAN kosong. Tidak ada
A
catatan untukk12.ca.us
. Ini bukan kesalahan, tipe ini (A
) tidak ada untuk catatan ini, tapi mungkin tipe catatan lain ada untuk catatan ini atau catatan ini adalah ENT, alias "Empty Non Terminal": itu kosong, tetapi itu bukan daun, ada hal-hal "di bawah" itu (lihat definisi dalam RFC 7719 ), seperti yang sudah kita ketahui (tetapi biasanya resolusi top-down, jadi kita akan mencapai langkah ini sebelum naik satu tingkat di bawah dan bukan sebaliknya seperti yang kita lakukan di sini untuk demonstrasi tujuan).Inilah sebabnya mengapa sebenarnya, sebagai pintasan, kita mengatakan kode statusnya adalah
NODATA
: ini bukan kode status nyata itu hanya berartiNOERROR
+ bagian JAWABAN kosong, yang berarti tidak ada data untuk tipe catatan spesifik ini tetapi mungkin ada untuk yang lain.Anda dapat mengulangi percobaan yang sama untuk hasil yang sama jika Anda kueri dengan label "naik" berikutnya, yaitu namanya
ca.us
.Hasil kueri vs konten zonefile
Sekarang dari mana kebingungan bisa datang? Saya percaya ini mungkin berasal dari beberapa ide yang salah bahwa setiap titik dalam nama DNS berarti ada delegasi. Ini salah. Dikatakan berbeda,
example.com
zonefile Anda bisa seperti itu, dan itu benar-benar valid dan berfungsi:Dengan zonefile seperti itu, dengan menanyakan nameserver ini Anda akan mendapatkan persis perilaku yang diamati di atas: kueri untuk
intermediate.example.com
akan kembaliNOERROR
dengan jawaban kosong. Anda tidak perlu membuatnya secara khusus di zonefile (jika Anda tidak membutuhkannya karena alasan lain), nameserver yang berwibawa akan mengurus mensintesis balasan "perantara", karena ia melihatnya memerlukan non-terminal kosong ini (dan yang lain "di antara" jika ada label lain) karena melihat nama daunleaf.intermediate.example.com
.Perhatikan bahwa ini adalah kasus yang tersebar luas di beberapa daerah, tetapi Anda mungkin tidak melihatnya karena menargetkan lebih banyak catatan "infrastruktur" yang tidak diketahui orang:
in-addr.arp
atauip6.arpa
, dan khususnya yang terakhir. Anda akan memiliki catatan seperti1.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.
dan jelas tidak ada delegasi di setiap titik, atau catatan sumber daya yang terlampir di setiap labelSRV
catatan, seperti_nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr.
, domain dapat memiliki banyak_proto._tcp.example.com
dan_proto._udp.example.com
SRV
catatan karena dengan desain mereka harus memiliki formulir ini, tetapi pada saat yang sama_tcp.example.com
dan_udp.example.com
akan tetap Kosong Non-Terminal karena tidak pernah digunakan sebagai catatanwhatever._domainkey.example.com
, tetapi jelas_domainkey.example.com
dengan sendirinya tidak akan pernah digunakan, sehingga akan tetap menjadi non-terminal kosong. Ini adalah sama untukTLSA
catatan dalam DANE (ex:_25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==
), atauURI
catatan (ex:_ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public"
)Perilaku server nama dan pembuatan balasan perantara
Mengapa server nama mensintesis secara otomatis jawaban perantara tersebut? Algoritma resolusi inti untuk DNS, sebagaimana dirinci dalam RFC 1034 bagian 4.3.2 adalah alasan untuk itu, mari kita ambil dan merangkum dalam kasus kami ketika menanyakan nameserver otoritatif di atas untuk nama
intermediate.example.com
(ini adalahQNAME
protokol di bawah):example.com
Server nama menemukan zona sebagai leluhur QNAME terdekat, jadi kita bisa pergi ke langkah 3.Kami sekarang memiliki ini:
Kami dapat menghilangkan kasus b dan c, karena zonefile kami tidak memiliki delegasi (maka tidak akan pernah ada referensi ke server nama lain, tidak ada kasus b), atau wildcard (jadi tidak ada kasus c).
Kami hanya harus berurusan dengan kasus a.
Kami mulai mencocokkan, label dengan label, di zona. Jadi, bahkan jika kami memiliki
sub.sub.sub.sub.sub.sub.sub.sub.example.com
nama panjang , pada titik tertentu, kami tiba di kasus a: kami tidak menemukan rujukan, atau wildcard, tetapi kami berakhir pada nama akhir yang kami inginkan hasilnya.Kemudian kami menerapkan seluruh isi kasing a:
Bukan kasus kami, kami lewati itu.
Apapun QTYPE kita pilih (
A
,AAAA
,NS
, dll) kita tidak memiliki RRS untukintermediate.example.com
seperti itu tidak muncul dalam zonefile tersebut. Jadi salinan di sini kosong. Sekarang kita selesai pada langkah 6:Tidak relevan bagi kami di sini, maka kami selesai dengan sukses.
Ini persis menjelaskan perilaku yang diamati: permintaan seperti itu akan kembali
NOERROR
tetapi tidak ada data juga.Sekarang, Anda mungkin bertanya pada diri sendiri: "tetapi kemudian jika saya menggunakan nama apa pun, seperti
another.example.com
dengan algoritma di atas saya harus mendapatkan jawaban yang sama (tidak ada kesalahan)", tetapi pengamatan akan melaporkanNXDOMAIN
dalam kasus itu.Mengapa?
Karena keseluruhan algoritma seperti yang dijelaskan, dimulai dengan ini:
Ini berarti bahwa zonefile di atas ditransformasikan menjadi pohon ini:
Jadi ketika mengikuti algoritme, dari atas, Anda memang bisa menemukan jalur:
com > example > intermediate
(karena jalurnyacom > example > intermediate > leaf
ada) Tetapi untukanother.example.com
, setelahcom > example
Anda tidak menemukananother
label di pohon, sebagai simpul anak-anakexample
. Karenanya kita masuk ke dalam bagian pilihan c dari atas:Label
*
tidak ada, dan kami tidak mengikutiCNAME
, maka kami ada dalam kasusset an authoritative name error in the response and exit
:, aliasNXDOMAIN
.Perhatikan bahwa semua hal di atas memang menciptakan kebingungan di masa lalu. Ini dikumpulkan di beberapa RFC. Lihat misalnya tempat tak terduga ini (kegembiraan spesifikasi DNS yang begitu sulit ditembus) mendefinisikan wildcard: RFC 4592 "Peran Wildcard dalam Sistem Nama Domain" dan terutama bagian 2.2 "Aturan Keberadaan", juga dikutip sebagian pada awal jawaban saya tapi ini lebih lengkap:
Dan kemudian definisi di bagian selanjutnya adalah paragraf yang saya kutip di awal.
Perhatikan bahwa RFC 8020 (pada
NXDOMAIN
benar-benar berartiNXDOMAIN
, yaitu jika Anda membalasNXDOMAIN
untukintermediate.example.com
, makaleaf.intermediate.example.com
tidak bisa ada) diberi mandat sebagian karena berbagai penyedia DNS tidak mengikuti penafsiran ini dan itu menciptakan kekacauan, atau mereka hanya bug, lihat misalnya yang satu ini diperbaiki pada 2013 dalam satu kode nameserver otoritatif opensource: https://github.com/PowerDNS/pdns/issues/127Orang-orang perlu kemudian melakukan langkah-langkah balasan khusus hanya untuk mereka: itu bukan caching agresif
NXDOMAIN
karena bagi penyedia tersebut jika Anda mendapatkanNXDOMAIN
pada beberapa node, itu mungkin masih berarti Anda mendapatkan sesuatu yang lain daripadaNXDOMAIN
pada node lain di bawahnya.Dan ini membuat minimisasi QNAME (RFC 7816) tidak mungkin diperoleh (lihat https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdf untuk detail lebih lanjut) , sementara itu ingin meningkatkan privasi. Keberadaan non-terminal kosong dalam kasus DNSSEC juga menciptakan masalah di masa lalu, sekitar penanganan non-keberadaan (lihat https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647 /AFNIC_OARC_Dallas.pdf jika tertarik, tetapi Anda benar-benar membutuhkan pemahaman yang baik tentang DNSSEC sebelumnya).
Dua pesan berikut ini memberikan contoh masalah yang harus dilakukan oleh satu penyedia untuk dapat menegakkan aturan ini dengan benar pada Non-Terminal Kosong, memberikan beberapa perspektif tentang masalah dan mengapa kami ada di mana:
sumber
Mungkin saja saya salah paham jawaban Khaled, tetapi tidak adanya catatan menengah seharusnya tidak menjadi masalah dengan resolusi nama subzon. Perhatikan bahwa output penggalian ini bukan dari, atau diarahkan ke, server DNS resmi untuk
teaparty.net
atau subzonanya:Memang, Anda harus dapat melakukannya
dig
sendiri, dan mendapatkan jawaban itu -teaparty.net
adalah domain nyata, di bawah kendali saya, dan benar-benar berisiA
catatan itu. Anda dapat memverifikasi bahwa tidak ada catatan untuk zona mana pun di antaravery
danteaparty.net
, dan bahwa itu tidak berdampak pada resolusi nama host di atas.sumber
teaparty.net
catatan dalam satu zonefile sehingga catatan kosong disintesis untuk domain perantara. Adakah yang bisa menjelaskan apa yang akan terjadi jikaparents.teaparty.net
delegasi dan hanyavery.deep.host.with.no.immediate
memiliki catatan dalam delegasi zonefile?teaparty.net
adalah subdomain yang didelegasikan darinet
; jika satu-satunya catatan A di zonefile ituvery.deep...
kalau itu tidak masalah.Jika Anda secara langsung menanyakan server DNS resmi, Anda akan mendapatkan jawaban tanpa masalah.
Namun, Anda tidak akan mendapatkan jawaban yang valid jika Anda meminta melalui server DNS lain yang tidak memiliki cache yang valid. Permintaan
intermediate.example.com
akan menghasilkanNXDOMAIN
kesalahan.sumber
NXDOMAIN
, itu harus menghasilkanNOERROR
kode dan bagian Jawaban kosong.intermediate.example.com
jika itu tidak digunakan untuk apa pun. Jadi, bahkan jika itu mengembalikan kesalahan (tidak), apa bedanya?NXDOMAIN
, Anda dapatkanNOERROR
. Itulah respons untuk simpul yang ada dalam hierarki DNS, tetapi tidak memiliki catatan dari jenis yang diminta.NS
catatan, tetapi Anda memintaA
catatan, Anda akan mendapatkanNOERROR
respons kosong.NXDOMAIN
untukintermediate.example.com
maka itu berarti tidak ada "di bawah" dan kemudianleaf.intermediate.example.com
TIDAK ada. Beberapa resolver rekursif agresif bahkan dapat men-cache itu dan mengurangi hal-hal sendiri.Untuk langsung menjawab pertanyaan, tidak, Anda tidak perlu menambahkan catatan untuk nama perantara yang sebenarnya tidak Anda gunakan, namun itu tidak berarti bahwa nama-nama itu tidak ada.
Mengenai apakah nama-nama ini ada atau tidak, itu sebenarnya adalah pertanyaan terpisah yang saya harap dapat memberikan jawaban singkat dan agak intuitif.
Itu semua bermuara pada DNS yang merupakan struktur pohon, di mana setiap label dalam nama domain adalah simpul pohon. Misalnya
www.example.com.
memiliki labelwww
,example
,com
dan `` (root node), yang merupakan node pohon yang membentuk jalur sepanjang jalan ke akar.Apa yang mungkin membuat sifat dasar DNS ini tidak jelas adalah bahwa hampir selalu ketika mengelola data DNS tidak ada pohon untuk dilihat dan kami umumnya tidak bekerja secara langsung dengan node pohon itu sendiri, sebagai gantinya kami biasanya memiliki daftar catatan apa yang rata. data yang harus ada pada nama domain yang berbeda (jalur pohon yang efektif, seperti di atas).
Apa yang terjadi ketika daftar ini digunakan adalah bahwa perangkat lunak server DNS membangun pohon berdasarkan catatan yang ada, dan jika ada kesenjangan antara node yang memiliki catatan (misalnya ada catatan untuk
foo.bar.example.com.
danexample.com.
tetapi tidakbar.example.com.
) ini hanya dianggap pohon kosong node. Artinya, ini adalah nama domain / node yang memang ada, pohon tidak rusak, node ini hanya tidak memiliki data yang terkait dengannya.Akibatnya, jika Anda meminta salah satu dari node kosong ini, Anda akan mendapat
NODATA
respons (NOERROR
status +SOA
di bagian otoritas), dengan mengatakan bahwa tipe catatan yang diminta tidak ada pada node ini. Jika Anda meminta beberapa nama yang sebenarnya tidak ada, Anda akan mendapatNXDOMAIN
respons, dengan mengatakan bahwa nama domain yang diminta tidak ada di pohon.Sekarang, jika Anda ingin detail seluk beluk, baca jawaban Patrick Mevzek yang sangat menyeluruh.
sumber