Comments 24
Всегда разделяйте авторитативные и кеширующие DNS сервера. Это справедливо для организаций любых размеров..
One size doesn't fit all.
One size doesn't fit all.
Хм… При таком разделении обращение своих клиентов к своему же порталу будет идти по полно схеме…
И как в таком случае настраивать внутреннею зону?
И как в таком случае настраивать внутреннею зону?
В бинде ещё в прошлом тысячелетии была реализована поддержка view. Специально для этого.
Ну так view я использую))) Я не об этом.
Итак у прова есть внутренняя зона .prov. Как вы хотите для внутренних клиентов организовать на разных серверах и работу с этой зоной и кэширующий DNS сервер?
Итак у прова есть внутренняя зона .prov. Как вы хотите для внутренних клиентов организовать на разных серверах и работу с этой зоной и кэширующий DNS сервер?
а зачем делать костыли вроде «внутренней зоны .prov»? Что мешает использовать нормальную зону prov.ru?
А в чем будет разница между зоной .prov и зоной .prov.ru?
Если кэширующий и авторитарный серверы — разные, то в случае с «несуществующим tld», расположенном на авторитарном, придётся на кэширующем прописывать костыли вроде принудительного форварда зоны на авторитарный (например, зона типа forward в BIND).
Если в той же ситуации использовать корректно делегированную на авторитарный сервер зону, никаких костылей прописывать не надо — кэширующий после первого же запроса придёт по цепочке, начиная с корневых серверов, на авторитарный, и там и останется, поскольку он кэширующий, и больше к корневым лезть особо часто не будет.
Но вообще, как вы верно ниже заметили, советы какие-то для уж очень больших серверов.
Если в той же ситуации использовать корректно делегированную на авторитарный сервер зону, никаких костылей прописывать не надо — кэширующий после первого же запроса придёт по цепочке, начиная с корневых серверов, на авторитарный, и там и останется, поскольку он кэширующий, и больше к корневым лезть особо часто не будет.
Но вообще, как вы верно ниже заметили, советы какие-то для уж очень больших серверов.
причем тут костыли?
Это внутренняя зона для клиентов. Там внутренние ресурсы типа сайтов для DC клиентов, форумов поддерживаемых самими пользователями. В общем зона не доступная из вне.
p.s. и кстати ну пускай внешняя зона (prov.ru) и работает все на view — но ведь этот же сервер будет использоваться и клиентами для обычных DNS запросов. И что выходит — авторитативный и кэширующий DNS роли на одной машине. От чего TC так настоятельно рекомендует уйти. Вот собственно в чем вопрос как?
Это внутренняя зона для клиентов. Там внутренние ресурсы типа сайтов для DC клиентов, форумов поддерживаемых самими пользователями. В общем зона не доступная из вне.
p.s. и кстати ну пускай внешняя зона (prov.ru) и работает все на view — но ведь этот же сервер будет использоваться и клиентами для обычных DNS запросов. И что выходит — авторитативный и кэширующий DNS роли на одной машине. От чего TC так настоятельно рекомендует уйти. Вот собственно в чем вопрос как?
Хотелось бы существенно большей детализации. Вы даете много советов, но у меня складывается впечатление, что они в основном предназначены для провайдеров, у которых десятки тысяч клиентов.
Скажем про гигабитные сетевые платы на сервере — понятно, что на современных серверах и так стоят гигабитные сетевые платы, но при каком количестве запросов в минуту будет происходить переполнение 100 мегабит?
и чем плохо хранение авторитативных зон на кеширующем сервере? чему это противоречит?
Скажем про гигабитные сетевые платы на сервере — понятно, что на современных серверах и так стоят гигабитные сетевые платы, но при каком количестве запросов в минуту будет происходить переполнение 100 мегабит?
и чем плохо хранение авторитативных зон на кеширующем сервере? чему это противоречит?
Воронеж, ЦТК. Два сервера, они же и кэширующие, и авторитарные, и резервные (slave) для многих зон. Клиентов у них, сейчас уже, наверное, под сотню тысяч. Не слышал ни про какой anycast для DNS.
Боюсь соврать, аппарат там Sparc (не рекомендованный выше), и уже давно (лет десять). Машины эти, кроме DNS, хостят как минимум NTP-сервер, а также тестовый веб-сервер (судя по тому, что все эти имена указывают на один и тот же IP-адрес).
Как бы живая демонстрация того, что если правила выше и применимы, то уже не для десятков тысяч, а как минимум нескольких сотен тысяч. Ибо с меньшим числом — можно так сильно не загоняться.
Боюсь соврать, аппарат там Sparc (не рекомендованный выше), и уже давно (лет десять). Машины эти, кроме DNS, хостят как минимум NTP-сервер, а также тестовый веб-сервер (судя по тому, что все эти имена указывают на один и тот же IP-адрес).
Как бы живая демонстрация того, что если правила выше и применимы, то уже не для десятков тысяч, а как минимум нескольких сотен тысяч. Ибо с меньшим числом — можно так сильно не загоняться.
На мой взгляд дело не в том, что 100Мбит при нормальной эксплуатации нужно обязательно заполнять, а в том, что если сервер может прокачать более 100Мбит — то ему необходимо предоставить такую возможность. Сценарии когда это может понадобиться: DDoS, вирусная активность.
Хранение авторитативных зон на кеширующем сервере плохо по нескольким причинам:
Резюме — при разделении авторитативного и рекурсивного сервиса появляется больше гибкости.
Хранение авторитативных зон на кеширующем сервере плохо по нескольким причинам:
- Если у вас была прописана авторитативная зона для клиента, а клиент тихо переделегировал свой домен на другие dns-сервера — то у вас либо должно быть разработано средство оперативного мониторинга для таких ситуаций, либо узнаете об этом от других клиентов, которые будут получать с вашего кеширующего сервера неправильные записи;
- Более простая конфигурация сервисов. Меньше возможностей совершить конфигурационные ошибки;
- Изменение векторов атаки. Например если идет атака на авторитативные сервера, то она не затронет кеширующие сервера;
- Возможность увеличивать мощность обоих сервисов независимо друг от друга;
- Возможность использовать ПО, которое наиболее отвечает текущей задаче. Например на авторитативных использовать ISC Bind, на кеширующих PowerDNS Recursor.
Резюме — при разделении авторитативного и рекурсивного сервиса появляется больше гибкости.
а почему «Используйте 64-битные операционные системы на современном оборудовании»?
Требую пояснений для
И для
Указывайте про какую реализацию DNS конкретно вы говорите, иначе хочется поставить минус.
Используйте 64-битные операционные системы на современном оборудовании. Для новых систем следует использовать сервера, построенные x86-64. Системы построенные на SPARC процессорах значительно меньше подходят для задач DNS сервера.
И для
Размер кеша должен быть меньше или равен 512Мб
Указывайте про какую реализацию DNS конкретно вы говорите, иначе хочется поставить минус.
Фокус статьи — телеком компании. У больших из них как правило есть в наличии много устаревшего, унаследованного серверного оборудования. И как правило возникает соблазн использовать какой нибудь SUN Fire V120 в качестве кеширующего dns сервера. На хорошо настроенном ПО такой сервер сможет без особых проблем обслуживать несколько тысяч dns запросов в секунды, при максимальной утилизации центрального процессора. Вопрос в том, что текущие скорости подключения клиентов измеряются в некоторых случаях в десятки мегабит. И проблемные клиенты время от времени генерируют паразитную нагрузк на dns, за счет ошибочной конфигурации в своих LAN. В моей практике встречались ситуации, когда «плохой» клиент генерил до 5000 запросов в секунду. Пара таких клиентов легко «укладывают» подобный сервер.
Например, прямо сейчас в компании, на которую я работаю, на наши кеширующие dns-сервера льется поток от одного из клиентов в 1400 запросов в секунду вида «PTR 105.1.168.192.in-addr.arpa.» Так-как мощность нашего оборудования избыточна — это не содает нам никаких проблем.
На мой взгляд использование современного оборудования на стороне провайдера в какой то степени гарантируют, что он выдержит ненормальную активность каждого единичного клиента.
Утвержение насчет кеша проверено практикой. Увеличение кеша до 1024Мб дает пару-тройку процентов увеличения эффективности кеша, с ростом нагрузки на процессор. Это практически не завязано на конкретные реализации DNS серверов.
Например, прямо сейчас в компании, на которую я работаю, на наши кеширующие dns-сервера льется поток от одного из клиентов в 1400 запросов в секунду вида «PTR 105.1.168.192.in-addr.arpa.» Так-как мощность нашего оборудования избыточна — это не содает нам никаких проблем.
На мой взгляд использование современного оборудования на стороне провайдера в какой то степени гарантируют, что он выдержит ненормальную активность каждого единичного клиента.
Утвержение насчет кеша проверено практикой. Увеличение кеша до 1024Мб дает пару-тройку процентов увеличения эффективности кеша, с ростом нагрузки на процессор. Это практически не завязано на конкретные реализации DNS серверов.
Требую пояснений для
Используйте 64-битные операционные системы на современном оборудовании. Для новых систем следует использовать сервера, построенные x86-64. Системы построенные на SPARC процессорах значительно меньше подходят для задач DNS сервера.
И для
Размер кеша должен быть меньше или равен 512Мб
Указывайте про какую реализацию DNS конкретно вы говорите, иначе хочется поставить минус
Используйте 64-битные операционные системы на современном оборудовании. Для новых систем следует использовать сервера, построенные x86-64. Системы построенные на SPARC процессорах значительно меньше подходят для задач DNS сервера.
И для
Размер кеша должен быть меньше или равен 512Мб
Указывайте про какую реализацию DNS конкретно вы говорите, иначе хочется поставить минус
разрешите позанудствовать: циска 6500 и 7600 — коммутатор. (да, я знаю, что их сложно делить в таком размахе, но все же)…
Это опыт какой компании с какой нагрузкой на dns сервера?
Ух, раскажите это пчелайну (уже киевстар) в Украине. А то ихние ДНСы дохнут и дохнут.
у многих хороших провайдеров сервера вынесены в различные подсети для повышения надёжности, т.е. не ххх.ххх.ххх.1-255, а как минимум ххх.ххх.х-у.1-255
это должно очень спасать при локальных проблемах с маршрутизайцией!
это правило имеет место в указанном списке?
это должно очень спасать при локальных проблемах с маршрутизайцией!
это правило имеет место в указанном списке?
Очень грамотные советы. Прямо очень-очень. Фактически, полный how-to, ни к одному из советов нет реальных претензий.
Но! Это все — для проектов с десятками миллионов пользователей или провайдеров с миллионами клиентов (от сотен тысяч если быть точнее).
Реально, статья скорее для nag.ru чем для habrahabr — ибо требует детальных пояснений для большинства.
Один anycast чего стоит — это BGP, анонсирование сеток, multi-home, ограничение на UDP (ибо TCP с anycast дружит весьма отоносительно)…
Но! Это все — для проектов с десятками миллионов пользователей или провайдеров с миллионами клиентов (от сотен тысяч если быть точнее).
Реально, статья скорее для nag.ru чем для habrahabr — ибо требует детальных пояснений для большинства.
Один anycast чего стоит — это BGP, анонсирование сеток, multi-home, ограничение на UDP (ибо TCP с anycast дружит весьма отоносительно)…
Sign up to leave a comment.
Лучшие DNS практики для телекома