Нет поиска DNS с DNS-серверами Google

Иногда по утрам, когда мой Ubuntu 18.04 выходит из спящего режима, мне требуется около 30 минут, прежде чем я смогу выполнить поиск в DNS.

Я уже отключил автоматический DNS и вместо этого добавил DNS-серверы Google:

Но тем не менее я могу пинговать 8.8.8.8 но нет google.com:

Обычно после долгого бесплодного включения / выключения Wi-Fi, а также подключения и отключения сетей Wi-Fi он внезапно срабатывает, и до конца дня все хорошо.

Но вот загадка: если Ubuntu использует 8.8.8.8 в качестве поиска DNS, как может быть так, что я могу пинговать IP, но не URL?

копать землю

Вот результат dig:

       ➜  dig @8.8.8.8 www.google.com

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @8.8.8.8 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39427
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         297     IN      A       216.58.206.100

;; Query time: 21 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Aug 20 19:52:43 BST 2020
;; MSG SIZE  rcvd: 59

tcpdump

       sudo tcpdump -ni lo port 53

Эта команда ничего не показывала примерно через 20 минут после загрузки, после чего она воплотилась в жизнь такими вещами, как:

netstat

       netstat -acpn | grep ":53"

Это результат netstat когда поиск DNS не работает.

И с работающим DNS днем ​​позже:

Источник

5 ответов

Пытаться

dig @8.8.8.8 www.ubuntu.com

просто чтобы исключить искажение трафика DNS.

edit: dig - это инструмент для запроса DNS-серверов. Используя синтаксис @serverIP, вы можете обойти системные настройки DNS и напрямую поговорить с DNS-сервером по вашему выбору. IMHO, это очень помогает в диагностике, если проблема в вашей машине (копайте с @syntax работая) или на стороне сети (копайте с @syntax, возвращающим тот же результат)

Источник

Мне удалось обойти эту проблему, заставив resolvedиспользовать определенный DNS-сервер.

Раньше мой был связан с /run/systemd/resolve/stub-resolv.conf:

      $ l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Mar 30 10:32 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Это содержало следующее:

      nameserver 127.0.0.53
options edns0

(Также есть много комментариев о том, как файл генерируется автоматически, а не возиться с ним вручную. Я не знаю, как он так сгенерировался.)

Поэтому я создал отдельный resolv.confфайл, с:

      nameserver 8.8.8.8
options edns0

и заменил мою символическую ссылку. Затем перезапустил службу с помощью:

      sudo systemctl restart systemd-resolved

и вдруг все ожило.

Источник

вам не нужно диктовать адрес DNS. Поскольку переключатель DNS переключен на автоматический, вы можете оставить это поле пустым.

Источник

Это может быть связано с конфликтами между старой системой (ifupdown) и новой системой (netplan,cloud-init и т. Д.). Единственно правильный ответ, который я смог найти на эту современную чушь, заключался в следующем:

apt remove ifupdown
apt install cloud-init
# comment out settings in /etc/network/interfaces
# complete settings in /etc/netplan/config.yaml

# Apply settings or reboot
netplan apply

Удаление ifupdown необходим для правильной работы DNS-преобразователя.

[nb: мой исходный пост здесь: https://Ask-ubuntu.ru/a/1255405/45849]

Источник

Вы пробовали отключить systemd-resolved, а затем проверить, как работает разрешение? У меня были проблемы с этим в прошлом.

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved

Затем в разделе [main] вашего /etc/NetworkManager/NetworkManager.conf

dns=default

Удалить символическую ссылку на resolv.conf

rm /etc/resolv.conf

А затем перезапустите

sudo systemctl restart NetworkManager
Источник
Другие вопросы по тегам