Проблема DNS (не удается найти хост) исправлена с помощью адреса host -a - что это значит?
У меня была проблема, которую я не могу объяснить своим ограниченным пониманием того, «как все работает». Я подключаюсь к различным серверам (я буду использовать svn.mycompany.com в качестве примера) для работы. Мы используем openvpn для создания безопасного соединения с этими серверами. Компания имеет OpenDNS, настроенный для обеспечения обычного разрешения для серверов, и результирующие адреса, конечно, работают только через установленный VPN-туннель.
Через некоторое время после некоторой безобидной реконфигурации некоторых серверов (не сделанной мной и, очевидно, работающей для всех остальных), я заметил следующую закономерность. У меня есть VPN-туннель, и я пробую команду svn:
svn update
Я немедленно получаю сообщение об ошибке, что хост svn.mycompany.com не может быть разрешен. Если я тогда выполню поиск host:
host -a svn.mycompany.com
, который ответит правильным IP-адресом. Если я затем снова попробую команду svn, она будет работать, и svn будет работать некоторое время. Однако через некоторое время он перестает работать, и цикл повторяется.
Тот же шаблон применяется для других серверов на другой стороне туннеля. Я видел, как это происходило в разных сетях (т. Е. У меня дома, в кафе и т. Д.).
Я не ищу общее решение. Мой реальный вопрос: как получается, что простой запуск host -a может, по крайней мере, временно «исправить» ситуацию, когда домен не разрешается? host делает что-то особенное, чтобы обойти локальный кеш? (Если так, я все еще в замешательстве, потому что адреса серверов не меняются или меняются редко.)
edit - ОК, больше информации. Включив ведение журнала для systemd-resolved, я смог использовать journalctl для отслеживания того, что моя локальная машина делает с поисками DNS. То, что я увидел, кажется интересным, но я все еще не знаю достаточно, чтобы понять, что это означает: запросы поиска DNS типа запроса ANY, кажется, переполняют размер пакета UDP, поэтому systemd-resolved возвращается к выполнению запроса TCP. Для обычного не ANY поиска по этим foo.mycompany.com именам я не получаю переполнение пакета, но он продолжает делать NODATA запись локального кэша.
Когда запросы ANY вынуждают откат TCP, systemd-resolved получает полезный результат и делает положительную запись в кеше.
Для меня это означает, что с ответами UDP происходит что-то странное, но я не знаю, что это означает о первопричине.