我进行过相当广泛的搜索，但似乎无法找到解决此问题的大海捞针。
我有一台运行 Ubuntu 18.04 的服务器
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic
我目前在服务器上运行 LXC/LXD，只有一个容器，实际上是一个 16.04 映像。DNS 在容器内工作正常。我相信这消除了任何潜在的网络问题。
在 18.04 安装中使用 nslookup 时会发生以下情况
nslookup google.com
;; connection timed out; no servers could be reached
但是，当直接包含 DNS 服务器时，我可以进行查找。再次排除防火墙/网络问题
nslookup google.com 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: google.com
Address: 172.217.5.238
Name: google.com
Address: 2607:f8b0:4006:802::200e
作为以下提示/技巧/指南的一部分，我尝试了以下一些方法，以及可能有助于解决这个问题的各种输出。
我修改了以下文件，使其看起来像这样。我只添加了名称服务器。我按照其中一个修复程序进行了此操作。
$ cat /etc/netplan/50-cloud-init.yaml
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: <redacted for post>
set-name: ens3
nameservers:
addresses: [8.8.4.4, 8.8.8.8, 1.1.1.1, 1.1.0.0]
这似乎确实将 DNS 服务器添加到了设备
sudo systemd-resolve --status
Global
DNS Domain: openstacklocal
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 5 (vethTR4JCU)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (lxdbr0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 2 (ens3)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 8.8.4.4
8.8.8.8
1.1.1.1
1.1.0.0
<redacted for post>
DNS Domain: openstacklocal
即使那里列出了 DNS 服务器，也无法使用 dig 或 nslookup 进行查找。
我确实按照指南安装了 resolvconf，但我认为这是不必要的，而且只会造成更大的混乱。
$ ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Jan 29 12:55 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
search openstacklocal
这是我似乎能得到的全部信息。如果我将有效的名称服务器（8.8.8.8、8.8.4.4、1.1.1.1 等）添加到 /run/resolveconf/resolv.conf 文件：
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
nameserver 8.8.8.8 # manually added in for testing
search openstacklocal
我可以让查找按如下所示进行工作。如果按照文件中所述，则这些更改将在重新启动时被覆盖。
nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 172.217.15.78
Name: google.com
Address: 2607:f8b0:4004:810::200e
编辑：应用命令的输出
sudo netplan --debug apply
** (generate:15710): DEBUG: 14:11:34.829: Processing input file /etc/netplan/50-cloud-init.yaml..
** (generate:15710): DEBUG: 14:11:34.830: starting new processing pass
** (generate:15710): DEBUG: 14:11:34.878: ens3: setting default backend to 1
** (generate:15710): DEBUG: 14:11:34.879: Generating output files..
** (generate:15710): DEBUG: 14:11:34.879: NetworkManager: definition ens3 is not for us (backend 1)
DEBUG:netplan generated networkd configuration exists, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:ens3 not found in {}
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets:
ens3:
dhcp4: true
match:
macaddress: <redacted for post>
nameservers:
addresses:
- 8.8.4.4
- 8.8.8.8
- 1.1.1.1
- 1.1.0.0
set-name: ens3
vlans: {}
wifis: {}
DEBUG:Skipping non-physical interface: lo
DEBUG:device ens3 operstate is up, not changing
DEBUG:Skipping non-physical interface: lxdbr0
DEBUG:Skipping non-physical interface: vethTR4JCU
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for ens3
DEBUG:netplan triggering .link rules for lxdbr0
DEBUG:netplan triggering .link rules for vethTR4JCU
编辑：要求
sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- lxdbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 /* generated for LXD network lxdbr0 */
0 0 ACCEPT udp -- lxdbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 /* generated for LXD network lxdbr0 */
0 0 ACCEPT udp -- lxdbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 /* generated for LXD network lxdbr0 */
0 0 ACCEPT tcp -- ens3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8443 /* allow connection to lxd */
2336 152K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
1 60 ACCEPT tcp -- lxdbr0 * 10.100.106.40 0.0.0.0/0 tcp dpt:22
1279 73342 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
8207 2604K ACCEPT all -- * lxdbr0 0.0.0.0/0 0.0.0.0/0 /* generated for LXD network lxdbr0 */
9496 3318K ACCEPT all -- lxdbr0 * 0.0.0.0/0 0.0.0.0/0 /* generated for LXD network lxdbr0 */
Chain OUTPUT (policy ACCEPT 70 packets, 8606 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * lxdbr0 0.0.0.0/0 0.0.0.0/0 tcp spt:53 /* generated for LXD network lxdbr0 */
0 0 ACCEPT udp -- * lxdbr0 0.0.0.0/0 0.0.0.0/0 udp spt:53 /* generated for LXD network lxdbr0 */
0 0 ACCEPT udp -- * lxdbr0 0.0.0.0/0 0.0.0.0/0 udp spt:67 /* generated for LXD network lxdbr0 */
有人知道这个问题的链接/解决方案吗？我很困惑。
答案1
TL;DR：允许端口 53 tcp 和 udp 到 lo 接口。
尽管 INPUT 的默认策略是 ACCEPT，但还有一条最终规则会丢弃任何尚未接受的内容。唯一接受端口 53 上流量的规则是在 lxdbr0 接口上。您可以全面允许lo接口上的所有内容，或者仅根据需要允许端口。
要推动一条规则以允许 lo 接口上的所有内容优先于其他规则：
iptables -I INPUT 1 -i lo -j ACCEPT
答案2
坦白说，对这个现代婊子来说唯一正确的答案是：
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 解析器正常运行。
答案3
从 16.04 升级到 18.04 时，我遇到了同样的问题。尝试了上述方法以及许多其他围绕 resolv.conf 的解决方案。
真正的罪魁祸首：POSTFIX。不知何故，postfix 干扰了我的 DNS 配置。使用 --auto-remove 删除 postfix 后，DNS 奇迹般地又开始解析了。
我现在可以再次 ping 和 apt-get。真是美好的一天 :)
答案4
更改为 NetPlan 配置后。运行
sudo netplan apply
展开更改。要评估更改，请执行：
sudo netplan --debug apply
更新更多信息。
我有这个文件配置：/etc/netplan/01-netcfg.yaml
您输入的参数是正确的。为什么不试试呢：
sudo mv /etc/netplan/50-cloud-init.yaml /etc/netplan/01-netcfg.yaml
PS：请做好备份。