Серверная опция unbound.conf "private-domain" - доменное имя, оканчивающееся точкой или нет?

unbound.conf используется для настройки Unbound, кэширующего преобразователя 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 (man-страница и цитируемая документация здесь не отличаются).

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

  • редактирование /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 имеет одинаковую обработку для обоих способов записи доменных имен (с / без точки).

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

Источник

1 ответ

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник
Другие вопросы по тегам