Перейти к содержимому
Калькуляторы

Как правильно настраивать провайдерский DNS

Здравствуйте!

Наверное надо было начала спрашивать, а потом экспериментировать, а то вчера крайне "весёлый" день сисадмина был - целый город сначала лёг, потом, после того как вернул всё назад - до конца дня тикеты закрывали.

Вопрос, каким должен быть провайдерский DNS-сервер: кэширующим или некэширующим, какой нужно поставить срок хранения записей в кэше и нужно ли для отдельных доменов задавать особые настройки кэширования. Также вопрос, можно ли пользоваться функциями DNS в MikroTik RouterOS или лучше всё-таки поднимать bind? И с какими проблемами можно столкнуться, если все пакеты, идущие в 53 порт, буду заворачивать в провайдерский DNS?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как вы решили вопрос с DNSSEC при проксировании? Чем вас не устраивает базовая настройка рекурсивного сервера (expire time=TTL)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Вопрос, каким должен быть провайдерский DNS-сервер: кэширующим или некэширующим, какой нужно поставить срок хранения записей в кэше и нужно ли для отдельных доменов задавать особые настройки кэширования. Также вопрос, можно ли пользоваться функциями DNS в MikroTik RouterOS или лучше всё-таки поднимать bind? И с какими проблемами можно столкнуться, если все пакеты, идущие в 53 порт, буду заворачивать в провайдерский DNS?

Пока читал создалось ощущение что читаю описание какогото триллера

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ДНС на микротике это не триллер, это хоррор. Bind, с ростом сети тоже не фонтан, рекомендую unbound.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

с ростом сети

Я догадываюсь, что нюанс как раз в этом. Абонентов немного, всего 1200. Причём абонентам ранее в качестве адреса DNS выдавался яндексовский 77.88.8.8 в качестве первого и наш на микротике в качестве второго. Я поменял их местами - сеть сразу легла, мне что абоненты его положили запросами?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

RFC1034, RFC1035. Концепция кэширования описана там, и разумно в неё не вмешиваться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

крайне "весёлый" день сисадмина был

Я поменял их местами - сеть сразу легла, мне что абоненты его положили запросами?

Ну как же так? День сисадмина отмечаете а традиции не чтите? Кто же в пятницу что-то меняет?

 

По теме кеширующий DNS для абонентов, unbound подойдёт даже если в 10 раз вырастите. Настройки простые, статистики больше соберёте будет понятно что вообще происходит. Увидите что через DNS в том числе проходит очень много левых запросов, даже очень много. Если покопать то можно абонентов вычислять с вирусами, делать упреждения, повысить уровень сервиса.

 

Собственно тема вот тут обсуждается http://forum.nag.ru/forum/index.php?showtopic=115871

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Однозначно Unbound. И желательно не особо трогать стандартный конфиг :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только bind. Самый массовый и самый документированный.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только bind. Самый массовый и самый документированный.

Уху, на виндовс7 - самой массовой ос :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уху, на виндовс7 - самой массовой ос :)

Так это десктопная ОС - для офисного ПО и игрушек :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только bind. Самый массовый и самый документированный.

Да ну нафиг, выкорчевал его ото всюду, кроме там, где центос еще 4 версии!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня узнал ещё об одной программе PDNSD

https://habrahabr.ru/post/159013/

Как в хабростатье написано - даёт как раз ускорение DNS-запросов

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не епи моск и не читай швабр, ставь unbound.

Они там сравнивали тёплое с зелёным: ответы от локального днс сервер с ответами от левых серверов где то в инете на неизвестно каком софте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня узнал ещё об одной программе 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ставь 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 пока не смотрел, выше написали, что что лучше умолчальный конфиг сильно не трогать. Что в умолчальном конфиге нужно поменять?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В реальной жизни клиенты не занимаются ресолвом сами. они спрашивают у внешнего ресолвера. обычно провайдер такого ресолвера предоставляет. Именно это ресалвер ходит на корневые ИТД сервера. все топ левел зоны в кеше появятся очень быстро. поэтому для ресолва tralivalihrensgory.ru провайдеровский ресолвер не пойдет на корневые сервера, а пойдет сразу на RU. причем если вы перед ним поставите прокладку из той статьи, то в общем ничего не поменяется. Если домен непопулярный то ктото должен сходить на сервера зоны ру и спросить там, а потом сходить на выданные там NSы. и дождаться ответа. если запрос популярный то он скорее всего есть в кеше, что вашем, что не вашем. если он среднепопулярный, то на 8.8.8.8 он окажется в кеше с большей вероятностью чиста от того, что у них клиентов больше. Зато усилителем запроса в 4 раза оно сработает на ура.

 

а настройки анбаунда лучше не трогать для начала. ip адрес куда биньдится прописать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ip адрес куда биньдится прописать.

Какой? 8.8.8.8 или DNS провайдера-аплинка? Есть ещё Яндекс - 77.88.8.8

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поставьте PowerDNS Recursor. Особо настраивать нечего (за исключением базовой настройки и настройки сетевого стека ос,ну и iptables )

Использую его уже не у одного провайдера, по 50.000 абонентов на ширпотребном железе, работает годами и не давится.

Изменено пользователем Tamahome

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

unbound - аналогично.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На прошлой работе были проблемы с резолвами через пднс-рекурсор. Unbound спас.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

долго юзал связку PowerDNS + unbound

DNSSEC на unbound + тамже кеширование

 

на PowerDNS + SQLITE + морда для доменов что хостятся + ACL для начальной проверки своих сеток

морда NSADMIN

Изменено пользователем alexpn

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Народ, а может кто-то юзал такую связку:

 

nginx в качестве балансировщика запросов, он кидает запросы на 3и сервера каждый из которых в контейнере unbound.

 

При тестировании unbound напрямую дает порядка 400 запросов в секунду через dnsperf.

Nginx запущен в однопоточном режиме, дает при тестах 450 запросов, запросы разливаются по всем 3ом серверам.

Поднятие nginx до 8 потоков выдало всего 650 запросов и увы оказалось потолком, но при этом ресурсы сервера вполне свободные. Может кто может направить, как бы отловить узкое место в данной конфигурации или может кто-то пробовал у себя такую связку?

Она выглядит более приятно чем отдельный процесс dns который может упасть или затупить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.