最小限の構成ですべてのドメインを管理するにはどうすればよいですか？

これは、DNSサーバーの管理に関する正規の質問です。

私は100ほどのドメインを持っています。これらのドメインはすべて同じように構成する必要がありますが、これらのドメインごとに新しいゾーンやゾーンファイルを構成しなければならないのは、非常に時間の無駄のようです。これを自動化するより良い方法がなければなりません！

私は何かに取り組んでいると思います...というゾーンを作成.するか、DNSソフトウェアで他の機能を使用して、Aレコードが要求されたときに常に特定のIPを返す場合、これにより、希望する目的にかなり近づくようです結果。私のサーバーはリクエストに対して信頼できる応答をしており、管理がとても簡単です！

ネームサーバー検証ソフトウェアがこれらのドメインのチェックを開始するまで、これはうまく機能していました。NSレコードを追加することでほとんどのエラーを解消できることを理解しましたが、私のソフトウェアではSOA、同じゾーンファイルに複数のレコードを配置できません。

この複数SOAレコードの問題を回避するにはどうすればよいですか？

質問を誤解しない限り、私は定期的にBINDでこれを行っています。各ゾーンが完全に同一である限り、問題はないようです。

私のプライマリネームサーバーにはnamed.conf、一般的なゾーンファイルを指すエントリがあります。

zone "example.com" {
        type master;
        file "primary/example.GENERIC";
};

zone "example.co.uk" {
        type master;
        file "primary/example.GENERIC";
};

そしてprimary/example.GENERIC、例えば言うゾーンファイル

;; Start of Authority
@       IN      SOA     ns.teaparty.net. dns.gatekeeper.ltd.uk. (
                        2004091201      ; serial number YYYYMMDDNN
                        28800           ; refresh  8 hours
                        7200            ; retry    2 hours
                        864000          ; expire  10 days
                        3600 )          ; min ttl  1 day
;;
;;      Name Servers
                IN      NS      ns.teaparty.net.
                IN      NS      ns2.teaparty.net.

そして、私はこれらのゾーンに関する問題をまったく認識していません。私は質問を誤解している、または私のドメインが実際には機能しないと言われても構わないが、それまでは私にとっては機能すると思う。

セカンダリで同じトリックを引くことはできないことに注意してください。各ゾーンには異なるファイルを格納する必要があります。ただし、そのファイルのコンテンツは、プライマリからのゾーンxferによって入力され、最新に保たれるため、これは大きな問題ではありません。

生活を楽にするために使用できるショートカットがいくつかあります。

ファイルを使用してゾーンデータを格納するバインドまたは同様のソフトウェアを使用する場合：たとえば、ゾーンを同じファイルにポイントします。

zone "example.net" {
    type master;
    file "/etc/bind/zone/default.zone";
};

zone "example.org" {
    type master;
    file "/etc/bind/zone/default.zone";
};

特定のDNS省略形を利用できるため、ユニバーサルゾーンファイルを作成できます。

$TTL 1h      ; default expiration time of all resource records without their own TTL value
@  IN  SOA   ns1.example.com. username.example.com. ( 
                               20140218131405 ; Serial number YYYYMMDDHHMMSS
                                        28800 ; Refresh     8 hours
                                         7200 ; Retry       2 hours
                                       604800 ; Expire      7 days
                                        86400 ; Minimum TTL 1 day )
@             IN  NS    ns1.example.com.      ; ns1.example.com is a primary nameserver
@             IN  NS    ns2.example.com.      ; ns2.example.com is a backup nameserver
@             IN  MX    10 mail.example.com.  ; mail.example.com is the mailserver
@             IN  MX    20 mail2.example.com. ; the secondary mailserver
@             IN  A     192.0.2.1             ; IPv4 address for the bare domain
              IN  AAAA  2001:db8:10::1        ; IPv6 address for the bare domain
