127.0.0.53に愛されているsystemdのDNSは、ローカルマシンを名前で照会する場合を除いて機能しているようです。しかし、それらを照会し、ローカルDNSサーバー(ルーター)を具体的に指定すると、適切な応答が返されます。しかし、構成ファイルには、ルーターを検索アドレスとしても使用していると書かれています。何かご意見は?
デルのラップトップでUbuntu 18.04を実行しています。
誤った結果:
$ nslookup web1
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find web1: SERVFAIL
また失敗する
$ nslookup -i wlp3s0 web1
nslookup: couldn't get address for 'web1': not found
正しい結果:
$ nslookup web1 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Name: web1
Address: 192.168.1.107
構成情報systemd-resolve
$ systemd-resolve --status
Global
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 3 (wlp3s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.1.1
DNS Domain: wp.comcast.net
Link 2 (enp2s0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
構成情報NetworkManager
$ cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[device]
wifi.scan-Rand-mac-address=no
Nslookupを取得して正しい答えを返すにはどうすればよいですか?リンク3は正しい情報であるように見え(私のWiFi接続)、ルーター上のDNSは正しい答えを返していますが、ローカルキャッシュはアドレスを検索しようとしません(またはそうです)。
Resolv.confファイルが間違った場所を指していませんでした— ../run/systemd/resolve/stub-resolv.conf
isデフォルトで指すはずの場所です。
問題は、systemd-resolved
がドット付きでない名前をDNSに渡さないことです。どうやらこれは「設計どおり」に機能しているようです。 このgithubの問題 を参照してください。これは、「解決すると、単一ラベルのルックアップがユニキャストDNSにリークすることを許可しない」と述べています。
そのgithubの問題の推論に同意するかどうかにかかわらず、これを修正する方法があります。 Ubuntuマシンのデフォルト設定を変更する必要さえありません。
まず、LANのDNSにドメイン名が必要です。
Dnsmasqを使用している場合は、DNSサーバーの/etc/dnsmasq.conf
に次を追加します。
expand-hosts
domain=your-domain # replace "your-domain" with domain of your choice
ドメインを追加すると、LANホスト名を解決できるようになります。
nslookup web1.your-domain
次に、LANドメインの名前がDNSサーバーと異なる場合は、DHCPサーバーにも設定されていることを確認します。 DHCPサーバー(ルーター)では、この設定は単に「ドメイン名」と呼ばれます。
その後、UbuntuボックスのDHCPリースを更新すると、/run/systemd/resolve/stub-resolv.conf
に検索ディレクティブが表示されます。
nameserver 127.0.0.53
search your-domain
web1
を検索すると、web1.your-domain
に展開され、DNSを使用して解決されます。
$ nslookup web1
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: web1.your-domain
Address: 192.168.1.107
Dig
の代わりにnslookup
を使用する場合、Dig
はデフォルトで検索パスを使用しないことに注意してください。+search
オプションを使用して有効にします。
私は私のために働いた修正を見つけました。
私のresolv.confファイルは間違った場所を指していました。これは、私のラップトップ(この問題に最初に気づいたマシン)とUbuntu 18.04サーバーの新規インストールで発生したUbuntuのバグのようです。
デフォルト
$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr 26 12:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
これを削除して、正しいファイルを指定しました。再起動後、これで問題が解決しました。そして、ラップトップでネットワークを切り替えることもでき、DNSは正しく切り替えられました。もちろん、外部ネットワーク上でローカルマシンを解決することはできませんが、それは当然のことです。ローカルネットワークに切り替えるとすぐに、ルーターがDNSであるため、すべてのローカルマシンが正しく解決されます。
修正
$ Sudo rm -f /etc/resolv.conf
$ Sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 32 May 29 08:48 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
$ Sudo reboot
その後、すべてが期待どおりに機能し、127.0.0.53はまったく使用されなくなりました。
正しい結果
$ nslookup web1
Server: 192.168.1.1
Address: 192.168.1.1#53
Name: web1
Address: 192.168.1.107
$ nslookup google.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: google.com
Address: 172.217.7.174
Name: google.com
Address: 2607:f8b0:4004:80e::200e