Кратко

  • RFC 1794 описывает дискуссию 1995 года о том, как менять порядок DNS-адресов вслед за нагрузкой серверов, не изменяя протокол.
  • Авторитетный сервер мог опубликовать предпочтение, но кэши, обновление вторичных серверов и локальная сортировка клиента не позволяли превратить его в обязательное назначение узла.

Упорядоченный ответ — ещё не подключение

Одно имя может указывать на несколько равноценных машин. Если одна свободнее, кажется логичным выдать её адрес первым. Но DNS передаёт записи, а не устанавливает соединение приложения. RFC 1794 выстраивает рассуждение вокруг этой границы: порядок может быть полезным и предсказуемым, однако протокол не гарантирует, что клиент его сохранит.

Документ опубликован в апреле 1995 года в категории Informational. В нём прямо сказано, что он не устанавливает стандарт Интернета. Автор хотел описать попытку обсуждения в рабочей группе DNS и рассматривавшиеся варианты; он также предупредил, что в истории могут быть пробелы. Это свидетельство инженерной дискуссии, а не статистика внедрения или эффективности.

От чередования адресов к измерению нагрузки

Автор относит первые изменения BIND, менявшие порядок адресных записей, примерно к 1986 году. Среди вероятно широко распространявшихся примеров он называет изменения Shuffle Address Брайана Бичера и код Round Robin Маршалла Роуза. И дата, и оценка распространённости — ретроспективное описание, а не независимый подсчёт.

Чередование меняло адрес, стоящий первым, но не измеряло реальную загрузку каждой машины. RFC 1794 противопоставляет ему изменения, приписываемые Мэтту Мэдисону из TGV: они использовали специфичные для VMS функции, проверяли нагрузку систем и упорядочивали A-записи от наименее загруженной к наиболее загруженной. Такой подход лучше учитывал состояние узлов, но зависел от конкретной операционной системы и требовал менять обработку записей. Простая ротация была переносимой, но не видела нагрузки; измерение давало больше контекста, но хуже обобщалось.

Совместимость перенесла динамику в другой этап

Критерии, перечисленные в RFC, включали обратную совместимость с существующей DNS, частое изменение данных, выдачу нескольких адресов, корректную работу с другими типами записей, поддержку разных определений нагрузки и быстрые вычисления. Пять минут считались обычным интервалом обновления; 60 секунд упоминались как возможный вариант, а не измеренный показатель. Несколько адресов должны были оставлять альтернативу, если предпочтительный узел отказывал до истечения TTL. Это не являлось гарантией переключения.

Изменение протокола или новый тип записей казались рискованными из-за уже установленного парка DNS. В RFC описано другое предложение Роба Остейна: сделать программу передачи зон интеллектуальнее. Она могла получить данные о нагрузке, переставить записи зоны и передать их серверу имён, не меняя формат DNS-сообщений. Путь запроса оставался привычным, а динамическим становился этап подготовки зоны.

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

Последний выбор оставался у клиента

RFC 1794 указывает, что DNS не гарантирует порядок записей в ответе. Автор называет его предсказуемым, но отмечает возможность локальной сортировки адресов клиентом, например с помощью sortlist. Программа передачи зон не могла предсказать такие удалённые решения. Выдача нескольких адресов также не доказывает, что клиент попробует каждый, что следующий сервер работоспособен или что запрос приложения завершится успешно.

Исторический вывод не в том, что DNS стал распределителем трафика, а в том, что границы управления были признаны явно. Оператор мог рассчитать и опубликовать предпочтительный порядок; вторичные серверы и кэши влияли на его распространение; клиент выбирал конечный адрес. RFC 1794 описывает подход внутри этих ограничений, но не показывает масштаб внедрения или его эксплуатационные результаты.

Источники