Iskatel_S Posted July 30, 2016 Posted July 30, 2016 Здравствуйте! Наверное надо было начала спрашивать, а потом экспериментировать, а то вчера крайне "весёлый" день сисадмина был - целый город сначала лёг, потом, после того как вернул всё назад - до конца дня тикеты закрывали. Вопрос, каким должен быть провайдерский DNS-сервер: кэширующим или некэширующим, какой нужно поставить срок хранения записей в кэше и нужно ли для отдельных доменов задавать особые настройки кэширования. Также вопрос, можно ли пользоваться функциями DNS в MikroTik RouterOS или лучше всё-таки поднимать bind? И с какими проблемами можно столкнуться, если все пакеты, идущие в 53 порт, буду заворачивать в провайдерский DNS? Вставить ник Quote
ipaddr.ru Posted July 30, 2016 Posted July 30, 2016 Как вы решили вопрос с DNSSEC при проксировании? Чем вас не устраивает базовая настройка рекурсивного сервера (expire time=TTL)? Вставить ник Quote
orlik Posted July 31, 2016 Posted July 31, 2016 Вопрос, каким должен быть провайдерский DNS-сервер: кэширующим или некэширующим, какой нужно поставить срок хранения записей в кэше и нужно ли для отдельных доменов задавать особые настройки кэширования. Также вопрос, можно ли пользоваться функциями DNS в MikroTik RouterOS или лучше всё-таки поднимать bind? И с какими проблемами можно столкнуться, если все пакеты, идущие в 53 порт, буду заворачивать в провайдерский DNS? Пока читал создалось ощущение что читаю описание какогото триллера Вставить ник Quote
pppoetest Posted July 31, 2016 Posted July 31, 2016 ДНС на микротике это не триллер, это хоррор. Bind, с ростом сети тоже не фонтан, рекомендую unbound. Вставить ник Quote
Iskatel_S Posted July 31, 2016 Author Posted July 31, 2016 с ростом сети Я догадываюсь, что нюанс как раз в этом. Абонентов немного, всего 1200. Причём абонентам ранее в качестве адреса DNS выдавался яндексовский 77.88.8.8 в качестве первого и наш на микротике в качестве второго. Я поменял их местами - сеть сразу легла, мне что абоненты его положили запросами? И про кэширование, может кто-нибудь ответить нужно или нет или дать ссылку на какую-нибудь авторитетную статью в этот вопросе. Вот я думаю, с одной стороны кэшировавние должно уменьшить время DNS-запросов у абонентов, с другой как же тогда быть с динамическими DNS-записями Вставить ник Quote
ipaddr.ru Posted July 31, 2016 Posted July 31, 2016 RFC1034, RFC1035. Концепция кэширования описана там, и разумно в неё не вмешиваться. Вставить ник Quote
mixae1 Posted July 31, 2016 Posted July 31, 2016 крайне "весёлый" день сисадмина был Я поменял их местами - сеть сразу легла, мне что абоненты его положили запросами? Ну как же так? День сисадмина отмечаете а традиции не чтите? Кто же в пятницу что-то меняет? По теме кеширующий DNS для абонентов, unbound подойдёт даже если в 10 раз вырастите. Настройки простые, статистики больше соберёте будет понятно что вообще происходит. Увидите что через DNS в том числе проходит очень много левых запросов, даже очень много. Если покопать то можно абонентов вычислять с вирусами, делать упреждения, повысить уровень сервиса. Собственно тема вот тут обсуждается http://forum.nag.ru/forum/index.php?showtopic=115871 Вставить ник Quote
pavel.odintsov Posted July 31, 2016 Posted July 31, 2016 Однозначно Unbound. И желательно не особо трогать стандартный конфиг :) Вставить ник Quote
vlad11 Posted August 1, 2016 Posted August 1, 2016 Только bind. Самый массовый и самый документированный. Вставить ник Quote
Ivan_83 Posted August 1, 2016 Posted August 1, 2016 Только bind. Самый массовый и самый документированный. Уху, на виндовс7 - самой массовой ос :) Вставить ник Quote
vlad11 Posted August 2, 2016 Posted August 2, 2016 Уху, на виндовс7 - самой массовой ос :) Так это десктопная ОС - для офисного ПО и игрушек :) Вставить ник Quote
SyJet Posted August 2, 2016 Posted August 2, 2016 Только bind. Самый массовый и самый документированный. Да ну нафиг, выкорчевал его ото всюду, кроме там, где центос еще 4 версии! Вставить ник Quote
Iskatel_S Posted August 10, 2016 Author Posted August 10, 2016 Сегодня узнал ещё об одной программе PDNSD https://habrahabr.ru/post/159013/ Как в хабростатье написано - даёт как раз ускорение DNS-запросов Вставить ник Quote
Ivan_83 Posted August 10, 2016 Posted August 10, 2016 Не епи моск и не читай швабр, ставь unbound. Они там сравнивали тёплое с зелёным: ответы от локального днс сервер с ответами от левых серверов где то в инете на неизвестно каком софте. Вставить ник Quote
st_re Posted August 11, 2016 Posted August 11, 2016 Сегодня узнал ещё об одной программе PDNSD https://habrahabr.ru/post/159013/ Как в хабростатье написано - даёт как раз ускорение DNS-запросов ну учитывая, что тема как настроить ПРОВАЙДЕРСКИЙ днс... то да, прокся к провайдерскому же ДНСу странное решение. Я правильно понимаю, что их бенчмалка сначала делала запросы к апстримам, нагоняла там кеш, а потом тестировала 127.0.0.1 и тот сразу получал ответы из заранее прогретого кеша у апсртимов ? нюню... :) Если вас не устраивают результаты тестов, смените тесты. В реальной жизни запросы к непопулярным ресурсам будут только замедляться, из за добавления лишней сущности, запросы же к популярным лучше сразу и отправлять тогда на 8.8.8.8. А то вы вместо 1 запроса на своем загруженном канале отправите 4. получите 4 ответа. что будет особенно заметно в случае заведения внутри ДНС ддосера генерящего рандомные запросы на скорости своего интерфейса. ну и увеличение времени ТТЛ... поможет разве что в нелегкой борьбе РКН с онлайн казино. они там давно IP сменили, а вы все так и долбитесь в выключеннную VPSку, или вообще к посторонним уже севшим на тот IP. Самый классный вариант был у меня когда через месяц после смены MXов на домен (TTL 1 час) через месяц ко мне достучался через ГМАЙЛ админ какойто и спросил че ко мне почта не ходит от него. Оказалось он все еще долбился в старый сервер. Такую вот свинью ему подложил его аплинк, чьим ресолвером он пользовался. зы +1 к unbound Вставить ник Quote
Iskatel_S Posted August 12, 2016 Author Posted August 12, 2016 ставь unbound. В реальной жизни запросы к непопулярным ресурсам будут только замедляться, из за добавления лишней сущности, запросы же к популярным лучше сразу и отправлять тогда на 8.8.8.8. А то вы вместо 1 запроса на своем загруженном канале отправите 4. получите 4 ответа. что будет особенно заметно в случае заведения внутри ДНС ддосера генерящего рандомные запросы на скорости своего интерфейса. ну и увеличение времени ТТЛ... поможет разве что в нелегкой борьбе РКН с онлайн казино. они там давно IP сменили, а вы все так и долбитесь в выключеннную VPSку, или вообще к посторонним уже севшим на тот IP. Самый классный вариант был у меня когда через месяц после смены MXов на домен (TTL 1 час) через месяц ко мне достучался через ГМАЙЛ админ какойто и спросил че ко мне почта не ходит от него. Оказалось он все еще долбился в старый сервер. Такую вот свинью ему подложил его аплинк, чьим ресолвером он пользовался. В реальной жизни клиент обращается сначала к a.root-servers.net, потом к a.dns.ripn.net, потом к ns1.nag.ru и только после этого он будет знать ip ресурса nag.ru, поправьте если не так. Допустим я делаю DNAT для всех запросов, идущих в 53 UDP порт и перенаправляю их на провайдерский сервер. Стоит это делать или нет? С одной стороны клиенты больше не будут обращаться к серверам, расположеным в Америке, запрос к которым будет идти долго - стало быть скорость DNS-запросов должна увеличиться. С другой стороны нужно вычислить сколько запросов в секунду будет в результате обрабатывать сервер и справится ли он. Число абонентов - 1000. Опять же откуда будет брать сервер записи для предоставления клиентам: из собственного кэша или перенаправлять запросы на корневые сервера? Вот вы говорите, что нужны разные политики для запросов к популярным и непопулярным ресурсам. Как их делить, что считать популярным, что нет? У популярных ресурсов IP никогда не меняется, зато у популярных высоконагруженных ресурсов может быть балансировка DNS Round Robin. У непопулярных ресурсов IP может меняться и из-за этого высокий TTL может стать причиной того, что в какой-то момент времени ресурсы могут быть недоступными для наших абонентов. Все эти нюансы мне хотелось бы решить прежде чем начать ставить новый DNS-сервер. Настройки unbound пока не смотрел, выше написали, что что лучше умолчальный конфиг сильно не трогать. Что в умолчальном конфиге нужно поменять? Вставить ник Quote
st_re Posted August 12, 2016 Posted August 12, 2016 В реальной жизни клиенты не занимаются ресолвом сами. они спрашивают у внешнего ресолвера. обычно провайдер такого ресолвера предоставляет. Именно это ресалвер ходит на корневые ИТД сервера. все топ левел зоны в кеше появятся очень быстро. поэтому для ресолва tralivalihrensgory.ru провайдеровский ресолвер не пойдет на корневые сервера, а пойдет сразу на RU. причем если вы перед ним поставите прокладку из той статьи, то в общем ничего не поменяется. Если домен непопулярный то ктото должен сходить на сервера зоны ру и спросить там, а потом сходить на выданные там NSы. и дождаться ответа. если запрос популярный то он скорее всего есть в кеше, что вашем, что не вашем. если он среднепопулярный, то на 8.8.8.8 он окажется в кеше с большей вероятностью чиста от того, что у них клиентов больше. Зато усилителем запроса в 4 раза оно сработает на ура. а настройки анбаунда лучше не трогать для начала. ip адрес куда биньдится прописать. Вставить ник Quote
Iskatel_S Posted August 12, 2016 Author Posted August 12, 2016 ip адрес куда биньдится прописать. Какой? 8.8.8.8 или DNS провайдера-аплинка? Есть ещё Яндекс - 77.88.8.8 Вставить ник Quote
Ivan_83 Posted August 12, 2016 Posted August 12, 2016 В реальной жизни клиент обращается сначала к a.root-servers.net, потом к a.dns.ripn.net, потом к ns1.nag.ru и только после этого он будет знать ip ресурса nag.ru, поправьте если не так. Клиенты вообще рекурсию не умеют делать. С одной стороны нафик нада, лишний код и всё такое, с другой более правильно обращаться к ближайшему серверу с кешем, который заодно и локальные имена знает которых в паблике нет. Какой? 8.8.8.8 или DNS провайдера-аплинка? Есть ещё Яндекс - 77.88.8.8 на 0.0.0.0:53 Только пропиши либо ACL в конфиге либо фаером с наружи закрой, а то будут тебя для усиления с дос атаке использовать и исходящий канал в полку положат днс запросами. Вставить ник Quote
Tamahome Posted August 19, 2016 Posted August 19, 2016 (edited) Поставьте PowerDNS Recursor. Особо настраивать нечего (за исключением базовой настройки и настройки сетевого стека ос,ну и iptables ) Использую его уже не у одного провайдера, по 50.000 абонентов на ширпотребном железе, работает годами и не давится. Edited August 19, 2016 by Tamahome Вставить ник Quote
zhenya` Posted August 22, 2016 Posted August 22, 2016 На прошлой работе были проблемы с резолвами через пднс-рекурсор. Unbound спас. Вставить ник Quote
alexpn Posted August 27, 2016 Posted August 27, 2016 (edited) долго юзал связку PowerDNS + unbound DNSSEC на unbound + тамже кеширование на PowerDNS + SQLITE + морда для доменов что хостятся + ACL для начальной проверки своих сеток морда NSADMIN Edited August 27, 2016 by alexpn Вставить ник Quote
Megas Posted September 6, 2016 Posted September 6, 2016 Народ, а может кто-то юзал такую связку: nginx в качестве балансировщика запросов, он кидает запросы на 3и сервера каждый из которых в контейнере unbound. При тестировании unbound напрямую дает порядка 400 запросов в секунду через dnsperf. Nginx запущен в однопоточном режиме, дает при тестах 450 запросов, запросы разливаются по всем 3ом серверам. Поднятие nginx до 8 потоков выдало всего 650 запросов и увы оказалось потолком, но при этом ресурсы сервера вполне свободные. Может кто может направить, как бы отловить узкое место в данной конфигурации или может кто-то пробовал у себя такую связку? Она выглядит более приятно чем отдельный процесс dns который может упасть или затупить. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.