• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Как организовать DNS в интересах блогосферы

Система доменных имен (DNS) – исключительно важный компонент инфраструктуры интернет-провайдера. Шрини АВЕРНЕНИ, вице-президент по защите интересов клиентов и инновациям компании Nominum дает пошаговые рекомендации по разработке, созданию и эксплуатации DNS-инфраструктуры в условиях активной блогодеятельности абонентов.

Для DNS обычно используются две формы организации – авторитетная (autho-ritative) и кэшированная (caching). Серверы авторитетной DNS содержат домены вида www.yourcompany.com и соответствующие ресурсные записи, а также, благодаря привязке имен хостов к их IP-адресам, информацию о месте их расположения.

Кэшированные серверы DNS помогают приложениям и сервисам – браузерам, VoIP, IPTV и пр. – перемещаться по иерархии DNS для нахождения соответствующего авторитетного сервера и в итоге –  хостового компьютера искомого домена.

С чего начать?

При разработке и развертывании кэшированной DNS-инфраструктуры в первую очередь нужно прояснить следующие вопросы.

■ Какому количеству абонентов планируется предоставить доступ к ресурсу? 100–150 тыс. на сервер – это типичный максимум для высокопроизводительного программного обеспечения, работающего на современной аппаратной платформе.

■ Каким ожидается прирост абонентской базы? Хорошо бы увязать рост числа абонентов с циклом обновления оборудования (три-четыре года). Приняв максимальное число абонентов равным 100–150 тыс., можно высчитать их начальное число.

■ Насколько распределенной хотелось бы видеть инфраструктуру? Обычно это определяется топологией сети. Размещение DNS-кластеров/серверов как можно ближе к конечным пользователям позволяет предоставить наилучший из возможных вариантов доступа в Интернет.

■ Какие дополнительные функции (типа IPv6 или DNSSEC) должны быть задействованы?

■ Какие дополнительные решения – например, редирект, идентификацию и подавление ботов – предполагается реализовать на платформе?

■ Какие количественные показатели следует предоставлять внутренним системам? Какая связанная с DNS статистика собирается в настоящее время и будет ли полезна новая статистика, предлагаемая новой платформой?

■ Есть ли планы развертывания новых услуг, которые станут факторами роста DNS? Каковы иные движущие силы роста бизнеса?

■ Как служба эксплуатации будет управляться с новой инфраструктурой?

■ Какие процессы и процедуры должны быть внедрены для поддержки новой (или обновленной) платформы?

Найдя ответы на поставленные вопросы (а, возможно, и на некоторые другие, обусловленные спецификой информационной среды), можно приступать к реализации своих планов. Так как возможно, что инфраструктура создается с нуля или модернизируется уже существующая, целесообразно проанализировать, как потребности бизнеса соотносятся со стоимостью и возможностями выбранного решения. Нужно учесть число абонентов и производительность системы, взвесить факторы, влияющие на качество, воспринимаемое абонентами, например время ожидания, а также стоимость.

Разработка и создание кэширующего DNS-сервера

Когда решения относительно масштабирования, допустимого времени ожидания и дополнительной функциональности, основанной на DNS, приняты, можно переходить к следующим уровням детализации системы.

Аппаратная платформа. Потребуется быстрая процессорная архитектура Intel/AMD. Оперативная память – 2 Гбайт. Но если планируется реализовать дополнительные функции – редирект или широкомасштабную статистику, то нужно иметь 8 Гбайт или больше. Также необходим гигабитный интерфейс.

Конфигурация сервера. Ее целесообразно задать следующим образом:

• каждому источнику запроса должен назначаться отдельный IP-адрес;
• объем кэш-памяти в зависимости от среды может варьироваться от 500 до 1500 Мбайт. На выбор данного конфигурационного параметра существенно влияет число абонентов, имеющих доступ к серверу;
• значение параметра Recursive contexts (рекурсивные контексты – RC) должно быть низким. Рекурсивный контекст – это цепочка команд, которая используется для выполнения процедуры рекурсии (процедуры, при которой сервер выполняет от имени клиента полный поиск нужной информации во всей системе DNS, при необходимости обращаясь к другим DNS-серверам). Чем меньше число рекурсивных контекстов, тем больше число удачных обращений к кэшу. При оптимизации сервера кэширования эти два параметра идут рука об руку;
• для допустимого времени хранения ответов (TTL) в кэше в большинстве случаев используется значение по умолчанию. Малое TTL критично для большинства ресурсных записей (RR) глобальных объектов. Это значение лучше держать низким, порядка 15–45 минут.

Безопасность. Придерживайтесь следующих рекомендаций:

