@Ivante

DNS, каков порядок выбора ns записей клиентами?

Есть site.ru, развёрнут на 3 серверах сразу, 1-ый главный, 2 и 3 резервные копии допустим дневной давности. На каждом сервере свой dns сервер который указывает сам на себя в А записи.
В dns установлены следующие ns записи, и каждая имеет свою А запись
ns1.site.ru 10.0.0.1 А запись 10.0.0.1
ns2.site.ru 10.0.0.2 А запись 10.0.0.2
ns3.site.ru 10.0.0.3 А запись 10.0.0.3

Верна ли схема, что все пользователи запросив сайт будут получать все 3 ns сервера, а брать А запись по порядку то-есть если доступен ns1 все получат A запись 10.0.0.1 и только его. Если 1-ый сервер недоступен все пойдут на ns2, а если уже тот недоступен то на ns3. Как только поднимется первый сервер все клиенты вернутся только на него.

Т.е соблюдается ли порядок ns серверов или клиент берёт случайный и такая схема не будет работать. Таким образом хочется организовать простую отказоустойчивость на dns.

P.S задача в подстраховке доступности, не требующая сложных схем репликации и кластеров, и строгой актуализации данных.
  • Вопрос задан
  • 1006 просмотров
Пригласить эксперта
Ответы на вопрос 3
@inkvizitor68sl
Linux-сисадмин с 8 летним стажем.
Берет случайный.

Поэтому с резервных нужно проксировать трафик на основной, а когда он падает - начинать отдавать заглушку (или что там у вас) напрямую.
Ответ написан
Комментировать
@polozad
Погуглите round robin в применении к DNS. Полноценное НА через DNS не настроишь, ему плевать.
Ответ написан
В любом случае нужно иметь постоянные адреса серверов в DNS, по которым балансировать с помощью DNS, если нужно, и с которых проксировать на главные/резервные сервера, как уже заметили в ответах, но я хочу немного добавить для полноты картины.

Еще нужно учитывать, что клиентские/провайдерские сервера кэшируют запросы, порой очень надолго, поэтому никаких обращений к вашим NS не будет. Кроме того, не ясно, какой длины цепочка из серверов до вас, там по пути могут что попало накэшировать. Бинд по умолчанию максимально кэширует на неделю, например.

Также я прошелся по RFC1034 по диагонали, нашел важное: "The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS." Или: "Since the DNS does not preserve the order of RRs, this function may choose to sort the returned addresses or select the "best" address if the service returns only one choice to the client."

В общем, точно нельзя полагаться на определенный порядок нигде.

Пара примеров:

Например, Гугл использует балансировку: их NS возвращают один адрес с малым TTL (300). Вот реакция разных серверов на это: мой named по умолчанию так и возвращает, и пока TTL не истечет, показывает одну запись; 4.2.2.1 выводит сразу много А записей с разными маленькими TTL; 8.8.8.8 просто не кэширует, отдает по одному адресу, но с разными TTL (тоже маленькими)).

Касательно NS можете попробовать dig @8.8.8.8 ya.ru NS и убедиться в том, что порядок любой.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы