TL; DR: да, промежуточные субдомены должны существовать, по крайней мере, при запросе, для определения DNS; они могут не существовать в файле зоны, хотя.
Возможная путаница, чтобы устранить в первую очередь; Определение термина "пустой нетерминал"
Вы можете путать две вещи, как и другие ответы. А именно, что происходит при запросе имен по сравнению с тем, как вы настраиваете ваш сервер имен и содержимое файла зоны.
DNS является иерархическим. Для существования любого конечного узла все компоненты, ведущие к нему, ДОЛЖНЫ существовать в том смысле, что, если к ним обращаются, ответственный полномочный сервер имен должен отвечать за них без ошибок.
Как объяснено в RFC 8020 (который является просто повторением того, что всегда было правилом, но только некоторые поставщики DNS нуждались в напоминании), если на любой запрос авторитетный сервер имен отвечает NXDOMAIN (то есть: эта запись ресурса не существует), тогда это означает, что любой метки «под» этим ресурсом тоже не существует.
В вашем примере, если запрос для intermediate.example.comвозвращения NXDOMAIN, то любые собственные рекурсивный сервер имен будут немедленно отвечать NXDOMAINна leaf.intermediate.example.comпотому , что эта запись не может существовать , если все ярлыки в нем не существуют в виде записей.
Об этом уже говорилось в RFC 4592 о подстановочных знаках (которые здесь не связаны):
Пространство доменных имен представляет собой древовидную структуру. Узлы в дереве либо
владеют хотя бы одним RRSet и / или имеют потомков, которые вместе владеют
хотя бы одним RRSet. Узел может существовать без RRSets, только если у него есть
потомки; этот узел является пустым нетерминалом.
Узел без потомков является листовым узлом. Пустых листовых узлов не существует.
Практический пример с доменными именами .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+ пустой раздел ОТВЕТ, что означает, что нет данных для этого конкретного типа записи, но могут быть и для других.
Вы можете повторить тот же эксперимент для того же результата, если запросите следующую метку «вверх», то есть имя 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, отмечающими разрезы вдоль нижней части зоны. [..]
с. Если для какой-либо метки совпадение невозможно (т. Е. Соответствующая метка не существует), посмотрите, существует ли метка "*". [..]
Мы можем исключить случаи b и c, потому что в нашем файле зоны нет делегирования (следовательно, никогда не будет ни обращения ни к другим серверам имен, ни к случаю b), ни к подстановочным знакам (так что нет дела с).
Мы должны иметь дело только с делом а.
Мы начинаем сопоставление вниз, метка за меткой, в зоне. Поэтому, даже если у нас было длинное sub.sub.sub.sub.sub.sub.sub.sub.example.comимя, в какой-то момент мы приходим к случаю 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. Если имя является оригинальным, установите в ответе достоверную ошибку имени и выйдите. В противном случае просто выйдите.
этикетка * не существует, и мы не следовали за CNAME, следовательно, мы в случае:, set an authoritative name error in the response and exitиначе 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 и, насколько это практически возможно
, является листом дерева доменов. Но определение может быть
взято, чтобы означать, что 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 на другом узле под ним.
И это делало невозможным получение минимизации 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, прежде чем).
В следующих двух сообщениях приведен пример проблем, которые один провайдер должен был уметь правильно применять в отношении этого правила для пустых нетерминалов, он дает некоторое представление о проблемах и причинах их возникновения: