Лучшие DNS практики для телекома

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

Выполнение перечисленных правил может помочь вам минимизировать жалобы ваших пользователей на DNS:

  • Никогда не используйте межсетевые экраны с контролем состояния сессий на DNS серверах.
    Iptables и пр. сетевые экраны существенным образом уменьшают производительность нагруженных DNS серверов.
    Если по организационным причинам необходимо проводить фильтрацию трафика — то лучше это делать на обычных не statefull межсетевых экранах на сетевом оборудовании. Например с помощью обычных ACL на аппаратных маршрутизаторах Cisco, начиная с 7600 (6500) серии, построенных на ASIC и FPGA.
  • Размер кеша должен быть меньше или равен 512Мб. БОльшие значения не приводят к хоть сколько либо значимому увеличению эффективности кеширования, но увеличивают требования к пропускной способности оперативной памяти и эффективности кешей центрального процессора. При использовании кеша размером 512Мб желательно иметь общий объем оперативной памяти не менее 2048Мб.
  • Средняя нагрузка на центральный процессор DNS сервера не должна превышать 30%. Выполнение этого правила позволит легче пережить DDOS и вирусные атаки.
  • Всегда используйте настройки, ограничивающие доступ к кеширующим DNS серверам только для своих клиентов. Не стоит позволять их использовать всем пользователям Интернет. Это может привести к использованию ваших DNS серверов для DNS Amplification Attacks, к неконтролируемой нагрузке и увеличивает шансы злоумышленников отравить ваш кеш.
  • Всегда разделяйте авторитативные и кеширующие DNS сервера. Это справедливо для организаций любого размера.
  • DNS сервера желательно эксплуатировать на выделенном для них оборудовании. Для кеширующих DNS серверов самым важным параметром является мощность центрального процессора. Для авторитативных DNS серверов несколько важнее пропускная способность оперативной памяти. При малых нагрузках на DNS сервера допускается их использование на системах виртуализации. При этом им обязательно необходимо гарантировать ресурсы по процессору, памяти и сети.
  • Для DNS серверов лучше использовать процессоры максимальной частоты. Лучше один мощный двух-ядерный или четырех-ядерный процессор, чем два процессора меньшей частоты. Дело в том, что современное программное обеспечение плохо масштабируется на множество ядер-нитей процессоров. Более того лучше использовать «single-threaded» реализации (или сборки) программного обеспечения DNS.
  • Используйте 64-битные операционные системы на современном оборудовании. Для новых систем следует использовать сервера, построенные x86-64. Системы построенные на SPARC процессорах значительно меньше подходят для задач DNS сервера.
  • Для DNS серверов желательно использовать гигабитные сетевые интерфейсы, для того чтобы сеть не стала узким местом.
  • При необходимости распределять нагрузку на несколько DNS серверов рекомендуется делать это через IP ANYCAST или с помощью баласировщиков нагрузки c выключением состояния сессий.
  • Используйте проверенные решения. Тестируйте новые версии перед использованием их в продуктивной среде. Старайтесь делать одно изменение за раз, не больше. Например обновляя версию ПО, обновите ее сначала только на одном из серверов.
  • Не увлекайтесь слишком тюнингом сетевого стэка операционной системы. Как правило все современные UNIX и UNIX-like системы имеют оптимальные настройки. Если появились какие то проблемы эксплуатации, то надо провести как можно более глубокую диагностику, перед тем как кошмарить операционную систему громадными буферами и пр.
  • До начала использования DNSSEC необходимо тщательно протестировать как и ПО, так и нагрузку на оборудование. Дополнительно к этому стоит внимательно отнестись к процедурам, связанным с DNSEC, так как любая ошибка может быть незаметной и в то же время носить фатальный характер, когда DNSSEC кеширующие DNS сервера будут отвергать записи с ваших зон как неправильно подписанные.
  • Не ленитесь настроить мониторинг ваших DNS серверов. Это позволить избежать проблем до того как их заметят пользователи. Ведь проблемы DNS воспринимаются пользователями как проблемы сети. Им неважно что у вас супер-современная скоростная низко латентная сеть, защищенная от сбоев, если у них медленно открывается страничка в Интернет из за плохо работающего DNS сервера.
  • Сохраняйте общий дизайн вашего DNS решения максимально простым. Это облегчит вам диагностику проблем.
