内部ネットワークのBINDの一部のDNSエントリを上書きする
単一のゲートウェイを介してインターネットに接続された、BINDを実行しているDNSサーバーを備えた内部ネットワークがあります。私のドメイン「example.com」は、外部DNSプロバイダーによって管理されています。そのドメインの一部のエントリ、たとえば「Host1.example.com」と「Host2.example.com」、およびトップレベルのエントリ「example.com」は、ゲートウェイのパブリックIPアドレスをポイントしています。
内部ネットワークにあるホストに、「Host1.example.com」、「Host2.example.com」、「example.com」をゲートウェイではなく内部IPアドレスに解決してもらいたい。 「otherhost.example.com」などの他のホストは、引き続き外部DNSプロバイダーによって解決される必要があります。
「Host1.example.com」と「Host2.example.com」のBINDに2つの単一エントリゾーンを定義することで、Host1とHost2エントリに対してこれを行うことに成功しました。ただし、「example.com」のゾーンを追加すると、そのドメインのすべてのクエリはローカルDNSサーバーによって解決されます。 「otherhost.example.com」をクエリするとエラーになります。
ドメインのsomeエントリのみをオーバーライドするようにBINDを構成し、残りを再帰的に解決することは可能ですか？
最善の方法は、Bind 9.8.1以降の応答ポリシーゾーンを使用することです。これにより、任意のゾーンの単一レコードをオーバーライドできます（そのためにサブドメイン全体を作成する必要はなく、変更する単一レコードのみを作成できます）。CNAMEをオーバーライドできます。Unboundなどの他のソリューションではCNAMEをオーバーライドできません。 。
https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html
EDIT：次に、これを適切に実行しましょう。上記のリンク先のチュートリアルに基づいて、私がやったことを文書化します。
私のOSはRaspberry Pi用のRaspbian 4.4ですが、この手法はDebianとUbuntuで変更を加えなくても、または他のプラットフォームでは最小限の変更で機能するはずです。
Bind設定ファイルがシステム上に保持されている場所に移動します-ここでは/etc/bindにあります。そこにdb.rpzというファイルを作成し、次の内容を含めます。
$TTL 60
@ IN SOA localhost. root.localhost. (
2015112501 ; serial
1h ; refresh
30m ; retry
1w ; expiry
30m) ; minimum
IN NS localhost.
localhost A 127.0.0.1
www.some-website.com A 127.0.0.1
www.other-website.com CNAME fake-hostname.com.
それは何をするためのものか？
www.some-website.comのIPアドレスを偽のアドレス127.0.0.1で上書きし、そのサイトのすべてのトラフィックをループバックアドレスに効率的に送信しますwww.other-website.comのトラフィックをfake-hostname.comという別のサイトに送信します
ここで使用できるバインドゾーンファイルに入る可能性のあるものすべて。
これらの変更を有効にするには、さらにいくつかの手順があります。
named.conf.localを編集して、このセクションを追加します。
zone "rpz" {
type master;
file "/etc/bind/db.rpz";
};
上記のリンク先のチュートリアルでは、zone "rpz" { }に項目を追加するように指示していますが、簡単な設定では必要ありません。ここで示したのは、ローカルリゾルバーで機能させるための最低限のものです。
named.conf.optionsを編集し、options { }セクションのどこかにresponse-policyオプションを追加します。
options {
// bunch
// of
// stuff
// please
// ignore
response-policy { zone "rpz"; };
}
バインドを再起動します。
service bind9 restart
それでおしまい。ネームサーバーは、これらのレコードのオーバーライドを今すぐ開始する必要があります。
変更する必要がある場合は、db.rpzを編集してから、Bindを再起動します。
おまけ：DNSクエリをsyslogに記録して、進行状況を監視できるようにする場合は、named.conf.localを編集し、次のステートメントを含むloggingセクションがあることを確認します。
logging {
// stuff
// already
// there
channel my_syslog {
syslog daemon;
severity info;
};
category queries { my_syslog; };
};
Bindをもう一度再起動すると、それだけです。
Bindを実行しているマシンでテストします。
Dig @127.0.0.1 www.other-website.com. any
別のマシンでDigを実行する場合は、@ 127.0.0.1の代わりに@ the-ip-address-of-Bind-serverを使用してください。
私はこのテクニックを大成功させて、作業中のウェブサイトのCNAMEをオーバーライドし、テスト中の新しいAWSロードバランサーに送信しました。 Bindを実行するためにRaspberry Piが使用され、RPiもWiFiルーターとして機能するように構成されていたため、RPiで実行されているSSIDにデバイスを接続することで、テストに必要なDNSオーバーライドを取得しました。
「dnsmasq」を調べると、解像度を微調整してかなり賢いことができます。
あなたが探しているのは Webopedia で定義されているスプリットDNSです。
分割DNSインフラストラクチャでは、同じドメインに2つのゾーンを作成します。1つは内部ネットワークで使用され、もう1つは外部ネットワークで使用されます。スプリットDNSは、名前解決のために内部ホストを内部ドメインネームサーバーに転送し、名前解決のために外部ホストを外部ドメインネームサーバーに転送します。
基本的に、外部ゾーンファイルのコピーを作成し、それを内部DNSサーバーに反映させ、内部ネットワークに特に必要なレコードを変更または追加する必要があります。これはかなり一般的な設定ですが、「外部」レコードを2つのDNSサーバー間で同期させておくのは面倒な場合があります。パブリックサーバーでレコードを作成または変更する場合は、プライベートサーバーでもレコードを作成または変更する必要があります。
これは、使用するDNSサーバーの実装に関係なく実装できます。ほとんどの設定では、外部ネットワークにサービスを提供するDNSサーバーと、内部ネットワークにサービスを提供する別のDNSサーバーがあります。 BINDを使用すると、他の実装として、named.confファイルのゾーンセクション内の「allow-query」ステートメントを使用して、両方のバージョンのゾーンを同じサーバーに置くことができます。
BINDのもう1つの可能性（私はこれを試したことはありません）は、内部で使用するレコードのみを使用して、内部DNSサーバーにexample.comドメインを設定することです。次に、「forwarder」と組み合わせて「first」引数を使用して「forward」ステートメントを設定します。理論的には、これは外部DNSサーバー（「フォワーダー」で設定されているように、内部レコードを持たない回答を要求し、失敗の応答を返します）を要求します。次に、内部サーバーが自身を調べて回答を探します。それがうまくいくかどうかは確かですが、それは考えです。
BINDでは、目的のホスト名を使用してゾーンを定義することで、この結果を得ています。いくつかのホストのみをオーバーライドする場合は、この方法で問題ありません。
私のゾーン宣言は次のようになります：
zone "override.example.com" {
type master;
notify no;
file "zone-config/override.example.com";
};
私のゾーン定義は次のようになります：
$TTL 4H
@ IN SOA ns.override.example.com. root.override.example.com. (
2009072215 ; Serial
3600 ; Refresh
600 ; Retry
604800 ; Expire
3600 ) ; Minimum
;
NS ns
IN NS ns.override.example.com.
IN A 192.168.1.100
ns IN A 192.168.1.100
したがって、イントラネットDNSとISP DNSでexample.comをクエリすると、同じIPが取得されますが、override.example.comをクエリすると、イントラネットDNS（プライマリ）にアクセスできる場合、異なる結果が得られます。
Dnsmasqを使用すると、非常に簡単になります。 http://www.thekelleys.org.uk/dnsmasq/doc.html DNSサーバーとして機能しますが、ローカルDNSサーバーから応答を取得します。ゾーンファイルをいじることなく、単一のドメインレコードを上書きできるのは素晴らしいことです。
実際のところ、わずかに異なるとはいえ、これを行う別の方法があります。同じ状況で、外部と内部で使用されるドメインがあり、外部の静的ホストと動的ホストがあります。本当に痛いものは、外部の動的なものだけです。ソリューションはおそらく最もエレガントではありませんが、小さなスクリプトで実装可能です。ほとんどの場合、動的DNSプロバイダーのAPIを使用して独自の動的DNSスクリプトを実行しています。このスクリプトを5分ごとにcronで実行します。
1）外部IPを取得します。変わった？出口なし。
2）IPを変更し、新しいIPアドレスでdyndns-providerのAPIを呼び出し、
3）外部IPを使用してdb.mydomain.comをsed
4）バインドを再開します。
ホームネットワークで非常に確実に機能します
あなたはすでに正しい軌道に乗っています。
内部DNSサーバーで、「example.com」のすぐ下にあるすべての例外ホストのゾーンを定義する必要があります。これらの例外を最小限に抑えるには、すべての内部マシンに「hosta.internal.example.com」という名前を付けるのが一般的です。DNSサーバーはほとんどのクエリを外部DNSサーバーに送信しますが、ゾーンには「internal.example.com」に対して権限があります。 （小さな操作を通過すると、通常、クライアントが向けられるDNSサーバーがいくつかあり、それらが "internal.example.com"に向けられる別の権威DNSがあります。）
通常、ホストが外部と内部の両方に到達可能でなければならない場合にのみ、説明した例外が作成されます。それでも、外部からは「Host1.example.com」、内部からは「Host1.internal.example.com」を使用することもできます。内部ホストは、「internal.example.com」内の名前を検索するように構成されます。サーバーの証明書がサーバーを「Host1.example.com」として識別している場合など、すでに行っていることが適切である場合があります。その場合は、クライアントが接続する名前にしたいとします。