「Pdnsd」の版間の差分
(→キャッシュ容量: 微修正) |
Kusanaginoturugi (トーク | 投稿記録) (校正(でき・出来)) |
||
(他の1人の利用者による、間の4版が非表示) | |||
76行目: | 76行目: | ||
ネットワークを使用するサービス ({{ic|network-online.target}}) がちゃんと DNS を使えるように、{{ic|network.target}} の後すぐに起動します (参照: [https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Upstream Wiki])。 |
ネットワークを使用するサービス ({{ic|network-online.target}}) がちゃんと DNS を使えるように、{{ic|network.target}} の後すぐに起動します (参照: [https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Upstream Wiki])。 |
||
− | 2つ以上のNICを備えたPCで、有線およびワイヤレス接続でpdnsdが動作するようにするには、各NICに個別のプロファイルを設定してください {{ic|pdnsd.conf}} by 正しい{{ic|interface}}を指定する。 |
+ | 2つ以上のNICを備えたPCで、有線およびワイヤレス接続でpdnsdが動作するようにするには、各NICに個別のプロファイルを設定してください {{ic|pdnsd.conf}} by 正しい{{ic|interface}} を指定する。 |
== ヒントとテクニック == |
== ヒントとテクニック == |
||
92行目: | 92行目: | ||
purge_cache=off; |
purge_cache=off; |
||
− | {{ic|1=neg_rrs_pol=on;}} ポリシーとは、クエリに対して否定的な応答が返された場合、応答が「信頼できる」ものでなくても、pdnsdサーバーは結果をキャッシュすることを意味します。 DNSクエリを監視すると、AAAAレコード(IPv6のDNSクエリ)に対する多くの要求があることが明らかになるため、これは重要です。多くのドメインがIPv6を使用していないために結果を返すことはなく、すべてのドメインがMXレコードを持っているわけではないためMXレコードも同様です。ネガティブキャッシングがない場合、これらの要求はドメイン名がキャッシュされた後でも送信され、この役割では追加のDNS要求が行われることを望まないでしょう。このオプションは、 {{ic|1=proxy_only=on;}} と組み合わせて使用することが重要です。システムから送信されるクエリの数を最小限に抑えるオプション。 |
+ | {{ic|1=neg_rrs_pol=on;}} ポリシーとは、クエリに対して否定的な応答が返された場合、応答が「信頼できる」ものでなくても、 pdnsd サーバーは結果をキャッシュすることを意味します。 DNS クエリを監視すると、 AAAA レコード (IPv6 の DNS クエリ) に対する多くの要求があることが明らかになるため、これは重要です。多くのドメインがIPv6を使用していないために結果を返すことはなく、すべてのドメインが MX レコードを持っているわけではないため MX レコードも同様です。ネガティブキャッシングがない場合、これらの要求はドメイン名がキャッシュされた後でも送信され、この役割では追加の DNS 要求が行われることを望まないでしょう。このオプションは、 {{ic|1=proxy_only=on;}} と組み合わせて使用することが重要です。システムから送信されるクエリの数を最小限に抑えるオプション。 |
− | {{ic|1=par_queries=1;}} このオプションは、以下の「サーバー」セクションで複数のDNSサーバーを指定する場合に役立ちます。一度に実行される並列クエリの数の増分を指定します。たとえば、 |
+ | {{ic|1=par_queries=1;}} このオプションは、以下の「サーバー」セクションで複数の DNS サーバーを指定する場合に役立ちます。一度に実行される並列クエリの数の増分を指定します。たとえば、''server'' セクションに4つの DNS サーバーがリストされていて、 {{ic|1=par_queries=2;}} (デフォルト) の場合、最初の2つのサーバーが同時に照会され、最初の2つのサーバーの両方に障害が発生した場合、 {{ic|pdnsd}} は次の2つのサーバーに移動して、同時に照会します。上記の設定は、一度に1つのDNSサーバーが照会されることを意味するため、 ''server'' セクションに2つ以上の DNS サーバーをリストでき、2番目の DNS サーバーは、最初の DNS サーバーが失敗した場合にのみ照会されます。これはトラフィックを最小限に抑えるのに役立ちますが、最初のサーバーに障害が発生した場合は、2番目のサーバーが照会される前にタイムアウトになるまで待機する必要があります。この設定を独自の設定に合わせて調整します。 ''server'' セクションでサーバーを1つだけ指定する場合は、心配する必要はありません。 |
− | {{ic|1=proxy_only=on;}} 設定は、以下のFAQで説明されており、ホームブロードバンドユーザーにとって重要です。これは、通常、完全なDNSサーバーが行うような本格的な階層的な名前解決を行うのではなく、1つまたは2つのDNSサーバーのみを使用するためです。この設定は、 {{ic|pdnsd}} が |
+ | {{ic|1=proxy_only=on;}} 設定は、以下の FAQ で説明されており、ホームブロードバンドユーザーにとって重要です。これは、通常、完全なDNSサーバーが行うような本格的な階層的な名前解決を行うのではなく、1つまたは2つのDNSサーバーのみを使用するためです。この設定は、 {{ic|pdnsd}} が ''権限のある'' ネームサーバーまで解決しないようにし、代わりに、 ''server'' セクションですでに指定されている DNS サーバーの結果を受け入れます。繰り返しになりますが、これにより、必要な DNS クエリの数が減り、パフォーマンスが向上します。 |
{{ic|1=purge_cache=off;}} 設定は、DNSレコードの存続時間メトリックよりも長くてもキャッシュエントリを削除しないように {{ic|pdnsd}} に指示します。これは、ISPのDNSサーバーがダウンし、停止中に頻繁に使用するドメインの名前検索にアクセスできるようにする場合に非常に役立ちます。キャッシュがいっぱいになると、レコードは経過時間に基づいてキャッシュからバンプされます(キャッシュのサイズの設定方法については、{{man|5|pdnsd.conf}} を参照してください)。 |
{{ic|1=purge_cache=off;}} 設定は、DNSレコードの存続時間メトリックよりも長くてもキャッシュエントリを削除しないように {{ic|pdnsd}} に指示します。これは、ISPのDNSサーバーがダウンし、停止中に頻繁に使用するドメインの名前検索にアクセスできるようにする場合に非常に役立ちます。キャッシュがいっぱいになると、レコードは経過時間に基づいてキャッシュからバンプされます(キャッシュのサイズの設定方法については、{{man|5|pdnsd.conf}} を参照してください)。 |
||
104行目: | 104行目: | ||
==== TTL (Time-To-Live) ==== |
==== TTL (Time-To-Live) ==== |
||
− | サーバーから返される各DNSリソースレコードには、最大存続可能時間(TTL)が含まれます。これにより、受信者はレコードを保存する期間と、レコードを新しく検索するタイミングがわかります。多くのDNSレコードには、3600(1時間)などの比較的短いTTLがあります。つまり、1時間後、pdnsdは、キャッシュされたレコードが利用可能かどうかに関係なく、このエントリに対して新しい検索を試みます。グローバルな最小TTLを設定してこのデフォルトTTLをオーバーライドすることでパフォーマンスが向上し、実行されるルックアップが少なくなります。長すぎる最小TTLを使用することの欠点は、キャッシュされたレコードが古くなる可能性があることです(ホストのIPアドレスが変更される可能性がありますが、クライアントはキャッシュされたアドレスを受け取るため、これを認識しません)。ただし、ほとんどのIPアドレスは1時間ごと、または毎日変更されることはありません。 時間はデフォルトで秒単位で指定されますが、「m」、「h」、「d」、または「w」を時間に追加して、分、時間、日、または週を指定することもできます。 グローバル設定の {{ic|1=min_ttl}} は、キャッシュされたレコードの最小TTLを設定するため、pdnsdはサーバーから受信したレコードのデフォルトTTLを無視します。遅い接続または遅いDNSサーバーでは、これを数時間に設定して、ルックアップの数を減らすことができます ( 例 {{ic|1=min_ttl=6h;}} ) グローバル設定の {{ic|1=neg_ttl}} は、存在しないドメインの最小TTLを設定します。サーバーがドメインが存在しないことをpdnsdに通知した場合、この時間が経過するまで、サーバーはそのドメインを再度検索しようとしません。 |
+ | サーバーから返される各 DNS リソースレコードには、最大存続可能時間 (TTL) が含まれます。これにより、受信者はレコードを保存する期間と、レコードを新しく検索するタイミングがわかります。多くの DNS レコードには、3600(1時間) などの比較的短いTTLがあります。つまり、1時間後、 pdnsd は、キャッシュされたレコードが利用可能かどうかに関係なく、このエントリに対して新しい検索を試みます。グローバルな最小 TTL を設定してこのデフォルト TTL をオーバーライドすることでパフォーマンスが向上し、実行されるルックアップが少なくなります。長すぎる最小 TTL を使用することの欠点は、キャッシュされたレコードが古くなる可能性があることです(ホストのIPアドレスが変更される可能性がありますが、クライアントはキャッシュされたアドレスを受け取るため、これを認識しません)。ただし、ほとんどの IP アドレスは1時間ごと、または毎日変更されることはありません。 時間はデフォルトで秒単位で指定されますが、「m」、「h」、「d」、または「w」を時間に追加して、分、時間、日、または週を指定することもできます。 グローバル設定の {{ic|1=min_ttl}} は、キャッシュされたレコードの最小TTLを設定するため、pdnsdはサーバーから受信したレコードのデフォルトTTLを無視します。遅い接続または遅いDNSサーバーでは、これを数時間に設定して、ルックアップの数を減らすことができます ( 例 {{ic|1=min_ttl=6h;}} ) グローバル設定の {{ic|1=neg_ttl}} は、存在しないドメインの最小 TTL を設定します。サーバーがドメインが存在しないことをpdnsdに通知した場合、この時間が経過するまで、サーバーはそのドメインを再度検索しようとしません。 |
==== タイムアウト ==== |
==== タイムアウト ==== |
||
− | 短いタイムアウトを設定すると、pdnsdはクエリ全体または特定のサーバークエリをより迅速に放棄し、パフォーマンスが向上します。タイムアウトの設定が短すぎる場合の短所は、単にサーバーが応答するのに十分な時間を与えられなかったために、pdnsdがルックアップでエラーを返す可能性があることです。 |
+ | 短いタイムアウトを設定すると、 pdnsd はクエリ全体または特定のサーバークエリをより迅速に放棄し、パフォーマンスが向上します。タイムアウトの設定が短すぎる場合の短所は、単にサーバーが応答するのに十分な時間を与えられなかったために、 pdnsd がルックアップでエラーを返す可能性があることです。 |
− | {{ic|timeout}} グローバル設定では、pdnsdがクエリ全体を断念し、ブラウザまたは他のクライアントにエラーを返すタイミングを決定します。グローバルタイムアウトオプションを設定すると、サーバーセクションで非常に短いタイムアウト間隔を指定できます(以下を参照)。これにより、最初のサーバーの応答が遅い場合にpdnsdが追加サーバーの照会をかなり迅速に開始するという効果があります(ただし、最初のサーバーからの応答は引き続きリッスンします)。 (query_method = tcp_udpを使用する場合、グローバルタイムアウトを最大サーバータイムアウトの少なくとも2倍にすることをお勧めします。そうしないと、TCP接続がタイムアウトした場合にpdnsdがUDPクエリを試行する時間がない場合があります。) |
+ | {{ic|timeout}} グローバル設定では、pdnsdがクエリ全体を断念し、ブラウザまたは他のクライアントにエラーを返すタイミングを決定します。グローバルタイムアウトオプションを設定すると、サーバーセクションで非常に短いタイムアウト間隔を指定できます (以下を参照)。これにより、最初のサーバーの応答が遅い場合にpdnsdが追加サーバーの照会をかなり迅速に開始するという効果があります(ただし、最初のサーバーからの応答は引き続きリッスンします)。 (query_method = tcp_udp を使用する場合、グローバルタイムアウトを最大サーバータイムアウトの少なくとも2倍にすることをお勧めします。そうしないと、 TCP 接続がタイムアウトした場合に pdnsd が UDP クエリを試行する時間がない場合があります。) |
{{ic|1=tcp_qtimeout}} グローバル設定で、TCPクエリ接続を開いたままにすることができる時間を決定します。 |
{{ic|1=tcp_qtimeout}} グローバル設定で、TCPクエリ接続を開いたままにすることができる時間を決定します。 |
||
− | {{ic|1=timeout}} サーバー設定で、pdnsdが各サーバーからの応答を待機する時間を決定します。これをより短い時間に設定すると、pdnsdは応答しないサーバーをより迅速に放棄し、次の使用可能なサーバーに移動するため、全体的な応答時間が速くなる場合があります。高速接続では、これを4秒または5秒に設定することも可能です。 |
+ | {{ic|1=timeout}} サーバー設定で、pdnsdが各サーバーからの応答を待機する時間を決定します。これをより短い時間に設定すると、 pdnsd は応答しないサーバーをより迅速に放棄し、次の使用可能なサーバーに移動するため、全体的な応答時間が速くなる場合があります。高速接続では、これを4秒または5秒に設定することも可能です。 |
==== デバッグ ==== |
==== デバッグ ==== |
||
− | 特定のルックアップにpdnsdが使用しているサーバー、タイムアウトの仕組み、およびドメインで使用されているデフォルトTTLを確認するには、グローバル設定でデバッグをオンにします。 |
+ | 特定のルックアップに pdnsd が使用しているサーバー、タイムアウトの仕組み、およびドメインで使用されているデフォルト TTL を確認するには、グローバル設定でデバッグをオンにします。 |
debug=on; |
debug=on; |
||
− | pdnsdを再起動して、systemdジャーナルの変更についてpdnsd.serviceを監視します。 |
+ | pdnsd を再起動して、systemd ジャーナルの変更について pdnsd.service を監視します。 |
journalctl -f _SYSTEMD_UNIT=pdnsd.service |
journalctl -f _SYSTEMD_UNIT=pdnsd.service |
||
127行目: | 127行目: | ||
==== キャッシュ容量 ==== |
==== キャッシュ容量 ==== |
||
− | デフォルトでは、pdnsdは自動的にすべてのエントリの信頼できるレコードを作成します {{ic|/etc/hosts}}. エントリが多数ある場合、たとえば広告のブロックに使用している場合、デフォルトの最大キャッシュサイズは {{ic|/etc/pdnsd.conf}} 十分な大きさではない可能性があり、その結果、予想される時間内にDNS要求がキャッシュされません。 |
+ | デフォルトでは、 pdnsd は自動的にすべてのエントリの信頼できるレコードを作成します {{ic|/etc/hosts}}. エントリが多数ある場合、たとえば広告のブロックに使用している場合、デフォルトの最大キャッシュサイズは {{ic|/etc/pdnsd.conf}} 十分な大きさではない可能性があり、その結果、予想される時間内にDNS要求がキャッシュされません。 |
キャッシュ容量を増やすには、設定ファイルの ''global settings'' セクションの {{ic|1=perm_cache}} 行を編集してください (単位は kB です)。 |
キャッシュ容量を増やすには、設定ファイルの ''global settings'' セクションの {{ic|1=perm_cache}} 行を編集してください (単位は kB です)。 |
||
− | または、オプション {{ic|1=authrec=off}} を ''source'' セクションに追加することにより、pdnsdがhostsファイルを先制的に調達するのを防ぐことができます。何らかの理由でauthrecをoffに設定しても機能しない場合、簡単な回避策は、システム情報のみを含む別のホストファイル {{ic|/etc/hosts-pdnsd など}}を作成し、代わりに ''source'' セクションをポイントすることです元のホストファイルをそのまま残します。この方法で、pdnsdは検索を実行するときにのみ {{ic|/etc/hosts}} を参照します。たとえば、次のとおりです。 |
+ | または、オプション {{ic|1=authrec=off}} を ''source'' セクションに追加することにより、 pdnsd が hosts ファイルを先制的に調達するのを防ぐことができます。何らかの理由で authrec を off に設定しても機能しない場合、簡単な回避策は、システム情報のみを含む別のホストファイル {{ic|/etc/hosts-pdnsd など}}を作成し、代わりに ''source'' セクションをポイントすることです元のホストファイルをそのまま残します。この方法で、 pdnsd は検索を実行するときにのみ {{ic|/etc/hosts}} を参照します。たとえば、次のとおりです。 |
{{hc|/etc/hosts-pdnsd|2=#<ip-address> <hostname.domain.org> <hostname> |
{{hc|/etc/hosts-pdnsd|2=#<ip-address> <hostname.domain.org> <hostname> |
||
127.0.0.1 localhost.localdomain my_hostname |
127.0.0.1 localhost.localdomain my_hostname |
||
143行目: | 143行目: | ||
これで、ネットワーク上の他のコンピューターを構成して、PDNを実行しているコンピューターをプライマリDNSサーバーとして使用できます。 |
これで、ネットワーク上の他のコンピューターを構成して、PDNを実行しているコンピューターをプライマリDNSサーバーとして使用できます。 |
||
− | === 名前ブロック === |
+ | === 名前でブロック === |
pdnsdを使用すると、結果を返してはならないホストまたはドメインを指定できます。これにより、特にプリミティブ広告またはコンテンツブロッカーとして使用できます。 {{ic|pdnsd.conf}} に新しい {{ic|neg}} セクションを作成します。否定セクションには2つの主要なオプションがあります。 {{ic|name}} は、ブロックするホストまたはドメインの名前です。 {{ic|types}} を {{ic|domain}} に設定して、特定のドメイン内のすべてのホストをブロックできます。デフォルトの {{ic|pdnsd.conf}} は、doubleclick.netからのすべての広告をブロックする例を示しています。 |
pdnsdを使用すると、結果を返してはならないホストまたはドメインを指定できます。これにより、特にプリミティブ広告またはコンテンツブロッカーとして使用できます。 {{ic|pdnsd.conf}} に新しい {{ic|neg}} セクションを作成します。否定セクションには2つの主要なオプションがあります。 {{ic|name}} は、ブロックするホストまたはドメインの名前です。 {{ic|types}} を {{ic|domain}} に設定して、特定のドメイン内のすべてのホストをブロックできます。デフォルトの {{ic|pdnsd.conf}} は、doubleclick.netからのすべての広告をブロックする例を示しています。 |
||
+ | |||
+ | ブロックごとに1つのドメインしか設定できないので、追加、トラッカー、悪意のあるコンテンツをブロックするためにはうまくスケールしません。しかし、{{ic|source}} セクションを追加することは可能です (既存の {{ic|/etc/hosts}} を読み込むものに加えて) このセクションは、ドメインを特別な IP アドレス 0.0.0.0 にバインドする形式 – ただし、{{ic|/etc/hosts}} ではワイルドカードが許可されていないため、サブドメインはブロックされません。これを行うことは、ルールを {{ic|/etc/hosts}} に追加することと同じですが、一部のアプリケーションを破壊する可能性のある巨大な {{ic|/etc/hosts}} ファイルをを避けることができます。 |
||
=== pdnsd-ctl === |
=== pdnsd-ctl === |
||
152行目: | 154行目: | ||
:'''''pdnsd-ctl''' は永続的なキャッシュを使う DNS プロキシサーバーである '''pdnsd''' を制御します。'''pdnsd-ctl''' を使う前に (pdnsd のコマンドラインや設定ファイルでオプションを指定して) ステータス制御ソケットを有効にする必要があるので注意してください。'' |
:'''''pdnsd-ctl''' は永続的なキャッシュを使う DNS プロキシサーバーである '''pdnsd''' を制御します。'''pdnsd-ctl''' を使う前に (pdnsd のコマンドラインや設定ファイルでオプションを指定して) ステータス制御ソケットを有効にする必要があるので注意してください。'' |
||
+ | これを行うには、オプションを含めます |
||
+ | status_ctl = on; |
||
+ | {{ic|/etc/pdnsd.conf}} のグローバルセクションにあります。 |
||
+ | |||
+ | {{ic|/etc/pdnsd.conf}} でキャッシュディレクトリを変更した場合は、{{ic|-c}} オプションを指定して {{ic|pdnsd-ctl}} を実行する必要があります。 |
||
+ | |||
+ | # pdnsd-ctl -c ''path/to/cache'' |
||
以下のようなコマンドが使えます。 |
以下のようなコマンドが使えます。 |
||
171行目: | 180行目: | ||
ログに次のように表示されていても、ISPの [[Wikipedia:Dynamic DNS|dynamic DNS]] に正常にpingを送信できます。 |
ログに次のように表示されていても、ISPの [[Wikipedia:Dynamic DNS|dynamic DNS]] に正常にpingを送信できます。 |
||
− | {{hc|<nowiki>$ journalctl -f |
+ | {{hc|<nowiki>$ journalctl -f -u pdnsd.service</nowiki>| |
result of uptest for 192.168.x.x: failed |
result of uptest for 192.168.x.x: failed |
||
}} |
}} |
||
186行目: | 195行目: | ||
; Q) あんまり速くありません。なぜ? : '''A)''' ローカル DNS キャッシュを使うことによる速度の向上はサーバーに接続するまでにかかる時間によります。スループット (いわゆる速度) に影響はありません。複数のサーバーから小さなダウンロードを行う、ウェブの閲覧などで違いは最も明白になります。接続速度が遅い、特にダイアルアップ接続などでは、スループットがボトルネックになるため、目で見てわかるほどの違いは生まれません。 |
; Q) あんまり速くありません。なぜ? : '''A)''' ローカル DNS キャッシュを使うことによる速度の向上はサーバーに接続するまでにかかる時間によります。スループット (いわゆる速度) に影響はありません。複数のサーバーから小さなダウンロードを行う、ウェブの閲覧などで違いは最も明白になります。接続速度が遅い、特にダイアルアップ接続などでは、スループットがボトルネックになるため、目で見てわかるほどの違いは生まれません。 |
||
− | ; Q) 前より遅くなっているんですが? : '''A)''' おそらく {{ic|pdnsd.conf}} のサーバーセクションのどれかで {{ic|proxy_only}} オプションがオフになっています。デフォルトで、pdnsd は |
+ | ; Q) 前より遅くなっているんですが? : '''A)''' おそらく {{ic|pdnsd.conf}} のサーバーセクションのどれかで {{ic|proxy_only}} オプションがオフになっています。デフォルトで、pdnsd はできる限り正確なレスポンスを得るために複数の DNS サーバーに頻繁にリクエストを行います。{{ic|proxy_only}} オプションはこの機能を無効化します。ISP によって提供されている DNS サーバーを使っている場合はオンにしたほうが良いでしょう。 |
2024年7月10日 (水) 21:01時点における版
pdnsd は DNS 情報をローカルでキャッシュするように設計された DNS サーバーです。正しく設定することで、ブロードバンド接続でのブラウジング速度を劇的に上げることができます。BIND や dnsmasq と対照的に、再起動後もキャッシュを保持します。"p" は永続 (persistent) です。
インストール
設定
パッケージにはサンプル設定ファイル /usr/share/doc/pdnsd/pdnsd.conf
が付属しています。カスタマイズした設定ファイルを /etc/pdnsd.conf
に作成してください。
フォーマット
pdnsd.conf
ファイルのフォーマットはとても単純ですが、よくある設定ファイルとは少し違うところもあります。様々なタイプのセクションから成ります。セクションのタイプの名前と波括弧 ({) でセクションの開始を示して同じく波括弧 (}) で閉じます。セクションは入れ子にできません。
各ブロックでは以下の形式でオプションを指定します:
option_name=option_value;
セミコロンが最後に付いていることに気をつけて下さい。他のフォーマットと違って、セミコロンは必須です。
コメントは # か /* のどちらかで始めます。前者は行全体がコメントになり、後者は */ までずっとコメントになります。
DNS サーバー
DNS 情報を取得するために、最低でも一つの DNS のサーバーのアドレスを pdnsd に指定する必要があります。設定する箇所はブロードバンド接続なのかダイアルアップ接続なのかで変わってきます。ブロードバンドを使っている場合は最初のサーバーセクションを使って下さい。ダイアルアップ接続の場合、2番目のセクションを使って、それ以外のサーバーセクションはコメントアウトしてください。
- label
label
オプションはサーバーセクションに名前を付けるのに使います。使用は任意ですが、ISP の名前を使うと良いでしょう。- ip
- デフォルトのブロードバンド設定で使われるこのオプションは pdnsd に使用する DNS サーバーのアドレスを指定します。アドレスが複数ある場合はカンマで区切って下さい。カンマの前後には空白を挟むことができます。
/etc/resolv.conf
からアドレスをコピーするだけでかまいません。 - file
ip
の代わりにfile
オプションを使うことで DNS サーバーの IP のセットを指定することができます。resolv.conf
と同じ形式でサーバーがリストアップされたファイルのパスを値にします。ダイアルアップ接続の設定はデフォルトでfile
を使います。PPP クライアントは/etc/ppp/resolv.conf
に PPP サーバーから得られたアドレスを書き込むからです。ISP から取得できるデフォルトの DNS サーバーを使わない場合でなければ変更する必要はありません。- interface
- uptest=if オプションで使うネットワークインターフェイス。デフォルトでは eth0 ですが、基本的に別のインターフェイスになるはずです。pdnsd サービスを起動しても DNS レコードが返ってこない場合、このオプションが間違っていないか疑って下さい。
サーバーセクションの上記以外のオプションは変えなくてもかまいません。利用可能なオプションの詳細は pdnsd マニュアル を見て下さい。
DNS サーバーと DHCP 接続
netctl をインストールしている場合、pdnsd は resolvconf でネームサーバーの IP アドレスを知ることができます (resolvconf(8) を参照)。プロファイルの自動切り替えをしている場合、動的に IP アドレスが伝えられます。
この機能を設定するには、ブロードバンドのサーバーセクションを削除してダイアルアップのサーバーセクションに以下の変更を加えて下さい:
label = resolvconf; file = /etc/pdnsd-resolv.conf;
/etc/resolvconf.conf
を編集して pdnsd を使うように resolvconf を設定します:
name_servers=127.0.0.1 pdnsd_resolv=/etc/pdnsd-resolv.conf
それから resolvconf -u
を実行してネームサーバーのアドレスが載っている /etc/pdnsd-resolv.conf
を更新してください (pdnsd ソケットにアクセスできないというエラーメッセージは無視してください)。手動で pdnsd を起動する前に一度更新する必要があります。
OpenDNS
pdnsd.conf
ファイルには OpenDNS の設定が初めから入っています。ダイアルアップとブロードバンドセクションを削除 (またはコメントアウト) して (ファイルの上部にある全体の設定を削除してしまわないように注意してください)、OpenDNS の設定をアンコメントすることで OpenDNS を使うことができます。
ただし OpenDNS は Google で問題が発生することがあります。問題を避けるには OpenDNS の Google プロキシマシンを返答する OpenDNS の結果を拒否しなければなりません (大抵の場合 Google のリクエストが 15ms から 75ms 以上にまで遅くなります)。実際のサーバーの IP は代わりますが、(ldns に含まれている) drill www.google.com @208.67.222.222
で現在の IP を確認できます。サーバーの名前が google.navigation.opendns.com
のように解決されるので、クエリがプロキシを通しているかどうか知ることができます。執筆時点では、アドレスは 208.67.216.230
と 208.67.216.231
でした。
IP がわかったら、pdnsd.conf
の OpenDNS server { …
} にある既存の rejected
IP を置き換えてください。プリフィックスは削除しないでください。
OpenDNS の代替として OpenNIC というサービスも存在します。
テスト
pdnsd
デーモンが機能するか確認するために、起動してください。
テストする方法は Resolv.conf#Linux における DNS を参照してください。
127.0.0.1
を使ってアドレスをルックアップすると、問い合わせ時間は 1 ms 以下になるはずです。
システム設定
pdnsd
サービスを有効化してください。
ネットワークを使用するサービス (network-online.target
) がちゃんと DNS を使えるように、network.target
の後すぐに起動します (参照: Upstream Wiki)。
2つ以上のNICを備えたPCで、有線およびワイヤレス接続でpdnsdが動作するようにするには、各NICに個別のプロファイルを設定してください pdnsd.conf
by 正しいinterface
を指定する。
ヒントとテクニック
ホームブロードバンドユーザー向けのパフォーマンス設定
多くのユーザーはブロードバンド接続を使用しており、DNSサーバーが遅いか信頼性が低く、 pdnsd
をキャッシュサーバーとして使用して、必要なDNSクエリの数を最小限に抑えたいと考えています。上記の詳細設定を行った後、 /etc/pdnsd.conf
の以下の設定は、この役割のパフォーマンスを向上させるのに役立ちます。
global settings:
neg_rrs_pol=on; par_queries=1;
server settings:
proxy_only=on; purge_cache=off;
neg_rrs_pol=on;
ポリシーとは、クエリに対して否定的な応答が返された場合、応答が「信頼できる」ものでなくても、 pdnsd サーバーは結果をキャッシュすることを意味します。 DNS クエリを監視すると、 AAAA レコード (IPv6 の DNS クエリ) に対する多くの要求があることが明らかになるため、これは重要です。多くのドメインがIPv6を使用していないために結果を返すことはなく、すべてのドメインが MX レコードを持っているわけではないため MX レコードも同様です。ネガティブキャッシングがない場合、これらの要求はドメイン名がキャッシュされた後でも送信され、この役割では追加の DNS 要求が行われることを望まないでしょう。このオプションは、 proxy_only=on;
と組み合わせて使用することが重要です。システムから送信されるクエリの数を最小限に抑えるオプション。
par_queries=1;
このオプションは、以下の「サーバー」セクションで複数の DNS サーバーを指定する場合に役立ちます。一度に実行される並列クエリの数の増分を指定します。たとえば、server セクションに4つの DNS サーバーがリストされていて、 par_queries=2;
(デフォルト) の場合、最初の2つのサーバーが同時に照会され、最初の2つのサーバーの両方に障害が発生した場合、 pdnsd
は次の2つのサーバーに移動して、同時に照会します。上記の設定は、一度に1つのDNSサーバーが照会されることを意味するため、 server セクションに2つ以上の DNS サーバーをリストでき、2番目の DNS サーバーは、最初の DNS サーバーが失敗した場合にのみ照会されます。これはトラフィックを最小限に抑えるのに役立ちますが、最初のサーバーに障害が発生した場合は、2番目のサーバーが照会される前にタイムアウトになるまで待機する必要があります。この設定を独自の設定に合わせて調整します。 server セクションでサーバーを1つだけ指定する場合は、心配する必要はありません。
proxy_only=on;
設定は、以下の FAQ で説明されており、ホームブロードバンドユーザーにとって重要です。これは、通常、完全なDNSサーバーが行うような本格的な階層的な名前解決を行うのではなく、1つまたは2つのDNSサーバーのみを使用するためです。この設定は、 pdnsd
が 権限のある ネームサーバーまで解決しないようにし、代わりに、 server セクションですでに指定されている DNS サーバーの結果を受け入れます。繰り返しになりますが、これにより、必要な DNS クエリの数が減り、パフォーマンスが向上します。
purge_cache=off;
設定は、DNSレコードの存続時間メトリックよりも長くてもキャッシュエントリを削除しないように pdnsd
に指示します。これは、ISPのDNSサーバーがダウンし、停止中に頻繁に使用するドメインの名前検索にアクセスできるようにする場合に非常に役立ちます。キャッシュがいっぱいになると、レコードは経過時間に基づいてキャッシュからバンプされます(キャッシュのサイズの設定方法については、pdnsd.conf(5) を参照してください)。
その他のパフォーマンス設定
TTL (Time-To-Live)
サーバーから返される各 DNS リソースレコードには、最大存続可能時間 (TTL) が含まれます。これにより、受信者はレコードを保存する期間と、レコードを新しく検索するタイミングがわかります。多くの DNS レコードには、3600(1時間) などの比較的短いTTLがあります。つまり、1時間後、 pdnsd は、キャッシュされたレコードが利用可能かどうかに関係なく、このエントリに対して新しい検索を試みます。グローバルな最小 TTL を設定してこのデフォルト TTL をオーバーライドすることでパフォーマンスが向上し、実行されるルックアップが少なくなります。長すぎる最小 TTL を使用することの欠点は、キャッシュされたレコードが古くなる可能性があることです(ホストのIPアドレスが変更される可能性がありますが、クライアントはキャッシュされたアドレスを受け取るため、これを認識しません)。ただし、ほとんどの IP アドレスは1時間ごと、または毎日変更されることはありません。 時間はデフォルトで秒単位で指定されますが、「m」、「h」、「d」、または「w」を時間に追加して、分、時間、日、または週を指定することもできます。 グローバル設定の min_ttl
は、キャッシュされたレコードの最小TTLを設定するため、pdnsdはサーバーから受信したレコードのデフォルトTTLを無視します。遅い接続または遅いDNSサーバーでは、これを数時間に設定して、ルックアップの数を減らすことができます ( 例 min_ttl=6h;
) グローバル設定の neg_ttl
は、存在しないドメインの最小 TTL を設定します。サーバーがドメインが存在しないことをpdnsdに通知した場合、この時間が経過するまで、サーバーはそのドメインを再度検索しようとしません。
タイムアウト
短いタイムアウトを設定すると、 pdnsd はクエリ全体または特定のサーバークエリをより迅速に放棄し、パフォーマンスが向上します。タイムアウトの設定が短すぎる場合の短所は、単にサーバーが応答するのに十分な時間を与えられなかったために、 pdnsd がルックアップでエラーを返す可能性があることです。
timeout
グローバル設定では、pdnsdがクエリ全体を断念し、ブラウザまたは他のクライアントにエラーを返すタイミングを決定します。グローバルタイムアウトオプションを設定すると、サーバーセクションで非常に短いタイムアウト間隔を指定できます (以下を参照)。これにより、最初のサーバーの応答が遅い場合にpdnsdが追加サーバーの照会をかなり迅速に開始するという効果があります(ただし、最初のサーバーからの応答は引き続きリッスンします)。 (query_method = tcp_udp を使用する場合、グローバルタイムアウトを最大サーバータイムアウトの少なくとも2倍にすることをお勧めします。そうしないと、 TCP 接続がタイムアウトした場合に pdnsd が UDP クエリを試行する時間がない場合があります。)
tcp_qtimeout
グローバル設定で、TCPクエリ接続を開いたままにすることができる時間を決定します。
timeout
サーバー設定で、pdnsdが各サーバーからの応答を待機する時間を決定します。これをより短い時間に設定すると、 pdnsd は応答しないサーバーをより迅速に放棄し、次の使用可能なサーバーに移動するため、全体的な応答時間が速くなる場合があります。高速接続では、これを4秒または5秒に設定することも可能です。
デバッグ
特定のルックアップに pdnsd が使用しているサーバー、タイムアウトの仕組み、およびドメインで使用されているデフォルト TTL を確認するには、グローバル設定でデバッグをオンにします。
debug=on;
pdnsd を再起動して、systemd ジャーナルの変更について pdnsd.service を監視します。
journalctl -f _SYSTEMD_UNIT=pdnsd.service
デバッグをオンのままにするとパフォーマンスが低下する可能性があるため、一般的な使用ではデバッグをオフにしてください。
キャッシュ容量
デフォルトでは、 pdnsd は自動的にすべてのエントリの信頼できるレコードを作成します /etc/hosts
. エントリが多数ある場合、たとえば広告のブロックに使用している場合、デフォルトの最大キャッシュサイズは /etc/pdnsd.conf
十分な大きさではない可能性があり、その結果、予想される時間内にDNS要求がキャッシュされません。
キャッシュ容量を増やすには、設定ファイルの global settings セクションの perm_cache
行を編集してください (単位は kB です)。
または、オプション authrec=off
を source セクションに追加することにより、 pdnsd が hosts ファイルを先制的に調達するのを防ぐことができます。何らかの理由で authrec を off に設定しても機能しない場合、簡単な回避策は、システム情報のみを含む別のホストファイル /etc/hosts-pdnsd など
を作成し、代わりに source セクションをポイントすることです元のホストファイルをそのまま残します。この方法で、 pdnsd は検索を実行するときにのみ /etc/hosts
を参照します。たとえば、次のとおりです。
/etc/hosts-pdnsd
#<ip-address> <hostname.domain.org> <hostname> 127.0.0.1 localhost.localdomain my_hostname ::1 localhost.localdomain localhost
共有サーバー
ネットワーク上に複数のコンピュータが存在する場合、全てのコンピュータで pdnsd を DNS サーバーとして使うことができます。ひとつの DNS キャッシュをネットワーク全体で共有することで、ルックアップの速度がもっと高速になります。他のコンピュータから使用できるようにするには、global
セクションの server_ip
をネットワークインターフェイスの名前 (例: eth0
) に設定してください。ファイアウォールを使っている場合、ネットワーク上のアドレスからのポート 53 への接続を許可するようにしてください。
これで、ネットワーク上の他のコンピューターを構成して、PDNを実行しているコンピューターをプライマリDNSサーバーとして使用できます。
名前でブロック
pdnsdを使用すると、結果を返してはならないホストまたはドメインを指定できます。これにより、特にプリミティブ広告またはコンテンツブロッカーとして使用できます。 pdnsd.conf
に新しい neg
セクションを作成します。否定セクションには2つの主要なオプションがあります。 name
は、ブロックするホストまたはドメインの名前です。 types
を domain
に設定して、特定のドメイン内のすべてのホストをブロックできます。デフォルトの pdnsd.conf
は、doubleclick.netからのすべての広告をブロックする例を示しています。
ブロックごとに1つのドメインしか設定できないので、追加、トラッカー、悪意のあるコンテンツをブロックするためにはうまくスケールしません。しかし、source
セクションを追加することは可能です (既存の /etc/hosts
を読み込むものに加えて) このセクションは、ドメインを特別な IP アドレス 0.0.0.0 にバインドする形式 – ただし、/etc/hosts
ではワイルドカードが許可されていないため、サブドメインはブロックされません。これを行うことは、ルールを /etc/hosts
に追加することと同じですが、一部のアプリケーションを破壊する可能性のある巨大な /etc/hosts
ファイルをを避けることができます。
pdnsd-ctl
pdnsd-ctl(8) man ページより:
- pdnsd-ctl は永続的なキャッシュを使う DNS プロキシサーバーである pdnsd を制御します。pdnsd-ctl を使う前に (pdnsd のコマンドラインや設定ファイルでオプションを指定して) ステータス制御ソケットを有効にする必要があるので注意してください。
これを行うには、オプションを含めます
status_ctl = on;
/etc/pdnsd.conf
のグローバルセクションにあります。
/etc/pdnsd.conf
でキャッシュディレクトリを変更した場合は、-c
オプションを指定して pdnsd-ctl
を実行する必要があります。
# pdnsd-ctl -c path/to/cache
以下のようなコマンドが使えます。
キャッシュを表示:
# pdnsd-ctl dump
キャッシュを消去:
# pdnsd-ctl empty-cache
DNSCrypt
pdnsd は DNSCrypt と一緒に使うことができます。DNSCrypt はドメイン名のルックアップを暗号化します。必要になったときに pdnsd は DNSCrypt を呼び出します。設定例は DNSCrypt#pdnsd にあります。
トラブルシューティング
result of uptest for 192.168.x.x: failed
ログに次のように表示されていても、ISPの dynamic DNS に正常にpingを送信できます。
$ journalctl -f -u pdnsd.service
result of uptest for 192.168.x.x: failed
/etc/pdnsd.conf
のグローバルセクションに設定されているインターフェイスが存在することを確認します。
interface = any;
もしくはサーバーセクションにあるもの。
interface=enp2s0;
正しい名前は、ifconfig
を実行して見つけることができます。
FAQ
- Q) あんまり速くありません。なぜ?
- A) ローカル DNS キャッシュを使うことによる速度の向上はサーバーに接続するまでにかかる時間によります。スループット (いわゆる速度) に影響はありません。複数のサーバーから小さなダウンロードを行う、ウェブの閲覧などで違いは最も明白になります。接続速度が遅い、特にダイアルアップ接続などでは、スループットがボトルネックになるため、目で見てわかるほどの違いは生まれません。
- Q) 前より遅くなっているんですが?
- A) おそらく
pdnsd.conf
のサーバーセクションのどれかでproxy_only
オプションがオフになっています。デフォルトで、pdnsd はできる限り正確なレスポンスを得るために複数の DNS サーバーに頻繁にリクエストを行います。proxy_only
オプションはこの機能を無効化します。ISP によって提供されている DNS サーバーを使っている場合はオンにしたほうが良いでしょう。