ドメイン名前解決

一般に、ドメイン名は IP アドレスを表し、DNS（Domain Name System）で関連付けられています。ここでは、ドメイン名前解決の設定方法とドメイン名の解決方法について説明します。

1 Name Service Switch
- 1.1 NSS を使用してドメイン名を解決する
2 Glibc リゾルバ
3 ルックアップユーティリティ
4 Resolver のパフォーマンス
5 Privacy and security
- 5.1 Application-level DNS
- 5.2 Oblivious DNS
6 サードパーティの DNS サービス
7 DNS サーバ
- 7.1 認証専用サーバー
- 7.2 条件付き転送
8 See also

Name Service Switch

この記事またはセクションは加筆を必要としています。

理由: Mention nss-mdns, nss-tls-git^AUR and others. (議論: トーク:ドメイン名前解決#)

Name Service Switch (NSS) 機能は GNU C ライブラリ (glibc) の一部であり、getaddrinfo(3) API をサポートしており、ドメイン名を解決するために使用されます。NSS では、システムデータベースを別々のサービスで提供することができ、その検索順序は管理者が nsswitch.conf(5) で設定することができます。ドメイン名の解決を行うデータベースは hosts データベースであり、glibc は以下のサービスを提供しています。

files: /etc/hosts ファイルを読み込む。hosts(5) を参照してください。
dns :/etc/resolv.conf を読み込む glibc resolver。 resolv.conf(5) を参照してください。

systemd はホスト名解決のために 3 つの NSS サービスを提供します。

nss-resolve(8) — で説明されているキャッシング DNS スタブリゾルバ systemd-resolved
nss-myhostname(8) — /etc/hosts を編集せずにネットワーク設定#ローカルのホストネーム解決を提供します。
nss-mymachines(8) — ローカル systemd-machined(8) コンテナの名前のホスト名解決を提供します

NSS を使用してドメイン名を解決する

NSS データベースは getent(1) でクエリできます。ドメイン名は、NSS を介して解決できます。

$ getent hosts domain_name

ノート: ほとんどのプログラムは NSS を使用してドメイン名を解決しますが、/etc/resolv.conf や /etc/hosts を直接読み取るプログラムもあります。ネットワーク設定#localhost がネットワーク上で解決されるを参照してください。

Glibc リゾルバ

glibc リゾルバは、解決ごとに /etc/resolv.conf を読み取り、使用するネームサーバーとオプションを決定します。

resolv.conf(5) は、ネームサーバといくつかの設定オプションをリストアップします。最初にリストされたネームサーバが最初に試され、最大3つのネームサーバをリストすることができます。数字記号 resolv.conf(5) は、ネームサーバといくつかの設定オプションをリストアップします。

ノート: glibc リゾルバはクエリをキャッシュしません。クエリのルックアップ時間を改善するために、キャッシングリゾルバを設定できます。glibc リゾルバも DNSSEC を検証できません。そのためには、DNSSEC 対応のバリデータリゾルバが必要です。詳細については、#DNS サーバーを参照してください。

/etc/resolv.conf の上書き

Network manager は /etc/resolv.conf を上書きする傾向があります。詳細については、対応するセクションを参照してください。

プログラムが /etc/resolv.conf を上書きするのを防ぐために、不変のファイル属性を設定して書き込み保護することもできます。

# chattr +i /etc/resolv.conf

ヒント: 複数のプロセスで /etc/resolv.conf に書き込みたい場合は、resolvconf を使用できます。

ルックアップ時間を制限する

非常に長いホスト名のルックアップに直面したとき (pacman やブラウジング中など)、代替ネームサーバーが使われるまでの小さなタイムアウトを定義することがしばしば役に立ちます。これを行うには、/etc/resolv.conf に以下を記述してください。

options timeout:1

IPv6 でホスト名の解決が遅れる

ホスト名の解決時に5秒の遅延が発生した場合は、DNS サーバー/ファイアウォールの誤動作が原因である可能性があり、並列の A および AAAA 要求に対して1つの応答しか返さない可能性があります。[1] /etc/resolv.conf で次のオプションを設定することで、これを修正できます。

options single-request

ローカルドメイン名

ローカルマシン名のホスト名を完全修飾ドメイン名なしで使用できるようにするには、/etc/resolv.conf にローカルドメインの行を以下のように追加してください。

domain example.org

これにより、ssh コマンドを使用する際に mainmachine1.example.org のようなローカルホストを単に mainmachine1 として参照することができますが、 drill コマンドなどは検索を行うために完全修飾ドメイン名を要求します。

ルックアップユーティリティ

特定の DNS サーバーと DNS/DNSSEC レコードを照会するには、専用の DNS ルックアップユーティリティを使用できます。これらのツールは DNS 自体を実装し、NSS を使用しません。

ldns は、DNS から情報を取得するために設計されたツールである drill(1) を提供します。

たとえば、drill を使用して特定のネームサーバーにドメインの TXT レコードを照会するには、次のようにします。

$ drill @nameserver TXT domain

DNS サーバーが指定されていない場合、drill は /etc/resolv.conf で定義されたネームサーバーを使用します。

ヒント: 一部の DNS サーバーには、独自の DNS ルックアップユーティリティが付属しています。例えば

knot khost(1) と kdig(1) を提供します。
Unbound unbound-host(1) を持っています。
BIND には、dig(1)、host(1)、nslookup(1)、および多数の dnssec- ツールがあります。

Resolver のパフォーマンス

Glibc resolver は問い合わせをキャッシュしません。ローカルキャッシュを実装するには、 systemd-resolved を使用するか、ローカルキャッシュ DNS server を設定し、 127.0.0.1 と ::1 を /etc/resolv.conf または /etc/resolvconf (openresolv を使用する場合) でネームサーバとして使用します。

ヒント:

drill または dig は、クエリー時間を報告します。
通常、ルータは自身のキャッシングリゾルバをネットワークの DNS サーバとして設定し、ネットワーク全体に DNS キャッシュを提供します。
次の DNS サーバへの切り替えに時間がかかりすぎる場合は、ドメイン名前解決#timeout オプションを使ってホスト名の検索時間を減らすを試してください。

Privacy and security

The DNS protocol is unencrypted and does not account for confidentiality, integrity or authentication, so if you use an untrusted network or a malicious ISP, your DNS queries can be eavesdropped and the responses manipulated. Furthermore, DNS servers can conduct DNS hijacking.

You need to trust your DNS server to treat your queries confidentially. DNS servers are provided by ISPs and third-parties. Alternatively you can run your own recursive name server, which however takes more effort. If you use a DHCP client in untrusted networks, be sure to set static name servers to avoid using and being subject to arbitrary DNS servers. To secure your communication with a remote DNS server you can use an encrypted protocol, like DNS over TLS (RFC 7858), DNS over HTTPS (RFC 8484), or DNSCrypt, provided that both the upstream server and your resolver support the protocol. An alternative can be a dedicated software to encrypt and decrypt the communication, such as stunnel. To verify that responses are actually from authoritative name servers, you can validate DNSSEC, provided that both the upstream server(s) and your resolver support it.

Application-level DNS

Be aware that some client software, such as major web browsers[2][3], are starting to implement DNS over HTTPS. While the encryption of queries may often be seen as a bonus, it also means the software sidetracks queries around the system resolver configuration.[4]

Firefox provides configuration options to enable or disable DNS over HTTPS and select a DNS server.

Chromium will examine the user's system resolver and enable DNS over HTTPS if the system resolver addresses are known to also provide DNS over HTTPS. See this blog post for more information and how DNS over HTTPS can be disabled.

Mozilla has proposed universally disabling application-level DNS if the system resolver cannot resolve the domain use-application-dns.net. Currently, this is only implemented in Firefox.

Oblivious DNS

Oblivious DNS is a system which addresses a number of DNS privacy concerns. See Cloudflare's article for more information.

サードパーティの DNS サービス

ノート: サードパーティの DNS サービスを使用する前に、そのサービスのプライバシーポリシーで、ユーザーデータの処理方法に関する情報を確認してください。ユーザーデータには価値があり、他の当事者に販売することができます。

さまざまな Public recursive name server が利用可能であり、その一部には専用のソフトウェアもあります。

cloudflared — HTTPS 経由の Cloudflare DNS の DNS クライアント

https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy || cloudflared

dingo — HTTPS 経由の Google DNS の DNS クライアント

https://github.com/pforemski/dingo || dingo-git^AUR

opennic-up — 最も応答性の高い OpenNIC サーバーを使用して、DNS サーバーの更新を自動化します

https://github.com/kewlfft/opennic-up || opennic-up^AUR

nextdns — NextDNS 用の DNS-over-HTTPS CLI クライアント

https://github.com/nextdns/nextdns || nextdns^AUR

dnsperftest を使用して、最も一般的な DNS リゾルバーのパフォーマンスを自分の場所からテストできます。dnsperf.com は、プロバイダー間のグローバルベンチマークを提供します。

DNS サーバ

DNSサーバーには、authoritative と recursive があります。そのどちらでもない場合、それらは スタブリゾルバ と呼ばれ、単にすべてのクエリーを別の再帰的ネームサーバーに転送するだけである。スタブリゾルバは通常、ローカルホストまたはネットワークに DNSキャッシュを導入するために使用される。同じことが、本格的なネームサーバーでも実現できることに注意してください。このセクションでは、利用可能なDNSサーバーを比較します。より詳細な比較は、Wikipedia:Comparison of DNS server softwareを参照してください。

この記事またはセクションは加筆を必要としています。

理由: Fill in the unknowns. (議論: トーク:ドメイン名前解決#)

名前	パッケージ	機能				resolvconf	サポートされているプロトコル
名前	パッケージ	Authoritative	Recursive	Cache	Validates DNSSEC	resolvconf	DNS	DNSCrypt	DNS over TLS	DNS over HTTPS
BIND	bind	Yes	Yes	Yes	Yes	Yes	Yes	No	Server¹	Server
CoreDNS	coredns^AUR or coredns-bin^AUR	?	?	?	?	?	?	?	Yes	?
Deadwood (MaraDNS recursor)	maradns^AUR	No	Yes	Yes	No	No	Yes	No	No	No
dnscrypt-proxy	dnscrypt-proxy	No	No	Yes	No	No	Server	Resolver	No	Yes
dnsmasq	dnsmasq	Partial²	No	Yes	Yes	Yes	Yes	No	No	No
Knot Resolver	knot-resolver	No	Yes	Yes	Yes	No	Yes	No	Yes	Server
pdnsd	pdnsd	Yes	Yes	Permanent	No	Yes	Yes	No	No	No
PowerDNS Recursor	powerdns-recursor	No	Yes	Yes	Yes	Yes	Yes	No	Partial	No
Rescached	rescached-git^AUR	No	No	Yes	No	Yes	Yes	No	Yes	Yes
SmartDNS	smartdns	No	No	Yes	No	?	Yes	No	Resolver	Resolver
Stubby	stubby	No	No	No	Yes	No	Server	No	Resolver	No
systemd-resolved	systemd	No	No	Yes	Yes	Yes	Resolver and limited server	No	Resolver	No
Unbound	unbound	Partial	Yes	Yes³	Yes	Yes	Yes	Server	Yes	Server

BIND は DNS over TLS と DNS over HTTPS の両方を提供できますが (tls{} と listen-on を参照)、DNS over TLS/DNS over HTTPS アップストリームにクエリを転送することはまだできません。dig ツールは DNS over TLS と DNS over HTTPS (+tls と +https オプションを使用) でクエリを実行できますが証明書チェックなしです。
Wikipediaより: dnsmasq は認証付きのサポートが制限されており、公共のインターネット利用よりもむしろ内部ネットワーク利用を意図しています。
Redis バックエンドを使用して、Unbound に永続的なキャッシュを提供できます。

認証専用サーバー

名前	パッケージ	DNSSEC	Geographic balancing
gdnsd	gdnsd	No	Yes
Knot DNS	knot	Yes	Yes
MaraDNS	maradns^AUR	No	?
NSD	nsd	No	No
PowerDNS	powerdns	Yes	Yes

条件付き転送

特定のドメイン名を照会するときに、特定の DNS リゾルバーを使用することができます。これは、VPN に接続する場合に特に便利です。これにより、VPN ネットワークへのクエリは VPN の DNS によって解決されますが、インターネットへのクエリは引き続き標準の DNS リゾルバーによって解決されます。ローカルネットワークでも使用できます。

これを実装するには、ローカルリゾルバを使用する必要があります。これは、glibc がサポートしていないためです。

動的な環境 (ラップトップやある程度はデスクトップ)では、接続しているネットワーク (複数) に基づいてリゾルバを設定する必要があります。そのための最良の方法は openresolv を使うことです。なぜなら multiple subscribers をサポートしているからです。いくつかのネットワークマネージャは openresolv を通して、あるいはリゾルバを直接設定して、これをサポートしています。NetworkManager supports conditional forwarding without openresolv は、openresolv を使わずに条件付き転送をサポートしています。

ノート: 転送に他の条件 (送信元 IP アドレスなど) を使用することもできますが、"条件付き転送" は、"照会されたドメイン" を条件に使用される名前です。