TL; DR: так, проміжні субдомени повинні існувати, принаймні за запитом, для визначення DNS; вони можуть не існувати в файлі зон.
Можлива плутанина, щоб усунути спочатку; Визначення "Порожній нетермінальний"
Ви можете заплутати дві речі, як, здається, і інші відповіді. А саме, що відбувається під час запиту імен та того, як ви налаштовуєте сервер імен та вміст файлу зони.
DNS є ієрархічним. Для існування будь-якого вузла аркушів ОБОВ'ЯЗКОВО існувати всі компоненти, що ведуть до нього, у тому сенсі, що якщо на них запитують, відповідальний авторитетний сервер імен повинен відповісти на них без помилок.
Як пояснено в RFC 8020 (це лише повторення того, що завжди було правилом, але лише деяким постачальникам DNS потрібне нагадування), якщо на будь-який запит відповідати авторитетний сервер імен NXDOMAIN (тобто цей запис ресурсів не існує), то це означає, що жодної мітки "внизу" цього ресурсу також не існує.
У вашому прикладі, якщо запит для intermediate.example.comповернення NXDOMAIN, то будь-які власні рекурсивний сервер імен будуть негайно відповідати NXDOMAINна leaf.intermediate.example.comтому , що цей запис не може існувати , якщо всі ярлики в ньому не існують в вигляді записів.
Про це вже було сказано раніше в RFC 4592 про символьні символи (які тут не пов'язані):
Простір доменних імен - це структура дерева. Вузли в дереві або
володіють принаймні одним RRSet та / або мають нащадків, які спільно володіють
принаймні одним RRSet. Вузол може існувати без RRSets, тільки якщо він має
нащадків; цей вузол є порожнім нетермінальним.
Вузол без нащадків - листовий вузол. Порожніх листових вузлів не існує.
Практичний приклад з .US доменними іменами
Візьмемо робочий приклад з TLD з великою кількістю міток історично, тобто .US. Вибираючи будь-який приклад в Інтернеті, давайте нам використовувати www.teh.k12.ca.us.
Звичайно, якщо ви запитаєте це ім’я, або навіть teh.k12.ca.usви можете отримати Aзаписи. Тут немає нічого переконливого для нашої мети (навіть посеред нього є CNAME, але нас це не хвилює):
$ 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
Давайте запитаємо зараз k12.ca.us(я не запитую авторитетного сервера імен, але це фактично не змінює результат):
$ 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
Що ми дізнаємось з цієї відповіді?
По-перше, це успіх, оскільки статус є NOERROR. Якби це було що-небудь інше, а конкретно NXDOMAINтоді teh.k12.ca.us, і не www.teh.k12.ca.usмогло б існувати.
По-друге, розділ ВІДПОВІСТЬ порожній. Немає Aзаписів для k12.ca.us. Це не помилка, цього типу ( A) не існує для цього запису, але, можливо, для цього запису існують інші типи записів, або цей запис є ENT, він називається "Порожній нетермінальний": він порожній, але це не лист, Є речі "нижче" це (див. визначення у RFC 7719 ), як ми вже знаємо (але зазвичай роздільна здатність знаходиться зверху вниз, тому ми досягнемо цього кроку, перш ніж піти на один рівень нижче, а не навпаки, як ми робимо тут для демонстрації призначення).
Ось чому насправді, як ярлик, ми кажемо, що код статусу такий NODATA: це не реальний код статусу, це просто означає NOERROR+ порожній розділ ВІДПОВІДЬ, що означає, що даних для цього конкретного типу запису немає, але можуть бути й інші.
Ви можете повторити той же експеримент для того ж результату, якщо будете запитувати з наступною міткою "вгору", тобто ім'ям ca.us.
Результати запитів та вміст зони файлів
Тепер звідки може виникнути плутанина? Я вважаю, що може виникнути помилкова думка, що будь-яка крапка в імені DNS означає, що є делегування. Це помилково. Сказано інакше, ваш example.comфайл ззони може бути таким, і він цілком дійсний і працює:
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
З таким зонним файлом, запитуючи цього сервера імен, ви отримаєте саме таку поведінку, яку спостерігали вище: запит на intermediate.example.comповернеться NOERRORз порожньою відповіддю. Вам не потрібно створювати його спеціально в файлі зони (якщо він вам не потрібен з інших причин), авторитетний сервер імен подбає про синтез "проміжних" відповідей, оскільки він бачить, що йому потрібен цей порожній нетермінальний (і будь-який інші "посеред", якщо були інші мітки), як він бачить назву аркуша leaf.intermediate.example.com.
Зауважте, що це поширений випадок насправді в деяких районах, але ви можете не бачити цього, оскільки він націлений на більше "інфраструктурних" записів, до яких люди не піддаються:
- в зворотних зонах , таких як
in-addr.arpабо ip6.arpa, а конкретно останнього. Ви матимете записи на зразок, 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.і очевидно, що на кожній точці немає делегування, а також записів ресурсів, що додаються
- в
SRVзапису, як _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., домен може мати багато _proto._tcp.example.comі _proto._udp.example.com SRVзаписи , тому що дизайн вони повинні мати таку форму, але в той же час _tcp.example.comі _udp.example.comбуде залишатися порожніми нетермінали , тому що ніколи не використовується в якості записів
- у вас фактично багато інших випадків конкретної побудови імен на основі "підкреслювальних міток" для різних протоколів, таких як DKIM. DKIM зобов’язує вас мати такі записи DNS
whatever._domainkey.example.com, але, очевидно _domainkey.example.com, самі по собі ніколи не будуть використовуватися, тому він залишатиметься порожнім нетермінальним. Це те ж саме для TLSAзаписів в DANE (наприклад: _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==) або URIзаписи (наприклад: _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public")
Поведінка сервера імен та створення проміжних відповідей
Чому сервер імен автоматично синтезує такі проміжні відповіді? Алгоритм роздільної здатності ядра для DNS, детально описаний у розділі 4.3.2 RFC 1034, є причиною цього, давайте візьмемо його та узагальнимо у нашому випадку, коли запитуємо вищезазначений авторитетний сервер імен для цього імені intermediate.example.com(це QNAMEв протоколі нижче):
- Шукайте доступні зони для зони, яка є найближчим предком до QNAME. Якщо така зона знайдена, перейдіть до кроку 3, інакше - крок 4.
Сервер імен знаходить зону example.comяк найближчого предка QNAME, тому ми можемо перейти до кроку 3.
Зараз у нас це:
- Почніть відповідати вниз, етикеткою за міткою, в зоні. [..]
а. Якщо весь QNAME збігається, ми знайшли вузол. [..]
б. Якщо відповідність нас виведе з авторитетних даних, у нас є реферал. Це трапляється, коли ми стикаємося з вузлом з NS RR, що позначає надрізи внизу зони. [..]
c. Якщо на якійсь мітці збіг неможливий (тобто відповідна мітка не існує), подивіться, чи існує мітка "*". [..]
Ми можемо усунути випадки b і c, тому що в нашому зонному файлі немає делегування (отже, ніколи не буде звернення до інших серверів імен, жодного випадку b), ні макіяжів (так що немає випадку c).
Ми маємо мати справу лише із справою a.
Ми починаємо узгоджувати вниз, етикетку за міткою, в зоні. Тож навіть якщо ми мали довге sub.sub.sub.sub.sub.sub.sub.sub.example.comім'я, в якийсь момент ми дістаємося до випадку a: ми не знайшли ні реферала, ні макіяжу, але ми опинилися під кінцевим ім'ям, для якого хотіли результату.
Тоді ми застосовуємо решту вмісту справи a:
Якщо даними на вузлі є CNAME
Не наш випадок, ми пропускаємо це.
В іншому випадку скопіюйте всі RR, які відповідають QTYPE, у розділ відповідей та перейдіть до кроку 6.
Незалежно від QTYPE ми вибираємо ( A, AAAA, NSі т.д.) , ми не маємо для запису ресурсів , intermediate.example.comоскільки він не з'являється в zonefile. Тож копія тут порожня. Тепер ми закінчимо на кроці 6:
Скористайтеся лише локальними даними, спробуйте додати інші RR, які можуть бути корисні до додаткового розділу запиту. Вхід.
Для нас це не актуально, тому ми закінчуємо успіх.
Це саме пояснює спостережувану поведінку: такі запити не повертаються, NOERRORале даних також немає.
Тепер ви можете запитати себе: "але тоді, якщо я буду використовувати якесь ім'я, як, наприклад, another.example.comза вищенаведеним алгоритмом, я повинен отримати таку ж відповідь (без помилок)", але спостереження замість цього звітуватимуть NXDOMAINу цьому випадку.
Чому?
Тому що весь алгоритм, як пояснено, починається з цього:
Наступний алгоритм передбачає, що RR розташовані в декількох структурах дерева, одна для кожної зони, а інша для кешу
Це означає, що вищезазначений зональний файл перетворюється на це дерево:
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
Отже, слідуючи алгоритму, зверху ви дійсно можете знайти шлях: com > example > intermediate(тому що шлях com > example > intermediate > leafіснує) Але для another.example.com, після того, як com > exampleви не знайдете anotherмітку на дереві, як діти, вузол example. Отже, ми потрапляємо до частини вибору c зверху:
Якщо мітка "*" не існує, перевірте, чи є ім'я, яке ми шукаємо, оригінальне QNAME у запиті чи ім'я, яке ми дотримувались через CNAME. Якщо ім'я оригінальне, встановіть авторитетну помилку імені у відповіді та виході. Інакше просто вийдіть.
Мітки *не існує, і ми не слідували за a CNAME, отже, ми знаходимося у випадку: set an authoritative name error in the response and exitaka NXDOMAIN.
Зауважимо, що все вище сказане створювало плутанину в минулому. Це зібрано в деяких RFC. Дивіться, наприклад, це несподіване місце (радість, що специфікації DNS є настільки непроникними), що визначає підстановку: RFC 4592 "Роль відмітних знаків у системі доменних імен", а саме розділ 2.2 "Правила існування", також цитований частково на початку моя відповідь, але ось вона більш повна:
Порожні нетермінали [RFC2136, розділ 7.16] - це доменні імена, у яких немає записів ресурсів, але вони мають піддомени. У розділі 2.2.1
"_tcp.host1.example." є прикладом порожнього нетермінального імені.
Порожні нетермінали вводяться цим текстом у розділі 3.1 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.
В дужках "який може бути порожнім" вказується, що порожні
нетермінали явно розпізнаються і що порожні нетермінали
"існують".
Педантичне читання вищевказаного абзацу може призвести до
трактування того, що існують усі можливі домени - до запропонованого
обмеження в 255 октетів для доменного імені [RFC1035]. Наприклад,
www.example. може мати A RR, і, що стосується практично
, це лист дерева домену. Але це визначення може
означати, що цей підрозділ www.example. Також існує, хоча і не має даних. За розширенням існують усі можливі домени - від кореня донизу.
Оскільки RFC 1034 також визначає "авторитетну помилку імені, що вказує на те, що ім'я не існує" в розділі 4.3.1, то, мабуть, це не є метою вихідного визначення, що виправдовує необхідність оновленого визначення в наступному розділі.
І тоді визначення в наступному розділі - це абзац, який я цитував на початку.
Зауважте, що RFC 8020 ( NXDOMAINнасправді це означає NXDOMAIN, що якщо ви відповідаєте NXDOMAINза intermediate.example.com, то leaf.intermediate.example.comне може існувати), це було частково доручено, тому що різні постачальники DNS не дотримувалися цієї інтерпретації, і це створювало хаос, або вони були просто помилками, див. зафіксовано у 2013 році в одному авторитетному коді сервера імен: https://github.com/PowerDNS/pdns/isissue/127
Тоді людям потрібно було поставити конкретні заходи боротьби саме для них: це не є агресивним кешуванням, NXDOMAINоскільки для тих провайдерів, якщо ви потрапляєте NXDOMAINна якийсь вузол, це все ще може означати, що ви отримуєте щось інше, ніж NXDOMAINна іншому вузлі під ним.
І це унеможливило мінімізацію QNAME (RFC 7816) (детальніше див. Https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdf ) , хоча хотілося збільшити конфіденційність. Наявність порожніх нетерміналів у випадку DNSSEC також створювала проблеми в минулому, навколо вирішення питання про відсутність існування (див. Https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647 /AFNIC_OARC_Dallas.pdf, якщо ви зацікавлені, але вам дійсно потрібно добре розуміти DNSSEC раніше).
Наступні два повідомлення дають приклад проблем, яким один постачальник повинен був вміти належним чином застосовувати це правило на Порожніх нетерміналах, він дає певну перспективу проблем, і чому ми там, де є: