Если у меня есть хозяева example.com и leaf.intermediate.example.com в записях DNS для example.com, но нет записей для intermediate.example.com само по себе, вызывает ли это проблемы в некоторых ситуациях или это по какой-то причине плохой стиль или этикет? У меня настроены такие веб-серверы, и все вроде работает нормально, но я просто хотел проверить, не хватает ли чего-то.
TL; DR: да, должны существовать промежуточные поддомены, по крайней мере, при запросе, согласно определению DNS; однако они могут не существовать в файле зоны.
Вы можете запутать две вещи, поскольку другие ответы, похоже, тоже. А именно, что происходит при запросе имен по сравнению с тем, как вы настраиваете свой сервер имен и содержимое файла зоны.
DNS является иерархическим. Для существования любого листового узла все компоненты, ведущие к нему, ДОЛЖНЫ существовать, в том смысле, что если они будут запрошены, ответственный полномочный сервер имен должен ответить за них без ошибок.
Как объяснено в RFC 8020 (что является просто повторением того, что всегда было правилом, но только некоторые поставщики DNS нуждались в напоминании), если для любого запроса авторитетный сервер имен отвечает NXDOMAIN (то есть: эта запись ресурса не существует), то это означает, что любая Ярлык "ниже" у этого ресурса тоже не существует.
В вашем примере, если запрос для intermediate.example.com возвращается NXDOMAIN, то любой правильный рекурсивный сервер имен немедленно ответит NXDOMAIN для leaf.intermediate.example.com потому что эта запись не может существовать, если все метки в ней не существуют как записи.
Об этом уже говорилось в прошлом в RFC 4592 о подстановочных знаках (которые здесь не связаны):
Пространство доменных имен представляет собой древовидную структуру. Узлы в дереве либо
владеют хотя бы одним RRSet и / или имеют потомков, которые совместно владеют
хотя бы один RRSet. Узел может существовать без RRSet, только если он имеет
потомки, которые делают; этот узел - пустой нетерминал.Узел без потомков - это листовой узел. Пустые листовые узлы не существуют.
Давайте возьмем рабочий пример из 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 + пустая секция ANSWER, что означает, что для этого типа записи нет данных, но могут быть данные для других.
Вы можете повторить тот же эксперимент для того же результата, если вы запросите следующую метку «вверх», то есть имя ca.us.
Итак, откуда может возникнуть путаница? Я считаю, что это может быть связано с каким-то ложным представлением о том, что любая точка в DNS-имени означает делегирование. Это неправда. Иначе говоря, ваш example.com zonefile может быть таким, и он полностью действителен и работает:
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 останутся пустыми нетерминалами, потому что никогда не использовались в качестве записей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, подробно описанный в RFC 1034, раздел 4.3.2 является причиной этого, давайте возьмем ее и подведем итоги в нашем случае, когда запрашиваем имя у вышеуказанного авторитетного сервера имен intermediate.example.com (это QNAME в протоколе ниже):
- Найдите в доступных зонах зону, которая является ближайшим предком QNAME. Если такая зона обнаружена, переходите к шагу 3, в противном случае - к шагу 4.
Сервер имен находит зону example.com как ближайший предок QNAME, поэтому мы можем перейти к шагу 3.
Теперь у нас есть это:
- Начните сопоставление вниз, ярлык за ярлыком, в зоне. [..]
а. Если все QNAME совпадает, мы нашли узел. [..]
б. Если совпадение лишит нас достоверных данных, у нас есть реферал. Это происходит, когда мы сталкиваемся с узлом с NS RR, отмечающим разрезы в нижней части зоны. [..]
c. Если для какой-либо метки совпадение невозможно (т.е. соответствующая метка не существует), посмотрите, существует ли метка «*». [..]
Мы можем исключить случаи b и c, потому что наш файл зоны не имеет делегирования (следовательно, никогда не будет ни ссылки на другие серверы имен, ни случая b), ни подстановочных знаков (поэтому нет случая c).
Здесь мы должны рассмотреть только случай а.
Мы начинаем сопоставление, ярлык за ярлыком, в зоне. Так что даже если бы мы долго sub.sub.sub.sub.sub.sub.sub.sub.example.com name, в какой-то момент мы приходим к случаю а: мы не нашли ни реферала, ни подстановочного знака, но мы остановились на конечном имени, для которого мы хотели получить результат.
Затем мы применяем остальное содержимое случая а:
Если данные на узле являются CNAME
Не наш случай, мы это пропускаем.
В противном случае скопируйте все записи, соответствующие QTYPE, в раздел ответов и перейдите к шагу 6.
Какой бы QTYPE мы ни выбрали (A, AAAA, NSи т. д.) у нас нет РП для 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 ты не находишь 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).
В следующих двух сообщениях приводятся примеры проблем, с которыми один провайдер должен был иметь возможность должным образом применять это правило к пустым нетерминальным устройствам, это дает некоторое представление о проблемах и о том, почему мы там оказались:
Возможно, я неправильно понял ответ Халеда, но отсутствие промежуточных записей ни в коем случае не должно быть проблемой с разрешением подзонированного имени. Обратите внимание, что этот вывод Digit не исходит и не направлен на полномочный DNS-сервер для teaparty.net или любая его подзона:
[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
Действительно, вы должны уметь это делать dig себя, и получите тот ответ - teaparty.net это настоящий домен, находящийся под моим контролем, и он действительно содержит A запись. Вы можете убедиться, что нет записей ни для одной из этих зон между very и teaparty.net, и что это не влияет на разрешение указанного выше имени хоста.
Если вы напрямую запрашиваете авторитетный DNS-сервер, вы получите ответы без проблем.
Однако вы не получите действительного ответа, если запрашиваете через другой DNS-сервер, у которого нет действующего кеша. Запрос на intermediate.example.com приведет к NXDOMAIN ошибка.
Чтобы напрямую ответить на вопрос, нет, вам не нужно добавлять записи для промежуточных имен, которые вы на самом деле не используете, однако это не означает, что эти имена не существуют.
Что касается того, существуют эти имена или нет, это на самом деле целый отдельный вопрос, на который я надеюсь дать краткий и довольно интуитивный ответ.
Все сводится к тому, что DNS представляет собой древовидную структуру, в которой каждая метка в доменном имени является узлом дерева. Например www.example.com. имеет ярлыки www, example, com и '' (корневой узел), которые представляют собой узлы дерева, образующие путь до корня.
Что, возможно, делает эту фундаментальную природу DNS неочевидной, так это то, что почти всегда при управлении данными DNS дерево не видно, и мы обычно не работаем напрямую с самими узлами дерева, вместо этого у нас обычно есть сплющенный список того, какая запись данные, которые должны существовать в разных доменных именах (фактически, в виде дерева, как указано выше).
Что происходит при использовании этого уплощенного списка, так это то, что программное обеспечение DNS-сервера строит дерево на основе существующих записей, и если есть промежутки между узлами, которые имеют записи (например, есть записи для foo.bar.example.com. и example.com. но нет bar.example.com.) они просто считаются пустыми узлами дерева. То есть это доменные имена / узлы, которые действительно существуют, дерево не сломано, с этими узлами просто не связаны никакие данные.
Следовательно, если вы запросите один из этих пустых узлов, вы получите NODATA ответ (NOERROR статус + SOA в разделе полномочий), говоря, что запрошенный тип записи не существует на этом узле. Если вы вместо этого запросите какое-то имя, которого на самом деле не существует, вы получите NXDOMAIN ответ о том, что запрошенное доменное имя не существует в дереве.
Теперь, если вам нужны мельчайшие подробности, прочитайте очень подробный ответ Патрика Мевзека.