Исходная диспозиция

В локальной сети используется локальный 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)


  1. max9
    18.07.2025 08:36

    а я правильно понял, что dnslist безусловно разрешает рекурсию и надо быть аккуратнее с setLocal("0.0.0.0:53") не повесив это все в интернет?


    1. JBFW Автор
      18.07.2025 08:36

      Разумеется это не должно висеть в интернет.


  1. aborouhin
    18.07.2025 08:36

    После нескольких случаев внезапных "поломок" DNS я теперь к корневым серверам хожу со своего DNS-сервера, без всяких гугловских или, упаси Боже, провайдерских серверов. А маршрутизацию запросов unbound из коробки умеет (да и простейший dnsmasq тоже, ЕМНИП). Немного сложнее становится когда серверов заводишь два (а это нынче полезно, иметь по своему DNS по обе стороны железного занавеса границы), тут у unbound встроенных механизмов синхронизации не хватает, приходится добавлять костыли.


    1. martin74ua
      18.07.2025 08:36

      А потом у вас заканчиваются деньги на счету, и вы даже не можете увидеть страничку провайдера с уведомлением об этом... Потому что провайдер пускает вас только на свои сервера, а всякие гугл сервера и ваши - просто недоступны...
      Как же утомили вот такие настройщики )


      1. JBFW Автор
        18.07.2025 08:36

        У вас единственный канал выхода в интернет? Это зря )


        1. martin74ua
          18.07.2025 08:36

          у меня? нет. У большинства клиентов - да. В домашнем инете все таки несколько провайдеров не такая уж и распространненая практика....


          1. JBFW Автор
            18.07.2025 08:36

            Если человек может настроить себе собственный днс-сервер - он может настроить на нем и адрес сайта провайдера. Или прописать hosts


          1. Devastator82
            18.07.2025 08:36

            Стоит ли считать, что у современных людей имеющих дома 1-го провайдера при этом нет доступа к мобильному интернету?


      1. aborouhin
        18.07.2025 08:36

        Какой из моих провайдеров, простите? Я в интернет выхожу из кучи разных точек, во всех более или менее важных есть резерв (оптика + мобильный модем в роутере как минимум), ну и, в конце концов, мобильный интернет на телефоне никто не отменял. Баланс счёта у всех провайдеров мониторит Prometheus (писать скрипты для парсинга ЛК в паре случаев было нетривиальной задачкой :), алерты прилетают заблаговременно. И даже в том маловероятном случае, если уж я совсем всё просплю и всё отвалится, мне точно не доставит труда за минуту понять, в чём проблема, и справиться с ней.

        Какие-то у Вас надуманные опасения, короче. Для кого это проблема - тот свой DNS-сервер не поднимает.


    1. inkvizitor68sl
      18.07.2025 08:36

      А у меня вот у одного из провайдеров DNS сломан как-то странно, ответы от корневых серверов возвращаются какие-то не такие, как будто бы от какого-то другого DNS-сервера, в итоге все утилиты и рекурсоры считают такие ответы невалидными...