web-dev-qa-db-ja.com

非表示のプライマリ設定で実際のプライマリDNSをSOAエントリとして設定しないとどうなりますか？

非表示のプライマリDNSサーバーをセットアップしたい、つまり自分のサーバーでゾーンファイルをホストしていますが、すべての要求は専用のDNS会社がホストするセカンダリDNSサーバーに送信する必要があります。私のDNSサーバーは、再帰リゾルバやエンドユーザーが使用するべきではありません。上記の会社は私のサーバーからのゾーン転送でゾーンファイルをコピーします。理想的には、私のサーバーがこのDNS設定に存在することを誰も知らないはずです。

もちろん、そのような設定のすべてのNSレコードは、DNS会社のネームサーバーをポイントします。しかし、SOAレコードについてはわかりません。

私の理解によると、このセットアップは私のサーバーが「権限の開始」であることを意味し、したがって、私はそれをSOAで指定する必要があります。 serverfaultの別の回答 によると、MNAMEは「このゾーンの元のデータまたはプライマリデータソースであったネームサーバーの<domain-name>」に設定する必要があります。

それほど問題なくできれば、NS server in SOA and list point SOA to私のネームサーバーホスティング会社。

実際にcompany.example.comを自分のサーバーmyserver.example.orgではなくSOAとして設定した場合、どのような影響がありますか？

  • RFCに違反しますか？
  • DNSシステムの一部が機能しなくなりますか？ （SOAのエントリは動的更新に使用されますが、外国人からの動的更新を受け入れるつもりもないし、自分で送信するつもりもないことを読みました）
  • プライマリDNSの連絡先として電子メールアドレスを誤って指定したため、ネームサーバーホスティング会社が利用できますか？ （SOAのメールアドレス欄）
  • SOAでいくつかの問題を解決するために、異なるホスト名とメールアドレスを混在させることはできますか？例：company.example.com to SOA server、to [email protected]メール連絡用？
domain-name-systemdns-hostingsoa-record
2
Aufziehvogel

（他のドメインからの）外部委託されたネームサーバーを使用することはDNS標準の違反ではありませんが、それは隠されたプライマリ構成のようには聞こえません。 SOAでプライマリとして指定されたNSは、NSレコード内にある必要がありますが、実際に導入されたプライマリサーバーが実際の元のソースになるようにサーバーを構成する必要があるという意味ではありませんデータの。

たとえば、プライベートDNSSECキーを持つプライマリサーバーを世界に公開したくない場合は、これは、公表されているプラ​​イマリサーバーに、一部のWebアプリケーションのように、簡単に侵害できる他の機能がある場合に特に役立ちます。

例を見てみましょう。構成はBINDを想定しています。

$Origin example.com.
@       IN      SOA     ns1.example.com. hostmaster.example.com. (
                        2020053100 ; serial
                        7200       ; refresh (2 hours)
                        3600       ; retry (1 hour)
                        604800     ; expire (1 week)
                        86400      ; minimum (1 day)
                        )
@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
@       IN      NS      ns3.example.com.

ns1     IN      A       192.0.2.10
ns2     IN      A       198.51.100.20
ns3     IN      A       203.0.113.30

Diagram of DNS server locations and interactions

  • 非表示のマスターがゾーンにリストされていません。

    • このサーバーは、IPアドレス172.16.10.40を持つプライベートネットワーク上にのみあります。
    • このサーバーはDNSSSEC署名を行うため、example.com.signedを使用しました。

    • example.comのマスターとして構成され、パブリックプライマリからのゾーン転送を許可しますが、LANのみを使用します（またはVPNにすることもできます）。

      zone "example.com" {
    type master; 
    file "/etc/bind/db/example.com.signed";
    allow-transfer { 172.16.10.20; };
    notify explicit;
    also-notify { 172.16.10.20; };
};

    • notify explicitはNSでプライマリとしてリストされているサーバーを除いて、SOAとしてリストされているサーバーにのみ通知するため、also-notify＆notify yesを使用して通知を手動で設定します。これは、そのままでは機能しません。

  • パブリックプライマリサーバーns1.example.com

    • このサーバーには、パブリック192.0.2.10とプライベート172.16.10.20の2つのIPアドレスがあります。

    • これはゾーンのスレーブとして構成されており、他のNSからのゾーン転送を許可します。

      zone "example.com" { 
    type slave; 
    file "/etc/bind/db/example.com"; 
    masters { 172.16.10.40; };
    allow-transfer { 198.51.100.20; 203.0.113.30; };
    notify yes;
};

  • パブリックセカンダリサーバーns2.example.com＆ns3.example.com。

    • この例では、これらのサーバーは完全に別の場所にあり、 必須ネットワークの多様性と地質学的冗長性の両方を提供しています。

    • これらのサーバーは、パブリックプライマリからゾーン転送を実行します。

      zone "example.com" { 
    type slave; 
    file "/etc/bind/db/example.com"; 
    masters { 192.0.2.10; };
};
1
Esa Jokinen