Исходная диспозиция
В локальной сети используется локальный named для того, чтобы задать имена для локальных серверов. Все остальные запросы форвардятся на DNS-сервер провайдера и на сервер Гугля.
Ну, можно сказать, стандартная ситуация.
Но несколько дней назад внезапно некоторые внешние DNS-имена перестали ресолвится, вообще. При этом DNS-сервер от Гугля вообще перестал быть доступен.
Однако точно такой же named на удаленном сервере продолжал работать как обычно.
Простое сопоставление A и B как бы намекает, что у местного провайдера что-то сломалось.
-- Это ж-ж-ж неспроста! - сказала паранойя - надо что-то делать!
Если сервер у провайдера ломается, а сервер Гугля внезапно устаревает - надо решать проблему иначе.
Разделение
Итак, у нас три категории доменных имен:
-- локальные
-- те, которые вряд ли будут ломаться
-- все остальные
Первые, как и раньше, можем определять на локальном named, вторые - отдаем провайдеру, а третьи придется разбирать на удаленном сервере, через резервный канал связи.
Для этого используем балансировщик DNS-запросов dnsdist:
sudo apt install dnsdist
Устанавливаем его на локальном DNS-сервере в дополнение к имеющемуся named.
Разумеется, он не запускается, т.к. 53 порт уже занят - поэтому переносим named на другой порт и отключаем там всё лишнее:
vim /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
listen-on port 5300 { 127.0.0.1; };
allow-query { any; };
recursion no;
forwarders { };
dnssec-validation no;
};
Затем настраиваем dnsdist:
vim /etc/dnsdist/dnsdist.conf
setSecurityPollSuffix("")
setLocal("0.0.0.0:53")
newServer({address="127.0.0.1:5300", pool="local_pool"})
newServer({address="provider_ip:53", pool="ru_pool"})
newServer({address="remote_ip:53", pool="world_pool"})
addAction(makeRule("dbase.local."), PoolAction("local_pool"))
addAction(makeRule("ru."), PoolAction("ru_pool"))
addAction(AllRule(), PoolAction("world_pool"))
И всё это перезапускаем. Для начала можно перезапустить только named:
/etc/init.d/named restart
Он уходит на порт 5300, и по порту 53 больше недоступен. Можно проверить его работу там:
dig @127.0.0.1 -p 5300 dbase.local
Должен вернуть локальный IP, определенный в named для этого сервера (предполагается что он там уже был раньше настроен, см. исходную диспозицию)
Теперь можно запустить dnsdist в отладке:
dnsdist -v
И попытаться что-то поискать:
dig ya.ru
dig microsoft.com
dig dbase.local
В консольном выводе dnsdist должно быть видно, куда распределяются разные запросы.
Локальное имя - на локальный сервер, *.ru - к провайдеру, остальное - на удаленный named.
Остается перезапустить и его:
/etc/init.d/dnsdist start
В общем, задача вроде бы решена. Теперь сломанный сервер провайдера не будет мешать работе, и заодно мы избавим его от лишней нагрузки.
Остается проблема работоспособности резервного канала связи к удаленному серверу, но у нее много своих, отдельных решений...
Комментарии (10)
aborouhin
18.07.2025 08:36После нескольких случаев внезапных "поломок" DNS я теперь к корневым серверам хожу со своего DNS-сервера, без всяких гугловских или, упаси Боже, провайдерских серверов. А маршрутизацию запросов unbound из коробки умеет (да и простейший dnsmasq тоже, ЕМНИП). Немного сложнее становится когда серверов заводишь два (а это нынче полезно, иметь по своему DNS по обе стороны
железного занавесаграницы), тут у unbound встроенных механизмов синхронизации не хватает, приходится добавлять костыли.martin74ua
18.07.2025 08:36А потом у вас заканчиваются деньги на счету, и вы даже не можете увидеть страничку провайдера с уведомлением об этом... Потому что провайдер пускает вас только на свои сервера, а всякие гугл сервера и ваши - просто недоступны...
Как же утомили вот такие настройщики )JBFW Автор
18.07.2025 08:36У вас единственный канал выхода в интернет? Это зря )
martin74ua
18.07.2025 08:36у меня? нет. У большинства клиентов - да. В домашнем инете все таки несколько провайдеров не такая уж и распространненая практика....
JBFW Автор
18.07.2025 08:36Если человек может настроить себе собственный днс-сервер - он может настроить на нем и адрес сайта провайдера. Или прописать hosts
Devastator82
18.07.2025 08:36Стоит ли считать, что у современных людей имеющих дома 1-го провайдера при этом нет доступа к мобильному интернету?
aborouhin
18.07.2025 08:36Какой из моих провайдеров, простите? Я в интернет выхожу из кучи разных точек, во всех более или менее важных есть резерв (оптика + мобильный модем в роутере как минимум), ну и, в конце концов, мобильный интернет на телефоне никто не отменял. Баланс счёта у всех провайдеров мониторит Prometheus (писать скрипты для парсинга ЛК в паре случаев было нетривиальной задачкой :), алерты прилетают заблаговременно. И даже в том маловероятном случае, если уж я совсем всё просплю и всё отвалится, мне точно не доставит труда за минуту понять, в чём проблема, и справиться с ней.
Какие-то у Вас надуманные опасения, короче. Для кого это проблема - тот свой DNS-сервер не поднимает.
inkvizitor68sl
18.07.2025 08:36А у меня вот у одного из провайдеров DNS сломан как-то странно, ответы от корневых серверов возвращаются какие-то не такие, как будто бы от какого-то другого DNS-сервера, в итоге все утилиты и рекурсоры считают такие ответы невалидными...
max9
а я правильно понял, что dnslist безусловно разрешает рекурсию и надо быть аккуратнее с
setLocal("0.0.0.0:53")
не повесив это все в интернет?JBFW Автор
Разумеется это не должно висеть в интернет.