www           IN  A     192.0.2.1             ; www.domain
              IN  AAAA  2001:db8:10::1        ; IPv6 address for www.domain - note by starting the line with a blank it becomes the continuation of the previous record and this IPv6 record applies to www
wwwtest       IN  CNAME www                   ; wwwtest is an alias for www

これは、ドットで終わっていないゾーンファイルのホスト名.が常に展開$ORIGINされ、暗黙的にゾーン名に設定されるという事実を利用しています。そして、@の$ ORIGINのための短い手です。

個々のゾーンファイルを手動で管理するのではなく、ネームサーバーとプログラムで対話する方法を有効にします。

私は、当時使用していたLAMPスタックと非常によく合うRDMSをバックエンドとして使用できるPowerDNSを使用しました。Amazon Route 53のようなクラウドサービスもweb-APIを公開しています。

しかし、由緒あるBindも動的更新をサポートしています。これは、マスターサーバーに特別な形式のDNSメッセージを送信することにより、マスターサーバーのレコードを追加、置換、または削除する方法です。これらのメッセージの形式と意味は、RFC 2136で指定されています。

動的更新は、ゾーンステートメントにallow-updateor update-policy句を含めることで有効になります。詳細については、Bind Administrator Reference Manualを確認してください。

簡潔な答え

BINDで「ゼロ構成」セットアップを探している場合、それは存在しません。ルートゾーン（.）を設定することは良い考えのように見えますが、そうではなく、ニーズに合わせてDNSを破壊しないソリューションを見つける必要があります。

長い答え

昨年、この質問の変形を数回取得しています。

ここでの答えは非常に簡単です。単一のゾーン定義を設定することはできません。SOAこのコンテキストで複数のレコードを定義または合成できるソフトウェアはすべて壊れたソフトウェアであり、ServerFaultでは壊れた処理を行うことは話題になりません。この管理をより簡単にするDNSソフトウェアを選択するか、この特定のショートカットを使用しない別の戦略を考え出す必要があります。

生活をより簡単にするために使用できるいくつかのトリックは確かにあります...例としてBINDを使用すると、すべてが同じテンプレートゾーンファイルを参照する複数のゾーンを定義することはかなり一般的です。これは完全に合法であり、検証ソフトウェアは何の問題も検出しません。MadHatterの回答を参照してください。新しいドメインを取得するたびにゾーン宣言を追加するのはまだ「手間がかかりすぎる」ため、ほとんどの人はこのソリューションを無視しますが、この種のホスティングには「一度設定して立ち去る」オプションはありません。

新しいバージョンのBIND allow-new-zonesでは、新しいrndc addzone機能を使用して動的にゾーン定義を動的に作成できるというオプションがサポートされています。これを見て、ニーズに合っているかどうかを確認することをお勧めします。

提案されたソリューション以外では、オプションは多少制限されます。ソフトウェアが思い通りに機能しない場合、作業が行き詰まることがあります。

「ドメインは同じように構成する必要がある」と言うとき、それらは同じリソースレコードを保持する必要があることを意味しますか？その場合、DNAME1つのドメインを除くすべてのRRはよりクリーンなソリューションではないでしょうか？

@MadHatterが同じテンプレートファイルをインポートするというトリックを、厳密にあなたの質問の範囲内に留めながら、打ち負かすことはできません。私はLDAPバックエンドに対して同様のアプローチしか提供できません（私の場合、powerDNSで使用されます）。associatedDomain関連するSOAおよびNSレコードの属性を次のように追加します。

dn: dc=vanitydomains,ou=DNS,dc=myDIT
objectClass: dNSDomain2
objectClass: domainRelatedObject
dc: vanitydomains
associatedDomain: vanitydomain.ORG
associatedDomain: vanitydomain.NET
associatedDomain: vanitydomain.COM
associatedDomain: vanitydomain.INFO
sOARecord: NS1.example.com  sysadmin.example.com 2011100701 28800 1800 2592000 10800
dNameRecord: example.com
nSRecord: NS1.example.com
nSRecord: NS2.example.com