Я хочу изучить технические подробности обнаруженной мной причуды.
У меня есть авторитетный DNS-сервер, выполняющий балансировку нагрузки глобальных служб. Он отвечает несколькими IP-адресами в порядке предпочтения, основанном на его алгоритмах балансировки нагрузки. Так, например, если все службы исправны, но x.y.z.3 загружен меньше всего, ответ может выглядеть так:
x.y.z.3
x.y.z.1
x.y.z.2
Однако я обнаружил, что если пользователь использует DNS Google (8.8.8.8), он получает ответ точно так же, как указано выше. Тем не менее, OpenDNS, похоже, продолжает циклический перебор этих ответов.
Другими словами, пользователь, использующий 8.8.8.8 в качестве DNS-сервера, всегда будет получать такой ответ:
x.y.z.3
x.y.z.1
x.y.z.2
Но пользователь, использующий OpenDNS, мог видеть их в любом порядке.
Я могу немедленно решить эту проблему, вернув только x.y.z.3, но хочу знать:
На ваши прямые вопросы немного сложно ответить, поскольку они основаны на предположениях, которые частично не совпадают с тем, как работает DNS.
Записи ресурсов, существующие для данной комбинации имени, класса и типа, образуют набор записей ресурсов (обычно называют RRSet).
Как следует из этого термина (особенно это устанавливать) порядок, в котором перечислены записи, не имеет значения для системы.
Я считаю, что первое место, где указывается на отсутствие порядка, - это RFC1033:
Система домена не гарантирует сохранения порядка записей ресурсов. Размещение RR (например, нескольких адресных записей) в определенном порядке не гарантирует, что они будут использоваться в этом порядке.
Обладая этим знанием, уже ясно, что иметь ожидания в отношении заказа означает полагаться на поведение, которое изначально не было гарантировано.
Далее, распространенный вариант использования наборов записей с несколькими адресными записями (A/AAAA) был грубым средством балансировки нагрузки в DNS.
Чтобы помочь этому работать немного лучше, многие кэширующие преобразователи будут переупорядочивать записи с каждым ответом (будь то циклический или просто случайный порядок), чтобы помочь простым клиентским приложениям, которые просто выбирают первый адрес, чтобы не все попадали на один и тот же адрес, однако долго TTL.
То есть, стандарты позволяют реализовать такое поведение (порядок не важен), чем фактически предписывают это.
В общем, вам просто нужно учитывать, что порядок записей не имеет фактического значения, и что можно ожидать, что клиенты будут использовать все адреса, присутствующие в наборе записей.
Если действительно важно, чтобы трафик получал только наименее загруженный хост, вам нужно будет либо вернуть только его адрес, либо если клиентское программное обеспечение поддерживает SRV (это исключает веб-браузеры), возможно, воспользуйтесь этим и настройте SRV поля приоритета и / или веса, чтобы отразить ваши текущие предпочтения.
Тем не менее, имейте в виду, что кеширование по-прежнему будет актуальным, поэтому лучше всего будет, если клиенты «сами по себе» распределят нагрузку по доступным хостам.