Кратко

  • RFC 1480 различала делегированную ветвь, прямую A-регистрацию IP-машины и прямую MX-регистрацию машины без IP. Наличие имени под .US не показывало, какой из трёх механизмов стоял за ним.
  • Делегирование передавало управление назначенному менеджеру и сопровождалось обязанностями: равное обслуживание, техническая компетентность, точные данные, резервные серверы, служение сообществу и согласованная передача. Строка в базе родителя таких полномочий не создавала.

Одинаковый суффикс не означал одинаковую схему

RFC 1480, опубликованная в июне 1993 года, делила .US по штатам, населённым пунктам и функциональным ветвям K12, LIB, FED и GEN. Иерархия помогала сохранять уникальность и распределять растущую административную работу.

В разделе регистрации документ различал делегирование и прямое внесение в главную базу. Прямая запись относилась либо к машине с IP, либо к машине без IP. При делегировании организация получала ветвь и запускала для неё серверы.

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

A сообщала адрес, а не право выпускать имена

Для IP-хоста верхний администратор напрямую добавлял A. По RFC 1035 это 32-битный адрес Internet. Он ничего не говорит о праве владельца записи создавать подчинённые имена.

Такое право появлялось после отдельного согласия. RFC 1034 требовала найти подходящую родительскую зону и получить от неё согласие передать контроль. NS называла сервер, который должен быть авторитетным для начинающейся в этой точке зоны.

Родитель мог опубликовать A и продолжать сам редактировать запись. Делегированный менеджер редактировал свою зону. Положительный ответ DNS показывал текущие данные, но не всю административную цепочку.

MX оставляла границу за удобным адресом

RFC 1480 разрешала регистрировать машины мира UUCP. Некоторые были в одном переходе от Internet-хоста, другие — в нескольких. MX указывала на IP-машину, которая принимала их почту, и внешнему отправителю не приходилось знать внутренний маршрут.

RFC 1035 определяет exchange как хост, готовый обслуживать почту имени-владельца; RFC 974 описывает выбор обменника. Из этого не следует, что именованная машина стала IP-узлом.

Нужны были административное согласие посредника и техническая процедура. Его локальная таблица должна была знать путь к UUCP-машине; каждый промежуточный узел — следующий шаг. Администратор .US мог внести MX, но не мог согласиться за чужого оператора.

Запись MX, действующее согласие, дозвон, состояние очереди и получение сообщения — разные события. Единый формат адреса скрывал границу для пользователя, но не устранял её из эксплуатации.

Вместе с ветвью передавалась обязанность

Документ предлагал делегировать K12.TX.US, населённые пункты, библиотечные ветви и другие разделы: один центр не мог бесконечно обрабатывать все имена. Распределение масштаба означало распределение решений.

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

Работу можно было проверять: своевременные ответы, точная и устойчивая база, доступные по IP первичный и вторичный серверы. Разные физические места рекомендовались для защиты от общего локального отказа.

Два NS-имени не доказывают два независимых места. Авторитетный ответ не доказывает беспристрастность. Делегирование, качество работы и легитимность имеют разные источники.

Смена попечителя требовала следов обеих сторон

Передача trusteeship требовала сообщений от старой и новой организаций. Верхний уровень должен был увидеть взаимное согласие и понимание обязанностей новым менеджером. Мнения затронутых сторон дополняли картину.

Имя зоны могло не измениться, хотя менялись организация, серверы и контакты. Последний набор NS не восстанавливает даты согласия, признания, технического переключения и устойчивой работы.

RFC 1591 позже обобщила принцип: управление национальным доменом является общественной услугой, а менеджер действует как trustee страны и глобального Internet-сообщества. Это критерий, но не доказательство выполнения в конкретной зоне.

Географическая структура принадлежала своему времени

RFC 1480 заменила RFC 1386, вышедшую шестью месяцами раньше. Быстрая редакция показывает, что письменная схема менялась при росте. Она не является переписью делегированных ветвей.

Длинная географическая структура ставила управляемость выше желания каждого получить самый короткий «очевидный» адрес. RFC 920 и базовые документы DNS дали общий контекст; RFC 1480 зафиксировала конкретный американский план 1993 года.

Карточка RFC Editor считает документ Informational. В разделе безопасности прямо сказано, что эти вопросы не обсуждаются. Резервирование и обязанности менеджера не заменяют аутентификацию и авторизацию.

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

У имени должна сохраняться родословная

Для каждого owner следует отдельно хранить тип RR, публикующую зону, точку делегирования, менеджера, серверы и время наблюдения. Для почты добавляются согласие посредника, правила UUCP, попытка, очередь и квитанция. Для управления — выбор и документы передачи.

DNS сделал разные устройства и учреждения удобными под общей формой имени. Точная история не отменяет это достижение; она возвращает разделённые роли, когда от имени требуют больше, чем оно может засвидетельствовать.

Источники