• не разворачивайте межсетевой экран перед кэширующими DNS-серверами (при необходимости можно установить систему предотвращения вторжений или аналогичную ей);
• задайте список управления доступом (ACL), совпадающий с диапазоном адресов абонентов, которым разрешен доступ к серверу;
• установите максимальное число портов (16) для рандомизации UDP-порта источника, чтобы обеспечить максимальную защиту от спуфинга;
• используйте метод рандомизации запроса, известный как 0x20. Убедитесь, что сервер может работать (через TCP) без рандомизации, чтобы обслуживать небольшое количество авторитетных серверных имен, которые не зеркалируют запросы.

Резервирование. Это критичный показатель при создании надежной инфраструктуры с кэшированием. Для резервирования хорошо иметь в наличии несколько разных сетей и несколько дата-центров. При этом потребуются как минимум два логических кэширующих сервера, по крайней мере один из которых нужно располагать по возможности ближе к абонентам – так, чтобы задержка не превышала 20 мс.

Доступность. Для того чтобы воспринимаемое абонентами качество взаимодействия с Интернетом было высоким, кэширующая инфраструктура должна быть доступной всегда. Возможны несколько моделей развертывания DNS-инфрастуктуры, но лучше всего следовать топологии сети и соответствовать ожидаемым абонентами качеству и стоимости:

• модель на основе балансировки нагрузки. Эта модель допускает горизонтальное масштабирование в насыщенных средах. При необходимости также появляется возможность дополнительного контроля списков ACL на аппаратных средствах. Издержки этого подхода – высокий уровень компетенции, требуемый от балансировщика нагрузки для управления средой;
• модель на основе групповой рассылки. Это очень распространенная модель реализации. Она позволяет отдельным серверам выступать в роли узлов DNS в сети. Трафик DNS маршрутизируется к ближайшему серверу в сети;
• гибридная модель – групповая рассылка с балансировкой нагрузки. Используется в крупномасштабных средах. Обеспечивает гибкое масштабирование узла во множество серверов в зависимости от плотности абонентов и объемов трафика.

Производительность. Масштабируемая инфраструктура должна справляться с отказами сети и/или оборудования. У сервера всегда должен иметься достаточный запас производительности на случай потери сайта или сервера, а также для проведения регламентных работ на сайте или сервере.

Установка пороговых значений. Этот шаг позволит цент-ру управления сети превентивно решать проблемы, пока они не приобрели угрожающего характера:

• загрузка процессора не должна превышать 40, 50 или 60%;
• запуск контекстов рекурсии должен осуществляться при примерно 20%-ном использовании ресурсов, 50%-ная загрузка должна вызвать отправку уведомления, а 75%-ная требует разбирательства в создавшейся ситуации;
• нужно задать число запросов в секунду на одного клиента.

DDoS. Для предотвращения DDoS-атак следует ограничивать интенсивность запросов по IP, использовать распределенные серверы и лучшие типы кэширующих серверов.

Процесс развертывания. Старайтесь упростить процесс развертывания, чтобы оперативнее устанавливать патчи и обновлять программное обеспечение. Будьте готовы быстро пересобрать операционную систему, установить патч или обновить ПО.

Запуск кэширующего DNS-сервера

Итак, новая DNS-инфраструктура «поднялась» и заработала. Теперь нужно обеспечить выполнение следующих требований:

• процесс DNS должен работать на сервере при загрузке процессора не более 20%;
• нужно максимизировать число удачных обращений к кэшу путем управления его размером;
• рекурсивные контексты должны быть установлены на уровне 10–15% общей поддерживаемой доступности RC;
• ресурсы следует распределить, насколько это возможно;
• серверы должны быть максимально приближены к абонентам;
• если позволяют условия эксплуатации, полезно использовать несколько операционных систем и разнотипное оборудование. Зачастую это трудно осуществимо и может быть экономически невыгодно ввиду отсутствия ресурсов, работающих под разными ОС, необходимости поддержки разных эксплуатационных процедур и моделей развертывания, а также дороговизны эксплуатации. Количественные показатели производительности могут меняться в зависимости от использования конкретного типа ОС и/или оборудования.

Для поддержания надежности работы окружения на уровне 99,999% очень важно обеспечить контроль доступности системы и измерение параметров функционирования программного обеспечения. В число наиболее важных показателей мониторинга входят:

• загрузка процессора, памяти, дискового пространства;
• состояние подсистемы ввода-вывода;
• статистика интерфейсов;
• процесс кэширующего сервера;
• статистика рекурсивных контекстов;
• число запросов в секунду;
• список клиентов, генерирующих наибольшее число запросов к DNS;
• список наиболее часто посещаемых доменов.

При установке патчей и обновлений по возможности предварительно проверьте их в лабораторных условиях. Сначала установите их на один сервер или сайт и дайте ему поработать в течении некоторого времени, согласованного со службой эксплуатации. Методики и процедуры, выполняемые службой эксплуатации, при добавлении новых функций и/или особенностей работы также следует обновить.