systemd-resolvedは、とりわけIPアドレス127.0.0.53のローカルループバックインターフェイスを受信してDNSサーバーとして機能するデーモンです。
デーモンが別のインターフェイスでリッスンしたいと思います。私の使用例は、Dockerコンテナに公開して、Dockerコンテナにsystemd-resolvedによって提供されるDNSキャッシュを共有させることです。ホストをドッカーコンテナのDNSサーバーとして構成する方法を知っていますが、少なくともデフォルトでは、systemd-resolvedはこれらのDNSクエリがループバックインターフェイスではなくドッカーブリッジインターフェイスから来るため拒否します。
dnsmasq（systemd-resolvedに似たツール）を使用してこれを実行しました。listen-address=172.17.0.1構成ファイルに追加。残念ながら、システムで解析された対応するエントリが見つかりません。
少なくともUbuntu 18.04では、systemd-resolvedがデフォルトであるため、この構成に適したソリューションが必要でした。
systemd-resolvedがリッスンするインターフェイスを設定する方法はありますか？
ベストアンサー1
あなたはできません。上記のcristian-rodríguezのようにループバックのみを提供するように厳密に設計されています。
+ iptables NATを使用する代替ソリューションでもありませんnet.ipv4.conf.all.route_localnet=1（例：https://serverfault.com/questions/211536/iptables-port-redirect-not-working-for-localhost)、https://superuser.com/questions/594163/how-do-i-route-a-port-range-in-a-linux-host-to-a-guest-vm）、そしてhttps://stackoverflow.com/questions/18580637/iptables-redirect-from-external-interface-to-loopbacks-port) は、systemd-resolve がターゲットがループバックネットワークの外にあるかどうかを明示的にチェックするため、機能します。以下のコードを参照してくださいstatic void dns_stub_process_query(Manager *m, DnsStream *s, DnsPacket *p)
if (in_addr_is_localhost(p->family, &p->sender) <= 0 ||
in_addr_is_localhost(p->family, &p->destination) <= 0) {
log_error("Got packet on unexpected IP range, refusing.");
dns_stub_send_failure(m, s, p, DNS_RCODE_SERVFAIL, false);
goto fail;
}
socat回避策は、リスニングドッカーインタフェースを使用してそれをsystemd-resolvedに渡すことです。次の行はこの問題を解決します。必要に応じてTCPが受信するように変更します。
socat UDP-LISTEN:53,fork,reuseaddr,bind=172.17.0.1 UDP:127.0.0.53:53