☰

параметр сервера unbound.conf "private-domain" - доменное имя заканчивается на точку или нет?

tag-icon • tag-icon domain-name-system debian-stretch syntax unbound
параметр сервера unbound.conf "private-domain" - доменное имя заканчивается на точку или нет?

unbound.confиспользуется для настройкиНесвязанный, кэширующий DNS-резолвер.документацияв версии 1.6.8 говорится:

Server Options
    private-domain: <domain name>
        Allow this domain, and all its subdomains to contain private
        addresses. Give multiple times to allow multiple domain names
        to contain private addresses. Default is none.

Мы запускаем несвязанную версию 1.6.0 с Debian Stretch (страница руководства и цитируемая документация здесь не отличаются).

Мы протестировали следующие три варианта, разделенные

  • редактирование/etc/unbound/unbound.conf
  • проверкаunbound-checkconf
  • перезапускsystemctl restart unbound.service
  • мониторинг несвязанного файла журнала.

Вариант 1 (оканчивается точкой):

private-domain: domain.example.

Вариант 2 (без точки в конце):

private-domain: domain.example

Вариант 3 (в указанном порядке):

private-domain: "domain.example. domain.example"

Для всех трех вариантов unbound-checkconfвозвращается:

unbound-checkconf: no errors in /etc/unbound/unbound.conf

При варианте 3 в лог-файле находим:

debug: ignoring duplicate private-domain: domain.example.

Это имеет смысл, поскольку одной записи для одного и того же доменного имени должно быть достаточно, и это, по-видимому, подтверждает, что unbound одинаково обрабатывает оба способа написания доменных имен (с точкой и без нее).

Оба способа работают, но каков правильный синтаксис для определения частных доменных имен в unbound? Должны ли доменные имена заканчиваться точкой или нет? Полезна ли точка в конце или бессмысленна? Какие последствия может иметь ненужная или отсутствующая точка?

решение1

Это старый вопрос, но он все равно первым пришел мне на ум при поиске, так что, на мой взгляд, стоит попытаться на него ответить.

Итог: В этом контексте, как и в большинстве других, нет никакой практической разницы между domain.example(без конечного .) и domain.example.(с обучением .). Поэтому оба варианта верны.

Теперь длинный ответ. :) Этот ответ — и единственный другой комментарий здесь, от 2018 года — исходит из того, что говорится в спецификации, как и комментарий 2018 года к OP. Хотя могут быть семантические различия между RFC и тем, как Unbound использует доменные имена, это было бы отклонением от спецификации и, вероятно, считалось бы ошибкой.

RFC 1034 Раздел 3.1определяет основной синтаксис доменных имен следующим образом:

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

  • строка символов, представляющая полное доменное имя (часто называемый «абсолютным»). Например, «poneria.ISI.EDU».

  • строка символов, представляющая начальные метки доменного имени, которое является неполным и должно быть дополнено локальным программным обеспечением с использованием знаний локального домена(часто называемый «относительным»). Например, «poneria» используется в домене ISI.EDU.

Относительные имена берутся либо относительно известного источника, либо относительно списка доменов, используемого в качестве списка поиска.

Обратите внимание на последнее предложение: Если не определен «список доменов, используемых в качестве списка поиска», имена без конечной точки считаются относительно «известного источника» — т. е. корня иерархии имен. Для публичного DNS корень DNS соответствуеткорневая зона; иерархии частных имен редко отклоняются от этой конвенции.

Для практических целей это означает, что полное доменное имя (FQDN) без завершающего имени .почти всегда следует рассматривать относительно корня иерархии имен, что эквивалентно тому же «абсолютному» домену. Следовательно, domain.example== « domain.exampleотносительно корня» == domain.example..

Когда различные представления могут иметь последствия? Когда вы имеете дело сфрагментыдоменного имени вместо FQDN. В этом случае следует опустить точку и рассмотреть возможность использования точки в FQDN. Если вы запустите example.com.(обратите внимание на точку; корневой сервер отправляет *.example.comвам трафик) и хотите настроить east.example.com.как поддомен, east— это поддомен; east.— это домен верхнего уровня (TLD) .east.

Опять же: это то, что говорит спецификация. Проверьте документацию для инструмента, который вы настраиваете, как всегда. Есть также другие области спецификации, в частности, сжатие DNS, где вводятся некоторые дополнительные семантики. Вы можете игнорировать их, если вы буквально не анализируете или не генерируете сообщения в протоколе DNS-провода.

Надеюсь, это полностью отвечает на вопрос. Надеюсь, это будет кому-то полезно.

Связанный контент