Кратко

  • RFC 3123 определила APL RR для упорядоченного списка IPv4- и IPv6-префиксов с битом отрицания, но смысл пустого списка, нескольких RR, неизвестных семейств и ! должна была задавать отдельная спецификация приложения.
  • Корректная или аутентифицированная APL-запись подтверждала публикацию представления. Она не доказывала контроль префикса, полномочие policy, установку ACL, совпадение пакета или результат сервиса.

DNS получил формат, а не право приказывать

К 2001 году DNS давно переносил больше, чем соответствие имени и адреса. Resource Record model из RFC 1034 и RFC 1035 публиковал почтовые маршруты, name servers и другие инфраструктурные данные. RFC 1101 предлагала описание сетей организаций. Старые версии BIND даже использовали диапазоны в TXT как слабый способ ограничить доступ к данным зоны.

В таких практиках легко спутать два вопроса: как представить диапазон и что читатель обязан сделать. RFC 3123 их разделила. Документ вышел в июне 2001 года как Experimental и назначил APL тип 42. Элемент содержал семейство адресов, длину префикса, бит N, длину и значимые байты адреса. Семейство 1 означало IPv4, 2 — IPv6; один RR мог сочетать оба.

Но общего назначения список не получил. RFC прямо назвала APL framework без определённого смысла prefix list. Публикация диапазонов, описание classless reverse zone и материал для access control были лишь возможными сценариями со своими спецификациями. Примеры не стандартизировали приложения и не подтверждали deployment.

Имя, тип и payload показывали, где найдена декларация. Они не назначали principal, способный обязать оператора, не выбирали локальное правило и не подтверждали выполненное действие.

Восклицательный знак ещё не означал запрет

В zone file перед элементом допускался !, а wire format сохранял его наличие в N bit. Автоматически прочитать знак как «deny», «exclude» или «unauthorized» значило бы добавить политику. RFC потребовала, чтобы приложение отдельно определяло точную семантику отрицания.

Пустой RDATA был допустим и представлял пустой список. Но означал ли он «никого», «без ограничений», «нет мнения» или «наследовать» — запись не решала. RRset мог содержать несколько APL RR, а правило их объединения оставалось у приложения.

Приложение также называло ожидаемые address families и обработку других или неизвестных. Игнорировать элемент, отвергнуть весь RRset или сохранить для будущего читателя — разные решения. Parser, умеющий читать поля, не приобретал мандат на выбор.

Общая часть осталась минимальной и локально проверяемой. Будущая policy не была спрятана в punctuation и оставалась у участников, запускающих и принимающих код.

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

DNS server и resolver не должны были «улучшать» APL. Дубликаты разрешались и не сливались. Порядок сохранялся; перестановка и aggregation запрещались. Это кажется избыточным только если считать список математическим множеством. RFC не обещала этого: будущая application могла учитывать позицию или повтор.

Посредник обязан был доставить statement, не оптимизируя неизвестную policy. Объединение соседних префиксов или удаление второго элемента могло изменить priority или exception.

На уровне байтов действовала ограниченная canonicalization. Конечные нулевые octets без информации о префиксе не передавались. Эквивалентные IPv4/IPv6-префиксы получали единственную wire encoding, важную для упомянутой модели DNSSEC.

Canonical bytes определяют объект сравнения или подписи. Они не определяют, что подписанный объект разрешает. Детерминированное представление не создаёт полномочия.

Аутентичность защищала заявление, а не завершала решение

RFC 3123 советовала считать DNS-информацию небезопасной без указанных DNSSEC или TSIG. Она также предупреждала о раскрытии topology и риске построения access-control lists из APL.

DNSSEC помогает проверить origin и integrity подписанных данных. TSIG аутентифицирует сообщение или transaction между настроенными сторонами. Они не устанавливают, имел ли zone operator право управлять firewall, прочитало ли приложение текущую версию, завершилась ли compilation, привязана ли policy к правильному interface и прошёл ли packet через эту точку.

Операционная цепь требует отдельных receipts: owner name и время query, точный RRset, validation state, application contract и version, local config, compiled policy, enforcement acknowledgment и traffic observation. Переход от DNS-ответа сразу к outcome выдумывает control вместо publication.

Delegation и cache делали DNS дешёвым каналом распределения. Но distribution statement не распределяет decision authority. Zone publisher публикует; принимающий operator решает об adoption.

Тип 42 не считал внедрения

Примеры показывали диапазоны организации, reverse zone, AXFR restriction и multicast. Это иллюстрации синтаксиса под example names. Документ подчёркивал, что они не специфицируют application и не подразумевают её существование сейчас или в будущем.

Experimental — статус документа, а не receipt полевого испытания. RFC 3597 позже описала unknown RR types, но не измерила APL adoption. RFC 4034 уточнила DNSSEC records и canonical processing, не добавив списку универсальный смысл.

Источники подтверждают дизайн: компактный расширяемый container, сохраняющий family, prefix length, порядок, повтор и отрицание. История deployment, failure или success требует кода, zone corpus или измерений.

Сохранённая граница и была достижением

Общий формат решал только неизменную передачу. Application определяла name convention, empty list, multiple RR, families и negation. Operator выбирал adoption. Policy engine устанавливал. Packet встречал enforcement point или шёл другим путём.

Разделение не гарантировало успех, но позволяло локализовать ошибку. Аутентичный RR мог быть stale, правильная specification — неверно настроена, ACL — установлена на другом interface, положительный receipt — не относиться к реальному path.

Одинаковая строка префикса в DNS, модели, ACL и log не была одним фактом. Различались время, актор и полномочие.

RFC 3123 не сделала DNS сувереном сети. Она дала ему точный язык для prefix material и оставила решение вне record, где его требовалось доказать.

Источники

  1. https://www.rfc-editor.org/rfc/rfc3123.txt
  2. https://www.rfc-editor.org/info/rfc3123
  3. https://datatracker.ietf.org/doc/rfc3123/
  4. https://www.rfc-editor.org/rfc/rfc1034.txt
  5. https://www.rfc-editor.org/rfc/rfc1035.txt
  6. https://www.rfc-editor.org/rfc/rfc1101.txt
  7. https://www.rfc-editor.org/rfc/rfc2317.txt
  8. https://www.rfc-editor.org/rfc/rfc2535.txt
  9. https://www.rfc-editor.org/rfc/rfc2845.txt
  10. https://www.rfc-editor.org/rfc/rfc2874.txt
  11. https://www.rfc-editor.org/rfc/rfc3597.txt
  12. https://www.rfc-editor.org/rfc/rfc4034.txt