Использование родительского домена для запроса DNS SRV для поддомена

Я пишу приложение для запроса записи DNS SRV, чтобы узнать внутреннюю службу для домена, полученную с адреса электронной почты. Правильно ли делать следующее.

  • Допустим, домен электронной почты - test.example.com.
  • Запрос SRV-записи _service._tcp.test.example.com
  • Запись SRV не возвращается
  • Теперь запросите SRV-запись _service._tcp.example.com
  • Возвращается запись. Следовательно, используйте эту запись для подключения

Правильно ли описанный выше подход? Предполагая, что это не так, существуют ли какие-либо RFC или стандарты, которые мешают приложению делать это?

Источник

1 ответ

Правильно ли описанный выше подход?

Нет это не так. Не стоит "лезть" в корень.

В RFC нет ничего, прямо указывающего вам не делать этого, и вы даже найдете некоторые спецификации, говорящие вам подняться к корню, см. CAA спецификации (но их пришлось менять в течение года из-за

В большинстве случаев такое восхождение создает больше проблем, чем решения, и все это происходит из «нахождения административных границ», что выглядит намного проще, чем то, что есть на самом деле.

Если мы вернемся к вашему примеру, вы скажете, что используйте _service._tcp.test.example.com а потом _service._tcp.example.com а затем, я полагаю, вы останетесь там, потому что вы «очевидно» знаете, что вам не следует идти в _service._tcp.com следующим шагом, потому что вы "знаете", что example.com а также com не находятся под одними и теми же административными границами, поэтому вам не следует переходить это ограничение.

Хорошо, да, в этом конкретном примере (и TLD) все кажется простым. Но представьте себе произвольное имя, скажем www.admin.santé.gouv.fr, как узнать, где перестать лазить?

Это трудная проблема в целом. Были предприняты попытки решить эту проблему (см. Рабочую группу IETF DBOUND), но они не увенчались успехом. У вас есть только два основных места, если вам нужно заниматься: либо найти делегирования (сокращения зоны) с помощью вызовов DNS (не все делегации являются новыми административными границами, но смена администрации должна означать делегирование; и, очевидно, что делегирование не обязательно в каждая точка, поэтому вы не можете найти все это, просто посмотрев на строку, вам нужно выполнить живые DNS-запросы) ИЛИ с помощью Mozilla Public Suffix List, который имеет множество недостатков.

По сути, это всего лишь повторение того, что вы можете прочитать в «§4. Границы зон невидимы для приложений» RFC5507, цитируя здесь основную часть:

Ложное предположение привело к подходу, называемому «восхождение по дереву», где запрос, не получивший положительного ответа (либо запрошенный RRSet отсутствовал, либо имя не существовало), повторяется путем многократного удаления крайней левой метки (подъем к корень), пока не будет достигнут корневой домен. Иногда в этих предложениях делается попытка избежать запроса корневого уровня или уровня TLD, но все же этот подход имеет серьезные недостатки:

[..]

o По причинам, аналогичным тем, которые изложены в RFC 1535 [RFC1535], запрос информации в домене, находящемся вне контроля предполагаемого объекта, может привести к неверным результатам, а также может поставить под угрозу безопасность. Определение точных границ политики невозможно без явного маркера, которого в настоящее время не существует. В лучшем случае программное обеспечение может обнаруживать границы зоны (например, путем поиска записей ресурсов SOA), но некоторые реестры TLD регистрируют имена, начиная со второго уровня (например, CO.UK), а во-вторых, существуют различные другие типы «реестра», домены третьего или другого уровня, которые нельзя идентифицировать как таковые без знания политики, внешней по отношению к DNS.

Обратите внимание на пример, приведенный для MX потому что наивный взгляд, вы применяете там тот же алгоритм, но, как сказано в RFC:

Повторюсь, граница зоны - это чисто граница, которая существует в DNS для административных целей, и приложениям следует проявлять осторожность, чтобы не сделать необоснованные выводы из границ зоны. Другой способ заявить об этом состоит в том, что DNS не поддерживает наследование, например, MX RRSet для TLD не будет действителен для любого поддомена этого конкретного TLD.

Есть разные примеры, когда люди пытались залезть на корень ... и создавали множество проблем:

Короче говоря, без твердого понимания DNS просьба не создавать ничего "лезущего" в корень. Обратите внимание, что RFC2782 дает "Правила использования" без необходимости лезть в корень.

Вы не объясняете полностью, почему думаете об этом. Предлагаю вам взглянуть на новейшие HTTPS/ SVCB Записи DNS (RFC еще не опубликованы, но код типа RR уже назначен IANA и уже используется Apple, Cloudflare и Google), поскольку они могут предоставлять аналогичные функции, установленные как SRV но может быть более актуальным для вашего варианта использования.

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