Как заставить systemd-resolved прекратить попытки использовать автономные DNS-серверы?

Я настроил свой DHCP-сервер для предоставления двух серверов имен для резервирования, поэтому, если один из них находится в автономном режиме, можно использовать другой.

Я настроил мои ПК с помощью systemd-resolved и в соответствии с resolvectl status он выбрал все DNS-серверы (адреса IPv4 и IPv6 для обоих) и использует один из них в качестве текущего.

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

Если я запускаю systemctl restart systemd-resolved он переключается на другой сервер и продолжает работать, но через некоторое время он случайно переключается обратно на автономный сервер, и разрешение имен снова не удается.

Как я могу сказать systemd-resolved прекратить использование автономного DNS-сервера и быстро переключиться на один из тех, о которых он знает?

journalctl показывает это только когда он переключается на использование автономного сервера:

 systemd-resolved[1985]: Using degraded feature set (UDP) for DNS server fdxx::x. systemd-resolved[1985]: Using degraded feature set (TCP) for DNS server fdxx::x. 

Рассматриваемый сервер полностью отключен, когда это происходит, и не отвечает на эхо-запросы.

2 Solutions collect form web for “Как заставить systemd-resolved прекратить попытки использовать автономные DNS-серверы?”

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

Это слишком важное решение, чтобы оставить решателю реализацию клиентов, чтобы сделать.

Хотя теоретически клиенты должны возвращаться ко 2-му DNS после сбоя 1-го, часто это не происходит по нескольким причинам. За годы моей карьеры я видел огромные сбои в полных сетях из-за людей, реализующих вещи, рассчитывающие на то, что клиентская операционная система достаточно умна.

Что вы обычно делаете, так это на самом деле то, что делают корневые серверы имен, а именно, создают DNS-кластеры, которые принимают виртуальные IP-адреса ваших DNS-серверов. Наиболее используемая технология для этого – DNS anycast. Вы можете попробовать и более простые архитектуры, такие как keepdalived.

Однако, что бы вы ни делали, я подчеркиваю, что не оставляю это решение на усмотрение клиента.

см. IPv4 Anycast с Linux и Quagga

Традиционной гарантией является создание нескольких DNS-серверов для данного сайта. Каждый DNS-клиент в сети настроен с IP-адресами каждого из этих серверов. Вероятность того, что все эти серверы выйдут из строя катастрофически, довольно мала, поэтому у вас есть запас прочности.

С другой стороны, многие средства распознавания заглушек используют только два DNS-сервера, что делает практически невозможным существенное географическое разброс в вашей топологии DNS. Решатели DNS-заглушки обычно используют первый из двух настроенных DNS-серверов исключительно. Следовательно, в итоге один сервер берет на себя всю загрузку запроса и один простаивает, ожидая сбоя. Не оптимально, но эй, это цена избыточности … верно? Это не должно быть.

Избыточность DNS и аварийное переключение – classический вариант использования anycast. Anycast – это концепция получения одного IP-адреса и его распределения между несколькими серверами, каждый из которых не знает о других. Корневые DNS-серверы DNS широко используют anycast.

PS. В прошлом я реализовал anycast DNS с iBGP и OSPF в двух ISP и в одном университете, с существенными улучшениями доступности службы DNS во время работы.

Использование нескольких серверов имен через DHCP для обеспечения отказоустойчивости, а не избыточности. Похоже, вы пытаетесь использовать несколько серверов имен в том смысле, что каждый клиент будет отслеживать, если сервер имен перестает отвечать на запросы, и прекращает его использование. Если вы действительно хотите такой тип поведения / дизайн, то вам нужно использовать это через сам DNS-сервер, DNS-клиенты, как правило, не могут этого достичь. Подход, который вы часто видите здесь, заключается в том, чтобы сделать ваш DNS-сервер HA (высокодоступным) по отношению к вышестоящим DNS-серверам, с которыми он разрешается.

Чтобы показать, почему это не сработает, посмотрите, как работает файл /etc/resolv.conf . Добавление нескольких серверов имен в DHCP даст каждому клиенту 2 записи в их файлах /etc/resolv.conf . Этот файл может предоставить только следующий механизм для обработки нескольких серверов имен:

man resolv.conf

  nameserver Name server IP address Internet address of a name server that the resolver should query, either an IPv4 address (in dot notation), or an IPv6 address in colon (and possibly dot) notation as per RFC 2373. Up to MAXNS (currently 3, see ) name servers may be listed, one per keyword. If there are multiple servers, the resolver library queries them in the order listed. If no nameserver entries are present, the default is to use the name server on the local machine. (The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made.) 

Это предложение гласит:

Если имеется несколько серверов, библиотека распознавателя запрашивает их в указанном порядке.

Средство распознавания ничего не делает для управления этим списком, оно слепо будет продолжать использовать этот список, начиная каждый раз с 1-й записи, затем 2-й и т. Д. Единственное, что вы можете сделать для управления им, это изменить время timeout , retries и rotate ,

Таймаут: п

задает количество времени, которое распознаватель будет ожидать ответа от удаленного сервера имен, прежде чем повторять запрос через другой сервер имен. Измеряется в
секунд, по умолчанию RES_TIMEOUT (в настоящее время 5, см.). Значение для этой опции молча ограничено до 30.

Попытки: п

устанавливает количество раз, которое распознаватель будет отправлять запрос на свои серверы имен, прежде чем отказаться и вернуть ошибку вызывающему приложению. По умолчанию используется RES_DFLRETRY (в настоящее время 2, см.). Значение для этой опции молча ограничено до 5.

вращаться

устанавливает RES_ROTATE в _res.options, что вызывает циклический выбор серверов имен из числа перечисленных. Это имеет эффект распространения нагрузки на запрос среди всех
перечисленные серверы, вместо того, чтобы все клиенты пробовали первый перечисленный сервер первым каждый раз.

Рекомендации

  • второй сервер имен в /etc/resolv.conf не найден wget
  • man resolv.conf
Linux и Unix - лучшая ОС в мире.