内部ネットワークの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」のクエリはエラーになります。

ドメインの一部のエントリのみをオーバーライドし、残りを再帰的に解決するようにBINDを構成することは可能ですか？

最良の方法は、バインド9.8.1以降の応答ポリシーゾーンを使用することです。任意のゾーンの単一のレコードをオーバーライドできます（そして、そのためにサブドメイン全体を作成する必要はありません、変更したい単一のレコードのみ）、CNAMEなどをオーバーライドできます。Unboundなどの他のソリューションはCNAMEをオーバーライドできません。

https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html

編集：その後、これを適切に行いましょう。上記のリンクされたチュートリアルに基づいて、私が行ったことを文書化します。

私のOSはRaspberry Pi用のRaspbian 4.4ですが、この技術はDebianとUbuntuに変更を加えることなく、または他のプラットフォームに最小限の変更を加えて機能するはずです。

バインド構成ファイルがシステム上で保持されている場所に移動します/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偽のアドレス127.0.0.1でIPアドレスを上書きし、そのサイトのすべてのトラフィックをループバックアドレスに効率的に送信します
• という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から、バインドを再起動してください。

ボーナス：DNSクエリをsyslogに記録する場合は、手順を監視し、編集named.conf.localしloggingて、これらのステートメントを含むセクションがあることを確認します。

logging {
    // stuff
    // already
    // there

    channel my_syslog {
        syslog daemon;
        severity info;
    };
    category queries { my_syslog; };
};

バインドを再度再起動すると、それだけです。

Bindを実行しているマシンでテストします。

dig @127.0.0.1 www.other-website.com. any

別のマシンでdigを実行する場合は、@ 127.0.0.1ではなく@ the-ip-address-of-Bind-serverを使用してください。

この手法を使用して、作業中のウェブサイトのCNAMEをオーバーライドし、テスト中の新しいAWSロードバランサーに送信しました。Raspberry Piを使用してBindを実行し、RPiもWiFiルーターとして機能するように構成されました。したがって、RPiで実行されているSSIDにデバイスを接続すると、テストに必要なDNSオーバーライドを取得できます。

未結合の再帰的なDNSサーバは、個々のリソースレコードを上書きする能力を持っています。

見てくださいlocal-zoneとlocal-dataで構成の設定マニュアル、例えば：

local-zone: "example.com." transparent
local-data: "foo.example.com. IN A 192.168.1.1"

のtransparent設定は、local-zoneが指定されていない名前に対して通常の再帰的な検索を行うように指示しlocal-dataます。

「dnsmasq」を調べると、解像度を微調整してかなり巧妙なことができます。

あなたが探しているのは、Webopediaによって次のように定義されているスプリットDNSです。

スプリットDNSインフラストラクチャでは、同じドメインに対して2つのゾーンを作成します。1つは内部ネットワークで使用され、もう1つは外部ネットワークで使用されます。スプリットDNSは、名前解決のために内部ホストを内部ドメインネームサーバーに誘導し、外部ホストは名前解決のために外部ドメインネームサーバーに誘導されます。

基本的に、外部ゾーンファイルのコピーを作成し、それを内部DNSサーバーで支えてから、内部ネットワークに特に必要なレコードを変更または追加する必要があります。これはかなり一般的な設定ですが、2つのDNSサーバー間で「外部」レコードの同期を維持するのは面倒です。パブリックサーバーでレコードを作成または変更する場合は、プライベートサーバーでもレコードを作成または変更する必要があります。

これは、使用するDNSサーバーの実装に関係なく実装できます。ほとんどのセットアップでは、外部ネットワークにサービスを提供するDNSサーバーと、内部ネットワークにサービスを提供する別のDNSサーバーがあります。BINDでは、おそらく他の実装として、named.confファイルのゾーンセクション内で「allow-query」ステートメントを使用することにより、同じサーバー上に両方のバージョンのゾーンを配置できます。

BINDのもう1つの可能性（これを試したことはありません）は、内部で使用するレコードのみを使用して、内部DNSサーバーにexample.comドメインを設定することです。次に、「first」引数を使用して「forwarder」ステートメントを設定します（「forwarders」と組み合わせて）。理論的には、これは外部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（プライマリ）にアクセスできる場合に異なる結果が得られます。

あなたはすでに正しい軌道に乗っています。

内部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」として識別している場合など、すでに実行していることが適切な場合があります。その場合は、クライアントを接続する名前にする必要があります。

dnsmasqを使用すると、本当に簡単になります。http://www.thekelleys.org.uk/dnsmasq/doc.html DNSサーバーとして機能しますが、ローカルDNSサーバーから回答を取得します。良い点は、ゾーンファイルをいじらずに単一のドメインレコードを上書きできることです。

実際のところ、これを行う方法は、おそらくわずかに異なっていても、別の方法があります。同じ状況があり、外部および内部で使用されるドメインがあり、外部の静的および動的ホストがあります。本当に痛いのは、外部の動的なものだけです。このソリューションはおそらく最もエレガントではありませんが、小さなスクリプトで実装できます。ほとんどの場合、動的DNSプロバイダーのAPIを使用して独自の動的DNSスクリプトを実行しています。5分ごとにこのスクリプトをcronで実行しています。

1）外部IPを取得します。変わった？出口なし。

2）IPを変更し、dyndns-providerのAPIを新しいIPアドレスで呼び出し、

3）db.mydomain.comを外部IPでsed

4）バインドを再起動します。

ホームネットワークで非常に確実に動作します