DNSのしくみを理解できないか、DNSを正しく構成できません(どちらも適切ではありません)。私は現在ドメインで作業しています。これをwebdomain.comと呼びます。すべての内部ユーザーがdotterにアクセスして、他のドメインと同じようにパブリックDNSエントリを取得できるようにする必要があります。世界。次に、その上で、サーバーや機器をテストするために、公開されていないいくつかのオーバーライドDNSエントリを提供できるようにしたいと考えています。例として:
outside.webdomain.com-dotterからもこれを取得する必要があります
testing.webdomain.com-これは私の内部DNSコントローラから取得する必要があります
毎ターン実行しているように見える問題は、webdomain.comのゾーンを含む内部DNSコントローラーがある場合、can指定された内部エントリを取得するがneverパブリックDNSサーバーから何かを取得します。これは、私が使用するDNSサーバーの種類に関係なく当てはまります。LinuxBind9とWindows 2008ドメインコントローラーの両方を試しました。
私の大きな質問は次のとおりです:システムが指定された内部DNSをチェックできるはずだと考えるのは無理ですか?要求されたエントリが存在しない場合は、指定されたパブリックDNSサーバーにフェールオーバーする必要があります-または-これはDNSの動作方法だけではなく、ソースで迷っていますか?
それは、内部DNSサーバーにそれが満たすことができないすべての要求をdotterに転送するように指示するのと同じくらい簡単なはずですが、それは機能していないようです。これはファイアウォールの問題ですか?
前もって感謝します
[〜#〜]拡張[〜#〜]
わかりました、それで私はたくさんの研究をして、そしてこれに数時間差し込んでいました。これは私のnamed.confにあり、それでも同じ結果が表示されます。内部呼び出しは供給されますが、外部(ゾーン制御ドメイン内)はダンプされます。どんな援助も素晴らしいです!また、これは私が使用しているUbuntu 9.04 OSです。
Code removed because it was wrong.
正しい方法-質問を閉じた後に追加
さて、ここserverfaultの人たちのおかげで、これは私のサーバーで完璧に機能し、はるかに簡潔に動作します。これがあなたのやり方です。 bind9の基本インストールから、named.conf.localファイルを編集して、リダイレクトする各サブドメインのゾーンに追加します。
/ etc/bind/named.conf
// WEBDOMAIN.COM ENTRIES
zone "test.webdomain.com" {
type master;
file "/etc/bind/zones/test.webdomain.com";
};
zone "alpha.webdomain.com" {
type master;
file "/etc/bind/zones/alpha.webdomain.com";
};
zone "beta.webdomain.com" {
type master;
file "/etc/bind/zones/beta.webdomain.com";
};
// INTERNETSITE.COM ENTRIES
zone "internal.internetsite.com" {
type master;
file "/etc/bind/zones/internal.internetsite.com";
};
zone "dev.internetsite.com" {
type master;
file "/etc/bind/zones/dev.internetsite.com";
};
/etc/bind/named.conf.optionsファイルを編集し、使用するフォワーダーを正しい場所に追加します。
/ etc/bind/named.conf.options
options {
directory "/var/cache/bind";
forwarders {
208.67.222.222;
208.67.220.220;
8.8.8.8;
8.8.4.4;
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
/ etc/bind/zones /にゾーンと呼ばれる新しいフォルダーを作成し、上記で作成したゾーンごとに、上記の「ファイル」属性と一致する新しいファイルを追加します。例としてtest.webdomain.comを使用:
/ etc/bind/zones/test.webdomain.com
$TTL 604800
@ IN SOA test.webdomain.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS test.webdomain.com.
test.webdomain.com. IN A 10.0.1.20
10.0.1.20は、この(サブ)ドメインに転送するAレコードのIPアドレスです。このようにすることで、test.webdomain.comのレコードはサブドメインに対してのみ権限を持ち、グローバルDNSは通常どおり他のサブドメインまたはルートドメインを提供します。
内部DNSサーバーにTesting.webdomain.comのDNSゾーンを作成する必要があります。このように、webdomain.com DNSは内部サーバーによってホストされず、dotterによってホストされます。
誰かがwww.webdomain.comをクエリすると、リクエストはルックアップ用のdotterに転送され(ローカルDNSサーバーはそのゾーンに対して権限がないため)、testing.webdomain.comに対するリクエストは内部DNSサーバーによって処理されます。
Split-view DNS が必要です。ボーダーマシンでは、externalリゾルバーを使用します。テスト環境では、別のinternalリゾルバーを使用します。内部リゾルバーは、DNSのテストエントリと1つのビューからの回答を持ちます。ただし、外の世界ではゾーンの別の「ビュー」が表示され、テスト環境が省略されます。
興味があるかもしれない他のSFエントリ:
今日は延長投稿をざっと読む時間しかないので、ここで一目見てみましょう。
options {
directory "/etc/bind";
listen-on { // why are these lines needed?
10.0.1.5; // the way it is set up, only your loopback
127.0.0.1; // and your LAN clients will be able to
// get answers; the outside world can't see boo
// because there's no interface/port pair
// to contact. I would just get rid of this and
}; // not worry about what interfaces are being bound to
// BTW, that listen-on line is why your outside queries are failing.
auth-nxdomain no;
allow-query { any; };
recursion no;
version "0";
};
また、外部のmatch-clientsステートメント
view "external" {
match-clients { !localnets; any; };
することができます
view "external" {
match-clients { any; };
なぜなら、match-clientsに追加するとき、最初に一致するものは何もないと想定しているからです。 ACLを無効にしても、それほど多くは追加されません(そのビューでACLが「存在する」ことは決してないため、キャンセルする理由はありません)。
私はおそらくいくつかのことを逃したと確信していますが、これらは最も明白な犯人です。
ゾーンの定義が正しくないようです。 "webdomain.com"として宣言されたネームサーバーのIPアドレスがありません。
ゾーン定義を次のように変更することをお勧めします
$TTL 604800
@ IN SOA webdomain.com. email.webdomain.com. (
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS webdomain.com.
webdomain.com. IN A 10.0.1.5
test IN A 10.0.1.20
次にサーバーを再起動します(例:/etc/init.d/bind9 restart
)。
エラーのため、ゾーンをロードできなかったため、ドメインを解決できませんでした。
Windows DNSサーバーで、testing.webdomain.com用の新しい[〜#〜] zone [〜#〜]をセットアップします。最初のホストを追加するときは、名前フィールドを空白のままにして、内部ユーザーが解決するIPアドレスを入力します。
このサーバーはそのゾーンに対して権限を持つため、リクエストはそのIPに送信されるため、外部の解決と競合しません。
私はすべてのサイトでmail.corpdns.comにこれを使用しています(ユーザーがWebメールにアクセスするときに内部サーバー名を使用することを覚えていないためなど)。
これはLinux/Bindでも実行できると思いますが、手順はわかりません。