Apakah subdomain menengah perlu ada?

Jika saya memiliki host example.comdan leaf.intermediate.example.comdalam catatan DNS untuk example.com, tetapi tidak memiliki catatan untuk intermediate.example.comdirinya 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.

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.compengembalian NXDOMAIN, maka setiap nameserver rekursif yang tepat akan segera membalas NXDOMAINuntuk leaf.intermediate.example.comkarena 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):

Ruang nama domain adalah struktur pohon. Node dalam pohon
memiliki setidaknya satu RRSet dan / atau memiliki keturunan yang secara kolektif memiliki
setidaknya satu RRSet. Suatu simpul mungkin ada tanpa RRSets hanya jika memiliki
keturunan yang melakukannya; simpul ini adalah non-terminal kosong.

Sebuah simpul tanpa keturunan adalah simpul daun. Node daun kosong tidak ada.

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 gunakan www.teh.k12.ca.us.

Tentu saja jika Anda mencari nama ini, atau bahkan teh.k12.ca.usAnda bisa mendapatkan kembali Acatatan. Tidak ada yang konklusif di sini untuk tujuan kami (bahkan ada CNAME di tengahnya, tetapi kami tidak peduli tentang itu):

$ 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

Marilah kita kueri sekarang untuk k12.ca.us(Saya tidak meminta server nama otoritatif untuk itu, tapi itu sebenarnya tidak mengubah hasilnya):

$ 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

Apa yang kita pelajari dari jawaban ini?

Pertama, ini sukses karena statusnya NOERROR. Seandainya ada hal lain dan khusus NXDOMAINsaat itu teh.k12.ca.us, tidak www.teh.k12.ca.usakan ada.

Kedua, bagian JAWABAN kosong. Tidak ada Acatatan untuk k12.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 berarti NOERROR+ 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.comzonefile Anda bisa seperti itu, dan itu benar-benar valid dan berfungsi:

example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....

leaf.intermediate.example.com IN A 192.0.2.37

Dengan zonefile seperti itu, dengan menanyakan nameserver ini Anda akan mendapatkan persis perilaku yang diamati di atas: kueri untuk intermediate.example.comakan kembali NOERRORdengan 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 daun leaf.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:

• di zona terbalik seperti in-addr.arpatau ip6.arpa, dan khususnya yang terakhir. Anda akan memiliki catatan seperti 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.dan jelas tidak ada delegasi di setiap titik, atau catatan sumber daya yang terlampir di setiap label
• dalam SRVcatatan, seperti _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., domain dapat memiliki banyak _proto._tcp.example.comdan _proto._udp.example.com SRVcatatan karena dengan desain mereka harus memiliki formulir ini, tetapi pada saat yang sama _tcp.example.comdan _udp.example.comakan tetap Kosong Non-Terminal karena tidak pernah digunakan sebagai catatan
• Anda sebenarnya memiliki banyak kasus konstruksi nama tertentu berdasarkan "label garis bawah" untuk berbagai protokol seperti DKIM. DKIM mengamanatkan Anda untuk memiliki catatan DNS seperti whatever._domainkey.example.com, tetapi jelas _domainkey.example.comdengan sendirinya tidak akan pernah digunakan, sehingga akan tetap menjadi non-terminal kosong. Ini adalah sama untuk TLSAcatatan dalam DANE (ex: _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==), atau URIcatatan (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 adalah QNAMEprotokol di bawah):

2. Cari zona yang tersedia untuk zona yang merupakan leluhur terdekat dari QNAME. Jika zona seperti itu ditemukan, lanjutkan ke langkah 3, jika tidak, langkah 4.

example.comServer nama menemukan zona sebagai leluhur QNAME terdekat, jadi kita bisa pergi ke langkah 3.

Kami sekarang memiliki ini:

3. Mulailah mencocokkan, label dengan label, di zona. [..]

Sebuah. Jika seluruh QNAME cocok, kami telah menemukan simpulnya. [..]

b. Jika kecocokan akan membawa kami keluar dari data otoritatif, kami memiliki referensi. Ini terjadi ketika kita menemukan sebuah simpul dengan NS RR menandai pemotongan di sepanjang bagian bawah zona. [..]

c. Jika pada beberapa label, kecocokan tidak mungkin (yaitu, label yang sesuai tidak ada), lihat apakah label "*" ada. [..]

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

Jika data di node adalah CNAME

Bukan kasus kami, kami lewati itu.

Jika tidak, salin semua RR yang cocok dengan QTYPE ke bagian jawaban dan lanjutkan ke langkah 6.

Apapun QTYPE kita pilih ( A, AAAA, NS, dll) kita tidak memiliki RRS untuk intermediate.example.comseperti itu tidak muncul dalam zonefile tersebut. Jadi salinan di sini kosong. Sekarang kita selesai pada langkah 6:

Hanya menggunakan data lokal, coba tambahkan RR lain yang mungkin berguna untuk bagian tambahan dari kueri. Keluar.

Tidak relevan bagi kami di sini, maka kami selesai dengan sukses.