Поделиться публикацией

Комментарии 24

    +2
    Всегда разделяйте авторитативные и кеширующие DNS сервера. Это справедливо для организаций любых размеров..

    One size doesn't fit all.

      0
      Хм… При таком разделении обращение своих клиентов к своему же порталу будет идти по полно схеме…
      И как в таком случае настраивать внутреннею зону?
        0
        В бинде ещё в прошлом тысячелетии была реализована поддержка view. Специально для этого.
          0
          Ну так view я использую))) Я не об этом.
          Итак у прова есть внутренняя зона .prov. Как вы хотите для внутренних клиентов организовать на разных серверах и работу с этой зоной и кэширующий DNS сервер?
            +2
            а зачем делать костыли вроде «внутренней зоны .prov»? Что мешает использовать нормальную зону prov.ru?
              –3
              А в чем будет разница между зоной .prov и зоной .prov.ru?
                +1
                Если кэширующий и авторитарный серверы — разные, то в случае с «несуществующим tld», расположенном на авторитарном, придётся на кэширующем прописывать костыли вроде принудительного форварда зоны на авторитарный (например, зона типа forward в BIND).

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

                Но вообще, как вы верно ниже заметили, советы какие-то для уж очень больших серверов.
                –1
                причем тут костыли?
                Это внутренняя зона для клиентов. Там внутренние ресурсы типа сайтов для DC клиентов, форумов поддерживаемых самими пользователями. В общем зона не доступная из вне.

                p.s. и кстати ну пускай внешняя зона (prov.ru) и работает все на view — но ведь этот же сервер будет использоваться и клиентами для обычных DNS запросов. И что выходит — авторитативный и кэширующий DNS роли на одной машине. От чего TC так настоятельно рекомендует уйти. Вот собственно в чем вопрос как?
        0
        Хотелось бы существенно большей детализации. Вы даете много советов, но у меня складывается впечатление, что они в основном предназначены для провайдеров, у которых десятки тысяч клиентов.
        Скажем про гигабитные сетевые платы на сервере — понятно, что на современных серверах и так стоят гигабитные сетевые платы, но при каком количестве запросов в минуту будет происходить переполнение 100 мегабит?

        и чем плохо хранение авторитативных зон на кеширующем сервере? чему это противоречит?
          0
          Воронеж, ЦТК. Два сервера, они же и кэширующие, и авторитарные, и резервные (slave) для многих зон. Клиентов у них, сейчас уже, наверное, под сотню тысяч. Не слышал ни про какой anycast для DNS.

          Боюсь соврать, аппарат там Sparc (не рекомендованный выше), и уже давно (лет десять). Машины эти, кроме DNS, хостят как минимум NTP-сервер, а также тестовый веб-сервер (судя по тому, что все эти имена указывают на один и тот же IP-адрес).

          Как бы живая демонстрация того, что если правила выше и применимы, то уже не для десятков тысяч, а как минимум нескольких сотен тысяч. Ибо с меньшим числом — можно так сильно не загоняться.
            0
            На мой взгляд дело не в том, что 100Мбит при нормальной эксплуатации нужно обязательно заполнять, а в том, что если сервер может прокачать более 100Мбит — то ему необходимо предоставить такую возможность. Сценарии когда это может понадобиться: DDoS, вирусная активность.

            Хранение авторитативных зон на кеширующем сервере плохо по нескольким причинам:
            • Если у вас была прописана авторитативная зона для клиента, а клиент тихо переделегировал свой домен на другие dns-сервера — то у вас либо должно быть разработано средство оперативного мониторинга для таких ситуаций, либо узнаете об этом от других клиентов, которые будут получать с вашего кеширующего сервера неправильные записи;
            • Более простая конфигурация сервисов. Меньше возможностей совершить конфигурационные ошибки;
            • Изменение векторов атаки. Например если идет атака на авторитативные сервера, то она не затронет кеширующие сервера;
            • Возможность увеличивать мощность обоих сервисов независимо друг от друга;
            • Возможность использовать ПО, которое наиболее отвечает текущей задаче. Например на авторитативных использовать ISC Bind, на кеширующих PowerDNS Recursor.

            Резюме — при разделении авторитативного и рекурсивного сервиса появляется больше гибкости.
            0
            а почему «Используйте 64-битные операционные системы на современном оборудовании»?
              +1
              Требую пояснений для
              Используйте 64-битные операционные системы на современном оборудовании. Для новых систем следует использовать сервера, построенные x86-64. Системы построенные на SPARC процессорах значительно меньше подходят для задач DNS сервера.


              И для
              Размер кеша должен быть меньше или равен 512Мб


              Указывайте про какую реализацию DNS конкретно вы говорите, иначе хочется поставить минус.
                0
                Фокус статьи — телеком компании. У больших из них как правило есть в наличии много устаревшего, унаследованного серверного оборудования. И как правило возникает соблазн использовать какой нибудь SUN Fire V120 в качестве кеширующего dns сервера. На хорошо настроенном ПО такой сервер сможет без особых проблем обслуживать несколько тысяч dns запросов в секунды, при максимальной утилизации центрального процессора. Вопрос в том, что текущие скорости подключения клиентов измеряются в некоторых случаях в десятки мегабит. И проблемные клиенты время от времени генерируют паразитную нагрузк на dns, за счет ошибочной конфигурации в своих LAN. В моей практике встречались ситуации, когда «плохой» клиент генерил до 5000 запросов в секунду. Пара таких клиентов легко «укладывают» подобный сервер.
                Например, прямо сейчас в компании, на которую я работаю, на наши кеширующие dns-сервера льется поток от одного из клиентов в 1400 запросов в секунду вида «PTR 105.1.168.192.in-addr.arpa.» Так-как мощность нашего оборудования избыточна — это не содает нам никаких проблем.
                На мой взгляд использование современного оборудования на стороне провайдера в какой то степени гарантируют, что он выдержит ненормальную активность каждого единичного клиента.

                Утвержение насчет кеша проверено практикой. Увеличение кеша до 1024Мб дает пару-тройку процентов увеличения эффективности кеша, с ростом нагрузки на процессор. Это практически не завязано на конкретные реализации DNS серверов.
                –1
                Требую пояснений для
                Используйте 64-битные операционные системы на современном оборудовании. Для новых систем следует использовать сервера, построенные x86-64. Системы построенные на SPARC процессорах значительно меньше подходят для задач DNS сервера.

                И для
                Размер кеша должен быть меньше или равен 512Мб

                Указывайте про какую реализацию DNS конкретно вы говорите, иначе хочется поставить минус
                  –2
                  Хабр заставил дубль сделать… ибо не показал с первого раза :-(
                  –1
                  разрешите позанудствовать: циска 6500 и 7600 — коммутатор. (да, я знаю, что их сложно делить в таком размахе, но все же)…
                    +1
                    7600 все-же маршрутизатор, а вот 6500 как раз коммутатор
                      0
                      формально — да. но только вот модули от 6500 подходят к 7600
                    0
                    Это опыт какой компании с какой нагрузкой на dns сервера?
                      0
                      Ух, раскажите это пчелайну (уже киевстар) в Украине. А то ихние ДНСы дохнут и дохнут.
                        +1
                        у многих хороших провайдеров сервера вынесены в различные подсети для повышения надёжности, т.е. не ххх.ххх.ххх.1-255, а как минимум ххх.ххх.х-у.1-255
                        это должно очень спасать при локальных проблемах с маршрутизайцией!
                        это правило имеет место в указанном списке?
                          0
                          Вот это, наверно, единственное правило, которое верно без связи с количеством клиентов.
                          +1
                          Очень грамотные советы. Прямо очень-очень. Фактически, полный how-to, ни к одному из советов нет реальных претензий.

                          Но! Это все — для проектов с десятками миллионов пользователей или провайдеров с миллионами клиентов (от сотен тысяч если быть точнее).

                          Реально, статья скорее для nag.ru чем для habrahabr — ибо требует детальных пояснений для большинства.

                          Один anycast чего стоит — это BGP, анонсирование сеток, multi-home, ограничение на UDP (ибо TCP с anycast дружит весьма отоносительно)…

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое