DNS-серверы уже используют anycast. Будет ли добавление большего количества IP-адресов повысить масштабируемость?

RFC 1034 требует от нас назначить как минимум два IP-адреса для DNS-серверов. Однако избыточность уже может быть достигнута одним IP-адресом, если мы используем произвольную адресацию. Anycast BGP, кажется, хорошо масштабируется на сотни или даже тысячи серверов.

Если так, почему нам все еще нужно несколько IP-адресов для DNS-серверов? Действительно ли это увеличивает избыточность (способствует доступности), если у нас уже есть anycast, или это просто миф?

С какими проблемами и ошибками мы можем столкнуться, если будем использовать только один IP-адрес?

Под этим я подразумеваю полное исключение вторичных адресов DNS или использование поддельного IP (например 1.2.3.4) для второго адреса, когда для некоторых настроек требуется как минимум два.

Один произвольный IP-адрес не дает такой же избыточности, как два одноадресных IP-адреса с разными IP-префиксами.

Часто самая сложная проблема для избыточности заключается не в том, когда что-то выходит из строя полностью, а в том, что оно ведет себя не так, как нужно, чтобы пройти проверку работоспособности, но на самом деле не работает.

Я видел настройку anycast DNS, где DNS-сервер отключался, но пакеты все равно передавались на этот DNS-сервер. Что бы ни заботилось о рекламе, префикс мог бы просто не знать, что DNS-сервер вышел из строя.

Становится еще сложнее, если рассматриваемый DNS-сервер не является авторитетным DNS-сервером, а скорее рекурсивным распознавателем.

Такой рекурсивный распознаватель должен иметь как адрес anycast для получения запросов от клиентов, так и адреса одноадресной рассылки для запросов к авторитетным 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 в другой пул.

Если у вас более двух пулов anycast, вы можете временно разрешить физическому серверу работать в нескольких пулах. Но вы никогда не должны позволять физическому серверу находиться во всех пулах одновременно.

Комбинация anycast и unicast возможна, но нужно соблюдать осторожность. Если у вас есть IP для двух пулов, я бы не совмещал. Но если у вас есть только один альтернативный IP-адрес, возможно, имеет смысл также включить одноадресные IP-адреса. Проблема заключается в том, что включение одноадресных IP-адресов не обеспечит хорошую задержку и балансировку нагрузки.

Если физический сервер становится доступным как для одноадресной, так и для любой рассылки, вы можете подвергнуть пользователей риску получить доступ к одному и тому же серверу как первичному и вторичному и потерять доступ в случае его отказа. Этого можно избежать, используя только одноадресные адреса серверов, не входящих в пул anycast, или всегда предоставляя пользователям два одноадресных адреса.

Чем больше адресов одноадресной рассылки вы добавите в микс, тем меньше запросов будет отправлено на адрес anycast, и тем меньше преимуществ вы получите от anycast с точки зрения задержки и масштабируемости.

Рекомендуется использовать как минимум два адреса из разных префиксов и присваивать им имена под двумя разными TLD. Оба эти адреса могут быть в любом случае, если хотите. Наличие только одного IP-адреса даст вам единственную точку отказа. Если маршрутизация на этот адрес не работает (ошибка конфигурации, некачественный экземпляр anycast, угон префикса и т. Д.), Весь ваш домен становится недоступным.

Каждый адрес anycast требует, чтобы по крайней мере префикс /24IPv4 или /48IPv6 был маршрутизируемым в BGP. Меньшие (более длинные) префиксы обычно не принимаются в глобальной таблице маршрутизации во многих местах.

Никогда не вставляйте поддельный IP-адрес в качестве DNS-сервера. Это приведет к серьезным задержкам для резольверов.

RFC 1034 только утверждает, что вам требуется два DNS-сервера. Это не обязательное требование, а рекомендация, поэтому делайте с ним что хотите. В любом случае, если вы хотите HA, вашим 2 DNS-серверам может быть назначен один и тот же IP-адрес с помощью anycast, и единственное, что ваши конечные пользователи заметят при сбое одного DNS-сервера, - это кратковременное отсутствие соединения при повторном сближении сети.

Итак, в общем, да, использование anycast достаточно для соответствия RFC 1034.