複数のDNSサーバーを試すためのSamba4内部DNSフォワーダーのセットアップ


1

最近までのネットワーク設定では、いくつかの内部名のDNSサーバーとして機能するSamba4サーバーがあり、その他すべて(つまり、インターネット上のもの)のためにメインルーターに転送していました。メインルーター、Dlink DI-624、これらの要求をモデムから取得する適切なDNSサーバーに転送できてうれしかったです。

まあ、それはDI-624が死ぬまで、しゃっくりなしで、うまくいきました。新しいルーターにはDNS転送機能がないため、当面はインターネット接続からプライマリDNSサーバーを取得し、それをdns forwarder =D-Linkのアドレスがあった行のsmb.confに配置します。

これに関する私の主な理由は、ISPが1年に数回行うことが知られているプラ​​イマリDNSサーバーを変更した場合、インターネットのダウンタイムと一般的な混乱が発生するまでです。プロセスでファイル共有を中断するSambaを再起動します(より多くのダウンタイム)。これはすべて、古いルーターがきちんと処理してくれたものです。

残念ながら、スペースまたはコンマdns forwarderを使用smb.confしているかどうかは、複数の引数をとらないようです。必要のない場合はBINDを実行したくありませんが、この問題を解決できれば、Sambaに組み込まれている内部DNSからの切り替えを気にすることはありません。

CentOSがルーターから現在のDNSサーバー設定を取得し、smb.confを更新する方法はありますか?または、少なくとも試してみるDNSサーバーのリストを教えてください。それとも、D-Linkがかつて使用していたように、自動的に物事を処理しますか?

回答:


2

解決策1.安価な新しいルーターを入手する-新品の30ドルのルーターにDNS転送機能が搭載されることはほとんどありません。購入前に製品仕様を確認してください!また、新しいルーターにDNS機能がないことも奇妙です。マニュアルと設定インターフェイスを徹底的にチェックしましたか?

解決策2. GoogleのパブリックDNSフォワーダーを使用します。プライバシーを心配しない限り、Googleの分散DNSシステムはローカルのbind9キャッシング専用サービスを使用するより266%高速であると主張しています(Googleがクエリを収集する場合としない場合があるという事実について)

OPは、ISCのバインドがあまりにも多くのオーバーヘッドであると考えるならば、最後に、多分のような光リゾルバdnsmasqかをunbound助けるために来るかもしれません


Re:sol1、ええ、ISPの標準ルーター+モデムコンボ(2701hg-g)がDNS転送をサポートしていないことに驚いています。Re:sol2、それは興味深いページです... 8.8.8.8は素晴らしいオプションのように聞こえますが、それが報告するすべてのエラーは何ですか?
ケブ

また、プライマリDNSが間違っているため、変更できません。そのため、数字を信頼するかどうかはわかりません
...-Kev

どのエラーに言及しているのかわかりません。namebenchについて話すと、そのページのヘッダーが間違っているだけで、結果を表示するには少し下にスクロールする必要があります。
Costin Gușă

はい、namebench--それはヘッダーにありますが、結果にも多数の「誤った」エントリがあります。
ケブ

ここでソリューション1を使用しました。
ケブ14年

0

バインドインスタンスをインストールし、named.conf.optionsの好きなリストに転送するように設定してから、sambaがそれを指すようにすることができます。何も置き換える必要はありません。sambaをバインドするように指示し、好きなサーバーのリストにバインドするだけです。

唯一の欠点は、現在DNSがファイアウォール内にあり、転送されたクエリが応答するための穴を開ける必要があることです。


それが明確に質問で述べています:)彼はバインドを実行したくない
コスティングサ

彼は、サンバの解決をバインドに置き換えたくないと言ったが、これは必要ではない。その点を明確にするために、回答を更新しました。ありがとう!
フランクトーマス

OPがisc bindのオーバーヘッドが大きすぎると判断した場合、dnsmasqまたはunboundのようなライトリゾルバが役立つ可能性があります。
Costin Gușă

「転送されたクエリが応答するための穴を開けなければならない可能性が高い」を展開していただけますか 他のすべてのアウトバウンドリクエストと同様に機能しませんか?
ケブ

1
UDPは、TCPのように接続指向ではないため、ステートフルフィルタリングの処理が難しく、そのため、確立された接続の一部が内部から始まることをNATウォールに知らせるフラグがないためです。ステートフルパケットフィルタは、タイミングと送信元/宛先のアドレス指定に基づいてフローを作成するために最善を尽くしますが、サーバーの応答が内部からの要求に従っていると常に判断できるわけではありません。すべての応答を確実に取得するには、通常、UDP \ 53に穴を開ける必要があります。
フランクトーマス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.