RFC1034требует от нас назначения как минимум двух IP-адресов для DNS-серверов. Однако избыточность может быть достигнута уже одним IP-адресом, если мы используем адресацию anycast. BGP anycast, похоже, хорошо масштабируется на сотни или даже тысячи серверов.
Если так, то почему нам все еще нужно несколько IP-адресов для DNS-серверов? Действительно ли это повышает избыточность (способствует доступности), если у нас уже есть anycast, или это просто миф?
С какими проблемами и ошибками мы можем столкнуться?если мы используем только один IP-адрес?
Под этим я подразумеваю полное исключение вторичных DNS-адресов или использование поддельного IP-адреса (например, 1.2.3.4) в качестве второго адреса, когда для некоторых настроек требуется как минимум два.
решение1
Один произвольный IP-адрес не обеспечивает такой же избыточности, как два одноадресных IP-адреса в разных IP-префиксах.
Зачастую самая сложная проблема с избыточностью возникает не тогда, когда что-то полностью выходит из строя, а когда оно ведет себя ненадлежащим образом, чтобы пройти проверки работоспособности, но при этом фактически не функционирует.
Я видел настройку anycast DNS, где DNS-сервер выходил из строя, но пакеты все равно направлялись на этот DNS-сервер. То, что занималось объявлением префикса, могло просто не знать, что DNS-сервер выходил из строя.
Ситуация становится еще сложнее, если рассматриваемый DNS-сервер не является авторитативным DNS-сервером, а представляет собой рекурсивный резолвер.
Такой рекурсивный резолвер должен иметь как адрес anycast для получения запросов от клиентов, так и адреса unicast для запросов к авторитетным DNS-серверам. Но если адреса unicast выйдут из строя, он может легко выглядеть достаточно здоровым, чтобы по-прежнему маршрутизировать запросы.
Anycast — отличный инструмент для масштабируемости и сокращения задержек. Но для избыточности он не должен быть единственным.
Однако несколько избыточных пулов anycast являются хорошим решением для обеспечения доступности. Известный пример — 8.8.8.8 и 8.8.4.4. Оба являются адресами anycast, но они никогда не должны быть направлены на один и тот же физический DNS-сервер (при условии, что Google хорошо справился со своей работой).
Если у вас 10 физических DNS-серверов, вы можете настроить их как 2 пула с 5 серверами в каждом пуле или 5 пулов с 2 серверами в каждом пуле. Вы хотите избежать того, чтобы один физический DNS-сервер находился в нескольких пулах одновременно.
Так сколько IP-адресов вам следует выделить? Вам нужны IP-адреса, которые можно настроить как anycast независимо друг от друга. Обычно это означает, что вам нужно выделить целый /24 адресного пространства IPv4 или /48 адресного пространства IPv6 для каждого пула. Это может очень сильно ограничить количество пулов, которые вы можете иметь.
Кроме того, если мы говорим об авторитетных серверах, то ответ DNS со всеми вашими записями NS и A и AAAA Glue должен умещаться в один пакет размером 512 байт. Для корневых серверов это составило 13 адресов. Но это не включало Glue и IPv6, поэтому число, которого вы достигнете, будет меньше.
Каждый пул должен быть максимально географически распределен. Если у вас 5 серверов в Европе и 5 в Северной Америке и 2 anycast IP, вам не нужно создавать один пул, охватывающий каждый континент. Вы помещаете 2 из Европы в пул с 3 из Северной Америки, а остальные 5 — в другой пул.
Если у вас больше 2 пулов anycast, вы можете позволить физическому серверу временно находиться в более чем одном пуле. Но вы никогда не должны позволять физическому серверу находиться во всех пулах одновременно.
Объединение anycast и unicast возможно, но нужно быть осторожным. Если у вас есть IP для двух пулов, я бы не стал объединять. Но если у вас есть только один anycast IP для работы, может иметь смысл также включить unicast IP. Проблема в том, что включение unicast IP не даст вам хорошей задержки и балансировки нагрузки.
Если физический сервер доступен как по одноадресной, так и по произвольной рассылке, вы можете рисковать тем, что пользователи будут обращаться к одному и тому же серверу как к основному и вторичному и потеряют доступ, если он выйдет из строя. Этого можно избежать, используя только одноадресные адреса серверов, не входящих в пул произвольной рассылки, или всегда предоставляя пользователям два одноадресных адреса.
Чем больше адресов unicast вы добавите в микс, тем меньше запросов будет отправлено на адрес anycast и тем меньше преимуществ вы получите от anycast с точки зрения задержки и масштабируемости.
решение2
Лучше всего использовать как минимум два адреса с разными префиксами и давать им имена в двух разных TLD. Оба этих адреса могут быть anycast, если хотите. Наличие только одного IP-адреса даст вам единую точку отказа. Если маршрутизация к этому адресу не работает (ошибка конфигурации, экземпляр anycast работает неправильно, префикс был перехвачен и т. д.), то весь ваш домен станет недоступным.
Каждый адрес anycast потребует по крайней мере префикс /24IPv4 или /48IPv6 для маршрутизации в BGP. Меньшие (длинные) префиксы обычно не принимаются в глобальной таблице маршрутизации во многих местах.
Никогдавсегдаввести фиктивный IP-адрес в качестве DNS-сервера. Это вызовет серьезные задержки для резолверов.
решение3
В RFC 1034 указано только, что вам необходимо два DNS-сервера. Это не обязательное требование, а рекомендация, так что делайте с ним, что хотите. Независимо от этого, если вам нужна HA, вашим 2 DNS-серверам может быть назначен один и тот же IP-адрес с помощью anycast, и единственное, что ваши конечные пользователи заметят, когда один DNS-сервер выйдет из строя, — это кратковременное отсутствие связи, пока сеть восстанавливает конвергенцию.
Итак, подводя итог, можно сказать, что использование anycast достаточно для соответствия RFC 1034.