Должны ли существовать промежуточные поддомены?

TL; DR: да, должны существовать промежуточные поддомены, по крайней мере, при запросе, согласно определению DNS; однако они могут не существовать в файле зоны.

Возможная путаница, которую необходимо устранить в первую очередь; Определение «Пустой нетерминал»

Вы можете запутать две вещи, поскольку другие ответы, кажется, тоже делают. А именно, что происходит при запросе имен по сравнению с тем, как вы настраиваете свой сервер имен и содержимое файла зоны.

DNS является иерархическим. Для существования любого листового узла все компоненты, ведущие к нему, ДОЛЖНЫ существовать в том смысле, что, если они будут запрошены, ответственный полномочный сервер имен должен ответить за них без ошибок.

Как объяснено в RFC 8020 ] (это просто повторение того, что всегда было правилом, но только некоторые поставщики DNS нуждались в напоминании), если на какой-либо запрос авторитетный сервер имен отвечает NXDOMAIN (то есть: эта запись ресурса не существует), то это означает, что любая метка «ниже» этого ресурса также не существует.

В вашем примере, если запрос для intermediate.example.com возвращает NXDOMAIN , то любой правильный рекурсивный сервер имен немедленно ответит NXDOMAIN для листа . Intermediate.example.com , потому что эта запись не может существовать, если все метки в ней не существуют как записи.

Это уже было сказано в прошлом в RFC 4592 о подстановочных знаках (которые являются здесь не связаны):

Пространство доменных имен представляет собой древовидную структуру. Узлы в дереве либо
владеют хотя бы одним RRSet и / или имеют потомков, которые совместно владеют
хотя бы один RRSet. Узел может существовать без RRSet, только если он имеет
потомки, которые делают; этот узел является пустым нетерминальным.

Узел без потомков является листовым узлом. Пустые листовые узлы не Существуют.

Практический пример с доменными именами .US

Давайте возьмем рабочий пример из ДВУ с большим количеством меток исторически, то есть .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 + пустой раздел ANSWER, что означает, что нет данных для этого конкретного типа записи, но могут быть данные для других.

Вы можете повторить тот же эксперимент для того же результата, если запросите следующую метку «вверх», то есть имя 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.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1 час 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 останутся пустыми нетерминальными именами, потому что никогда не используются в качестве records
• на самом деле у вас есть много других случаев конкретного построения имен на основе «меток подчеркивания» для различных протоколов, таких как DKIM. DKIM требует, чтобы у вас были записи DNS, такие как something._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, подробно описанный в RFC 1034, раздел 4.3.2 , является причиной этого, давайте возьмем его и подведем итоги в нашем случае при запросе имени у вышеуказанного авторитетного сервера имен Intermediate.example.com (это QNAME в протоколе ниже):

2. Поиск доступных зон для зоны, которая является ближайшей предок QNAME. Если такая зона найдена, переходите к шагу 3, в противном случае - шаг 4.

Сервер имен находит зону example.com как ближайшего предка QNAME, поэтому мы можем перейти к шагу 3.

Теперь у нас есть следующее:

3. Начать сопоставление, обозначить по метке, в зоне. [..]

а. Если все QNAME совпадает, мы нашли узел. [..]

б. Если совпадение лишит нас достоверных данных, у нас есть реферал. Это происходит, когда мы сталкиваемся с узел с обозначением NS RR надрезов по дну зона. [..]

c. Если на какой-то метке совпадение невозможно (т.е. соответствующий ярлык не существует), посмотрите, есть ли метка «*» существует. [..]

Мы можем исключить случаи b и c, потому что наш файл зоны не имеет делегирования (следовательно, не будет ни ссылки на другие серверы имен, ни случая b), ни подстановочных знаков (поэтому нет случая c).

Здесь мы имеем дело только со случаем А.

Мы начинаем сопоставление, метка за меткой, в зоне. Таким образом, даже если у нас было длинное имя sub.sub.sub.sub.sub.sub.sub.example.com , в какой-то момент мы приходим к случаю а: мы не нашли реферала , ни подстановочный знак, но мы остановились на конечном имени, для которого хотели получить результат.

Затем мы применяем остальное содержимое случая a:

Если данные на узле являются CNAME

Не В нашем случае мы пропускаем это.

В противном случае скопируйте все записи RR, которые соответствуют QTYPE, в ответьте на раздел и перейдите к шагу 6. ​​

Какой бы QTYPE мы ни выбрали ( A , AAAA , NS и т. д.), у нас нет RR для ] intermediate.example.com , так как он не отображается в файле зоны. Итак, копия здесь пуста. Теперь мы заканчиваем на шаге 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 вы не найдете другую метку в дереве, как дочерний узел example . Следовательно, мы попадаем в часть варианта c сверху:

Если метка «*» не существует, проверьте, соответствует ли имя мы ищем исходный QNAME в запросе или имя, которое мы использовали из-за CNAME. Если имя является оригинальным, установите авторитетную ошибку имени в ответ и выход. В противном случае просто выйдите.

Метка * не существует, и мы не использовали CNAME , поэтому мы на случай: установили в ответе ошибку авторитетного имени и выйдите из , также известного как NXDOMAIN .

Обратите внимание, что все вышеперечисленное в прошлом создавало путаницу. Это собрано в некоторых RFC. См., Например, это неожиданное место (радость от того, что спецификации DNS столь непонятны), определяющие подстановочные знаки: RFC 4592 «Роль подстановочных знаков в системе доменных имен» и, в частности, его раздел 2.2 «Правила существования», также цитируемый частично в начале моего ответа, но здесь он более полный:

Пустые нетерминалы [RFC2136, раздел 7.16] - это доменные имена, которым принадлежит нет записей ресурсов, но есть субдомены, которые есть. В разделе 2.2.1,
"_tcp.host1.example." является примером пустого нетерминального имени.
Пустые нетерминалы вводятся этим текстом в разделе 3.1 RFC. 1034:

 # Пространство доменных имен представляет собой древовидную структуру.  Каждый узел и лист на
 # дерево соответствует набору ресурсов (который может быть пустым).  В
 # доменная система не делает различий между использованием
 # внутренние узлы и листья, и в этой заметке термин "узел" используется для обозначения
 # относятся к обоим.
 

Заключенное в скобки «который может быть пустым» указывает на то, что пустое не-
терминалы явно распознаются и что пустые нетерминалы
"существуют".

Педантичное прочтение вышеуказанного абзаца может привести к
интерпретация того, что все возможные домены существуют - вплоть до предложенного
ограничение в 255 октетов для доменного имени [RFC1035]. Например,
www.example. может иметь A RR, и насколько это практически
рассматриваемый, является листом доменного дерева. Но определение может быть
означает, что sub.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 / issues / 127

Людям нужно было принять специальные меры противодействия только для них: это не агрессивное кеширование NXDOMAIN , потому что для этих провайдеров, если вы получаете NXDOMAIN на каком-то узле, это может по-прежнему означать, что вы получаете что-то еще, кроме NXDOMAIN на другом узле под ним.

И это s делал невозможным минимизацию 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 / sizes / 403 / attachments / 378/647 / AFNIC_OARC_Dallas.pdf , если интересно, но вам действительно нужно хорошо разбираться в DNSSEC).

В следующих двух сообщениях приводятся примеры проблем: провайдер должен был иметь возможность должным образом применять это правило к пустым нетерминальным устройствам, это дает некоторое представление о проблемах и о том, почему мы там оказались:

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