Кратко

  • RFC 3403 хранил правила DDDS в NAPTR, но физическое место записи в ответе не задавало исполнение. Клиент сортировал по ORDER, применяя PREFERENCE только внутри одного уровня.
  • После совпадения нельзя было перейти к другому ORDER из-за знакомой услуги. Additional, DNSSEC и успех конечного сервиса оставались разными доказательствами.

Ответ DNS показывается строками, поэтому первая выглядит главной. RFC 3403 отверг эту видимость: NAPTR возвращал множество кандидатов, а нормативный порядок находился внутри записей.

Документ потока стандартов вышел в октябре 2002 года и определил DNS как базу правил DDDS. Ключом было доменное имя, запрос возвращал NAPTR типа 35. RFC заменил 2915 и 2168 как официальная спецификация.

ORDER восстанавливал делегирование от меньшего значения к большему. Записи с одинаковым ORDER считались одним правилом по полномочиям. После совпадения клиент не мог рассматривать иной ORDER, кроме явного исключения сложного выбора услуг.

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

PREFERENCE упорядочивал альтернативы только при равном ORDER. Как Priority, он позволял менее предпочтительный вариант при слабой поддержке протокола, но не переход между уровнями.

Это не была балансировка. Поле выражало качество среди равноправных правил. Для трафика существовали SRV и несколько A. Использование предпочтения как веса добавляло отсутствующий смысл.

Flags и Services определялись приложением, включая терминальные флаги. Узнать строку не означало понять прикладной контракт.

REGEXP и REPLACEMENT были взаимоисключающими формами. Первая применялась к исходной строке, вторая содержала полное доменное имя без сжатия. Заполнение обоих делало запись ошибочной.

Между зонным файлом и ответом действовало экранирование. Обратную косую черту часто писали дважды, чтобы клиент получил одну. Доказательство требовало обе формы.

Текст был UTF-8. Вне ASCII сопоставление шло по кодовым точкам, не байтам. Зависимость от POSIX locale запрещалась, иначе правило меняло смысл между клиентами.

Приложения DDDS могли столкнуться на одном имени. Их разделяли зонами, выражениями с прикладным якорем либо различимыми Flags и Services. Совместное имя не объединяло контракты.

Additional был оптимизацией. Сервер мог добавить A или SRV той же подлинности, но приложение обязано работать без них. Отсутствие требовало нового запроса, не отменяло NAPTR.

TTL обеспечивал временную целостность. Истечение одной использованной записи требовало начать сначала. Старая первая половина и новая вторая могли образовать путь, никогда не существовавший одновременно.

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

DNSSEC мог подтвердить данные NAPTR, но не безопасность выражения, сортировку, соответствие Services или работу сервиса. Документ отдельно запрещал без проверки передавать выражения среде, способной выполнить код.

IANA сохраняет NAPTR как тип 35 — факт координации. Errata 2868 со статусом Held for Document Update лишь убирает повтор this this в Services и не меняет обработку.

Операционный чек сохраняет ключ, RRset, DNSSEC, TTL, входную последовательность, группы ORDER, PREFERENCE, Flags, Services, корректность подстановки, UTF-8, формы зоны и сети, отказы, выбор, использованный Additional, следующий запрос и исход потребителя.

Минимальная начальная спецификация Lu Heng объясняет разделение: стандартизовать общее представление, оставить смысл приложениям. Приоритет работающего кода проверяет это перемешиванием RRset, удалением Additional, сменой locale и истечением TTL. Решение должно следовать полям полномочий.

Первая NAPTR в пакете была лишь первой увиденной. Первое правило определял ORDER.

Источники