Ini persis menjelaskan perilaku yang diamati: permintaan seperti itu akan kembali NOERRORtetapi tidak ada data juga.

Sekarang, Anda mungkin bertanya pada diri sendiri: "tetapi kemudian jika saya menggunakan nama apa pun, seperti another.example.comdengan algoritma di atas saya harus mendapatkan jawaban yang sama (tidak ada kesalahan)", tetapi pengamatan akan melaporkan NXDOMAINdalam kasus itu.

Mengapa?

Karena keseluruhan algoritma seperti yang dijelaskan, dimulai dengan ini:

Algoritma berikut mengasumsikan bahwa RR diatur dalam beberapa struktur pohon, satu untuk setiap zona, dan satu lagi untuk cache

Ini berarti bahwa zonefile di atas ditransformasikan menjadi pohon ini:

+-----+
| com |  (just to show the delegation, does not exist in this nameserver)
+-----+
   |
   |
   |
+---------+
| example | SOA, NS records
+---------+
   |
   |
   |
+--------------+
| intermediate | no records
+--------------+
   |
   |
   |
+------+
| leaf | A record
+------+

Jadi ketika mengikuti algoritme, dari atas, Anda memang bisa menemukan jalur: com > example > intermediate(karena jalurnya com > example > intermediate > leafada) Tetapi untuk another.example.com, setelah com > exampleAnda tidak menemukan anotherlabel di pohon, sebagai simpul anak-anak example. Karenanya kita masuk ke dalam bagian pilihan c dari atas:

Jika label "*" tidak ada, periksa apakah nama yang kami cari adalah QNAME asli dalam kueri atau nama yang kami ikuti karena CNAME. Jika nama itu asli, atur kesalahan nama otoritatif dalam respons dan keluar. Kalau tidak keluar saja.

Label *tidak ada, dan kami tidak mengikuti CNAME, maka kami ada dalam kasus set an authoritative name error in the response and exit:, alias NXDOMAIN.

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:

Kosong non-terminal [RFC2136, bagian 7.16] adalah nama domain yang tidak memiliki catatan sumber daya tetapi memiliki subdomain yang melakukannya. Di bagian 2.2.1,
"_tcp.host1.example." adalah contoh dari nama non-terminal yang kosong.
Kosong non-terminal diperkenalkan oleh teks ini di bagian 3.1 dari RFC 1034:

# 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.

Tanda kurung "yang mungkin kosong" menentukan bahwa non-
terminal kosong secara eksplisit diakui dan bahwa non-terminal kosong
"ada".

Membaca paragraf di atas dengan pedas dapat menyebabkan
interpretasi bahwa semua domain yang mungkin ada - hingga
batas yang disarankan 255 oktet untuk nama domain [RFC1035]. Misalnya,
www.example. mungkin memiliki RR, dan sejauh yang praktis
, adalah daun dari pohon domain. Tetapi definisi tersebut dapat
diartikan sebagai sub.www.example. juga ada, meskipun tanpa data. Dengan ekstensi, semua domain yang mungkin ada, dari root ke bawah.

Karena RFC 1034 juga mendefinisikan "kesalahan nama resmi yang menunjukkan bahwa nama itu tidak ada" di bagian 4.3.1, jadi ini tampaknya bukan maksud dari definisi asli, membenarkan kebutuhan untuk definisi yang diperbarui di bagian berikutnya.

Dan kemudian definisi di bagian selanjutnya adalah paragraf yang saya kutip di awal.

Perhatikan bahwa RFC 8020 (pada NXDOMAINbenar-benar berarti NXDOMAIN, yaitu jika Anda membalas NXDOMAINuntuk intermediate.example.com, maka leaf.intermediate.example.comtidak 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/127

Orang-orang perlu kemudian melakukan langkah-langkah balasan khusus hanya untuk mereka: itu bukan caching agresif NXDOMAINkarena bagi penyedia tersebut jika Anda mendapatkan NXDOMAINpada beberapa node, itu mungkin masih berarti Anda mendapatkan sesuatu yang lain daripada NXDOMAINpada 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:

• https://mailarchive.ietf.org/arch/msg/dnsop/XIX16DCe2ln3ZnZai723v32ZIjE
• https://lists.dns-oarc.net/pipermail/dns-operations/2019-April/018640.html

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.netatau subzonanya:

[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

Memang, Anda harus dapat melakukannya digsendiri, dan mendapatkan jawaban itu - teaparty.netadalah domain nyata, di bawah kendali saya, dan benar-benar berisi Acatatan itu. Anda dapat memverifikasi bahwa tidak ada catatan untuk zona mana pun di antara verydan teaparty.net, dan bahwa itu tidak berdampak pada resolusi nama host di atas.

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.comakan menghasilkan NXDOMAINkesalahan.

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. Misalnyawww.example.com. memiliki label www, example, comdan `` (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.dan example.com.tetapi tidak bar.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 NODATArespons (NOERROR status + SOAdi 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 mendapat NXDOMAINrespons, 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.