не все серверы имен просматриваются
В другом месте мне помогли советом по альтернативному методу для того же результата. Используя это, я написал следующее, что, кажется, работает достаточно для меня:
Settings=$(cat ~/tmp/YadWindow4SelectedSettings.txt)
{
echo 25
echo "#25%"
sleep 2
echo 50
echo "#50%"
sleep 2
echo 75
echo "#75%"
sleep 2
echo 100
echo "#100%"
} |
yad --progress --enable-log --log-on-top --log-expanded --auto-close --auto-kill --center --width=700 --image=$ICON --image-on-top --title="Loading..." --text="$Settings" --percentage=0
В DNS сообщение NXDOMAIN не является ошибкой. Это является или, по крайней мере, должно быть совершенно достоверной информацией о том, что запрашиваемый вами домен не существует. Ошибки могут быть чем-то вроде «я не знаю», или «мне не разрешено говорить вам», или «[мёртвая тишина до тайм-аута]».
В /etc/resolv.confпредполагается, что все сконфигурированные серверы имен равны. То есть предполагается, что все они имеют одинаковый доступ к информации DNS. :Все они должны иметь возможность разрешать любое имя, которое вам может понадобиться.
Если это не так, то традиционного стиля Unix -/etc/resolv.confбудет недостаточно. Многие пытались добиться того, что вы ищете, изменяя порядок DNS-серверов в файле, но все потерпели неудачу :, это просто не работает.
Вместо этого вам, как правило, потребуется настроить преобразователь/кэш/прокси DNS, который можно настроить с помощью некоторых правил, таких как «если имя, которое вам нужно разрешить, принадлежит одному из этих доменов, затем спросите один из этих серверов; если имя находится в том домене, то используйте тот сервер; а для всего остального используйте те серверы."
Например,вы можете настроить dnsmasqи написать что-то вроде этого вdnsmasq.conf:
no-resolv
server=/corporate-domain.com.example/10.1.2.3
rev-server=10.1.0.0/16,10.1.2.3
server=/google.com/8.8.8.8
server=9.9.9.9
Это означало бы:
- игнорировать
/etc/resolv.conf(для предотвращения образования петель) - использовать сервер имен 10.1.2.3 для разрешения любых имен в домене
corporate-domain.com.exampleи любых обратных запросов IP-адресов в сети 10.1.0.0/16 - используйте 8.8.8.8 для разрешения любых имен в домене
google.com - для всех остальных используйте 9.9.9.9.
После того, как вы настроили dnsmasqтаким образом, вы должны настроить /etc/resolv.confтолько с nameserver 127.0.0.1, чтобы перенаправить все локальные DNS-запросы на локальный dnsmasq.
Если ваш локальный сервер имен — BIND, вы можете сделать то же самое, используя объявления зоныtype forward:
zone "corporate-domain.com.example" {
type forward;
forwarders { 10.1.2.3; };
};
zone "1.10.in-addr.arpa" {
type forward;
forwarders { 10.1.2.3; };
};
zone "google.com" {
type forward;
forwarders { 8.8.8.8; 8.8.4.4; };
};
options {
forwarders { 9.9.9.9; };
forward only;
};
При этом достигаются те же результаты, что и в конфигурации dnsmasqвыше, но синтаксис конфигурации BIND немного более подробный.
В качестве альтернативы попытке изменить порядок DNS или аналогичным подходам:
Если вы контролируете VPN, вместо того, чтобы позволить клиенту решать, с каким DNS-сервером общаться (типа ), вы можете вместо этого перехватывать DNS-запросы через порт 53/UDP и порт 53/TCP и перенаправлять эти запросы. на DNS-сервер по вашему выбору.
Таким образом, находясь внутри VPN, вы можете заставить клиентов обращаться к DNS-серверу, способному разрешать корпоративные хосты.
Показательный пример :Раньше я администрировал пару VPN-серверов с примерно 400 сотнями пользователей BYOD VPN, которые использовали свои персональные компьютеры и телефоны.
Поскольку в нашей стране применяется цензура на уровне DNS, многие вручную добавляют 8.8.8.8 в качестве предпочтительных серверов DNS.
Как правило, симптомы этих пользователей заключались в том, что они не могли открыть корпоративные частные адреса.
У меня было несколько вариантов:
- либо служба поддержки убирала адрес 8.8.8.8, а пользователи вставляли их по желанию или по рассеянности, когда хотели посетить адрес из черного списка, и мы возвращались к исходной точке;
- ИЛИ я мог перехватывать DNS-вызовы в VPN, независимо от того, какие DNS-адреса они использовали, и перенаправлять DNS-запросы на адреса корпоративных DNS-серверов.