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