16,10 сбоев для разрешения DNS

После обновления моего с 16.04 установками к 16,10, я испытываю затруднения из-за DNS.

Сначала я получил проблемы пару раз при соединении с WiFi, в то время как он работал над Ethernet. Теперь это, кажется, работает над WiFi также. Не уверенный, почему, и если это всегда связано с проблемой, я сталкиваюсь теперь:

Когда соединение с VPN размещает с Cisco Anyconnect VPN, оно добавляет строку в '/etc/resolv.conf'. Я понимаю, что Ubuntu теперь использует systemd-твердость, и в странице справочника говорится, что существует три различных режима для обработки/etc/resolv.conf. Мой/etc/resolv.conf не является символьной ссылкой и не перечисляет 127.0.0.53 как сервер DNS, поэтому насколько я понимаю systemd-разрешенный, должен "считать его для данных конфигурации DNS". Однако это, кажется, не заботится об этом.

вырыть

Странная вещь (для меня) является этим dig host.customer.tld, дает хороший ответ с РАЗДЕЛОМ ОТВЕТА, показывающим IP требуемого хоста, и он относится к серверу DNS, добавленному к/etc/resolv.conf клиентом VPN как СЕРВЕР. Когда соединение VPN отключено, я не получаю ответа. Т.е. выройте чтения/etc/resolv.conf.

ping

Браузер, с другой стороны, не добирается до/etc/resolv.conf и не может разрешить имя хоста. Ни один не ping/завихрение, между прочим.

nmcli

Я нашел связанное сообщение и попытался работать

nmcli device show <interfacename> | grep IP4.DNS

но это не перечисляет DNS для cscotun0 устройства. (Это не делает в 16,04 ни один, все же.) Кроме того, nmcli перечисляет мой dhcp сервер (мой маршрутизатор) как IP4. Хост DNS для моих eth/wlan соединений. Используя dig @192.168.0.1 xxx поскольку любое общественное достояние хорошо работает.

конфигурация

Существуют некоторые другие серверы DNS, перечисленные в моем/run/systemd/resolve/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:4860:4860::8844

Они не подаются моим сервером DHCP. файл/etc/systemd/resolved.conf содержит только прокомментированные строки, кроме заголовка раздела:

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

В странице справочника для resolved.conf говорится это

DNS = разделенный пробелом список IPv4 и адресов IPv6 для использования в качестве системы серверов DNS.... По причинам совместимости, если эта установка не указана, используются серверы DNS, перечисленные в/etc/resolv.conf вместо этого, если тот файл существует, и любые серверы настроены в нем. Эта установка значения по умолчанию к пустому списку.

FallbackDNS = разделенный пробелом список IPv4 и адресов IPv6 для использования в качестве нейтрализации серверов DNS. Любые серверы DNS на ссылку, полученные из systemd-networkd.service (8), имеют приоритет по этой установке, также, как и любой набор серверов через DNS = выше или/etc/resolv.conf. Эта установка следовательно только используется, если никакая другая информация о сервере DNS не известна. Если эта опция не дана, скомпилированный - в списке серверов DNS используется вместо этого.

Кажется, что нейтрализация заканчивается в/run/systemd/resolve/resolv.conf в моем случае.

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

34
задан 13 April 2017 в 05:24

4 ответа

Я испытал подобные проблемы, например, с добавлением дополнительного аппаратного ключа Wi-Fi USB. Сначала я отключил dnsmasq в networkmanager, как описано выше, и я остановил dnsmasq (сервис dnsmasq остановка)

, я заметил, что, когда разрешение повредилось во время моего соединения VPN, таблица маршрутизации выглядит немного отличающейся (вывод команды маршрута). Название Шлюза является DD-WRT в случае, это не работает и просто 'шлюз', когда это действительно работает. Вывод этого не изменился:

nmcli device show wlp1s0 | grep IP4.DNS

Это продолжало показывать мой IP маршрутизатора. Обходное решение, чтобы заставить это работать некоторое время должно перезапустить systemd-resolvd:

sudo service systemd-resolved restart

, Так как dnsmasq вне уравнения, это - или systemd-resolvd, который является причиной проблемы или чего-либо изменяющего таблицу маршрутизации.

, Таким образом, это - единственная разница, которую я вижу:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    601    0        0 

, который работает. И это, когда это НЕ работает:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         DD-WRT          0.0.0.0         UG    601    0        0 wlp1s0

И то же различие в имени на строке VPN:

vpn-dns.name gateway         255.255.255.255 UGH   0      0        0 wlp1s0

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

[обновление] кажется, что systemd-разрешенная остановка может зафиксировать это и не негативно повлиять на другой материал. Можно попробовать это и сообщить ему, если это действительно повреждает материал. Я видел при выполнении systemd-resolvd в отладке, когда она повредилась:

Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *

Для отключения:

sudo systemctl disable systemd-resolved.service

я обновил отчет Ubuntu с предложениями. [/обновление] Добавьте:Примечание: отчет об ошибках: https://bugs.launchpad.net/ubuntu / + source/systemd / + ошибка/1624317 имеет патч для 17,04 для некоторых проблем. Проверьте отчет об ошибках и если возможный тест патч.Спасибо!

[обновление]

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

[/обновление]

15
ответ дан 23 November 2019 в 00:29

Поведение DNS во время соединения OpenVPN улучшилось сразу, когда я следовал предложение на ubuntuforums:

  1. Открывают /etc/NetworkManager/NetworkManager.conf в редакторе с корневыми правами.
  2. Удаляют (или прокомментируйте с хешем #), строка, которая читает dns=dnsmasq
  3. Перезапуск NetworkManager через sudo service NetworkManager restart
36
ответ дан 23 November 2019 в 00:29

Столкнулся с той же проблемой. Так или иначе я, должно быть, установил DNSmasq с некоторым приложением. Просто удаление dnsmasq решило проблему для меня.

sudo apt-get remove dnsmasq 

С тех пор, больше никаких разъединений или некоторые сайты, не бывшие способные больше загружаться (у меня был Gmail загрузки проблемы, т.е. все внезапные, которые он не мог подключить к Gmail, хотя другие сайты работали).

3
ответ дан 23 November 2019 в 00:29

Редактирование /etc/nsswitch.conf и изменение

hosts:          files mdns4_minimal [NOTFOUND=return] dns

к

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Редактирование:

я получил те же проблемы в течение достаточно долгого времени. Я смог разрешить доменные имена от vpn, но я не смог проверить с помощью ping-запросов или завихриться они или использовать их в других приложениях. Описанное изменение выше решило его для меня.

1
ответ дан 23 November 2019 в 00:29

Другие вопросы по тегам:

Похожие вопросы: