RFC: 3403
Оригинал: Dynamic Delegation Discovery System - Part Three: The Domain Name System (DNS) Database
Предыдущие версии: RFC 2168, RFC 2915
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 3403, Страница 2 из 10

3. Спецификация Базы данных DDDS

  • General Description — общее описание
  • Эта база данных использует систему DNS, описанную в [8] и [7].

    Набором символов, используемых для задания различных значений записей NAPTR является UTF-8 [17]. Следует соблюдать осторожность в тех случаях, когда ввод или вывод выражений для замены содержит коды, выходящие за пределы эквивалентности ASCII/Unicode в UTF-8 — любые символы UTF-8 интерпретируются как последовательности кодовых точек (code-point), а не байтов. Это сделано для поддержки других языков в расширенных регулярных выражениях POSIX, чтобы обеспечить возможность соответствия предназначенным кодовым точкам. Недопустимо писать выражения для замены так, чтобы они зависели от локальных установок POSIX, поскольку это приведет к потере выражениями для замены их универсальности в применении.

    Все записи о ресурсах DNS имеют связанное с ними значение времени жизни TTL. По истечении с момента отыскания записи соответствующего числа секунд корректность записи теряется м нужно сделать новый запрос для получения новых записей. Таким образом, как указано в Алгоритме DDDS, могут возникать ситуации, когда срок действия данного Правила истекает. В тех случаях, когда приложение пытается вернуться к ранее найденным наборам Правил (в случае неподходящего пути передачи полномочий или при отказе сервера) приложение должно обеспечить гарантию того, что ни одна из записей, к которым происходит возврат, не перестала быть корректной по времени жизни. Если истек срок действия хотя бы одной записи приложение должно вернуть процесс на первый шаг алгоритма.

  • Key Format — формат ключей
  • Ключ представляет собой корректно сформированное доменное имя DNS.
  • Lookup Request — поисковый запрос
  • Чтобы запросить набор правил для данного Ключа, клиент вводит запрос, соответствующий стандартным правилам DNS, для записис NAPTR RR, соответствующей данному доменному имени.
  • Lookup Response — отклик при поиске
  • Отклик на запрос для данного Ключа (доменное имя) будет серией записей NAPTR. Формат записи NAPTR описан в главе 4.
  • Rule Insertion Procedure — процедура вставки правил
  • Правила вставляются путем добавления новых записей в соответствующую зону DNS. Если Правило производит Ключ, который существует в конкретной зоне, тогда только объект, имеющий административный контроль над этой зоной, может задавать Правило, связанное с таким Ключом.
  • Collision Avoidance — предотвращение конфликтов
  • В том случае, когда два Приложения могут использовать эту Базу данных (на практике это случай использования базы приложениями ENUM и URI Resolution, описанный в параграфе 6.2), возможно возникновение конфликта между правилами, когда в домене появляются две записи NAPTR, применимые более, чем к одному Приложению. Существуют три способа предотвращения конфликтов.

    • Создание в домене новой зоны, которая содержит только записи NAPTR, которые подходят для Приложения. Например, все записи URI Resolution могут размещаться в зоне urires.example.com, а все записи ENUM — в зоне enum.example.com. В том случае, когда такое решение невозможно по причине отсутствия контроля над восходящим делегированием, следует использовать второй метод.

    • Создание регулярного выражения, содержащего часть строки AUS, достаточную для однозначной идентификации приложения. Например, URI Resolution может использовать имя схемы слева для привязки регулярного выражения к соответствию этой схеме. Связанные с ENUM записи в той же зоне могут привязываться слева к соответствию символу "+", который определен в ENUM как начало каждой строки AUS. В результате данной строке AUS может соответствовать лишь одна из записей, а не две.

    • Если два приложения используют различные значения Flags или Services, тогда записи другого Приложения можно игнорировать, поскольку они не будут соответствовать значению Services/Flags.

2007 - 2018 © Русские переводы RFC, IETF, ISOC.