Defaults.Exposed › 修正 › ネームサーバー設定（多様性とSOA）

ネームサーバー設定（多様性とSOA） の直し方

ネームサーバーは、あなたのウェブサイトとメールがどこにあるかをインターネット全体に伝える名簿です。それらがすべて1つのネットワークにあって、それが落ちると、あなたのビジネスは同じ瞬間にインターネットから消えます—サイトもメールも、すべて。そしてそれらのサーバーの時計設定がいい加減だと、あなたが行った変更が何日も反映されないままになります。

あなたのビジネスにとっての結論： ドメインのすべてのネームサーバーが単一のネットワークにあると、そのネットワークへのひとつの障害や攻撃が、ウェブサイトとメールを同時にオフラインにします—社員に給料を払い広告を出しながら、どの顧客もあなたに到達できません。別途、設定ミスのSOAタイマーは、あなたのDNS変更（新サーバー、メールプロバイダーの切り替え、緊急のリダイレクト）の伝播を、数時間ではなく数日間続けさせます。

これで失いかねないもの

• すべてのネームサーバーがある単一のネットワークが悪い午後を迎え—障害やDDoS攻撃—ウェブサイトとメールが同時に消えます。顧客はエラーページを見て、営業の受信トレイは跳ね返り、ウェブ担当にできるのは他人のネットワークの復旧を待つことだけです。
• 大口顧客のセキュリティチームがベンダーチェックを行い、すべてのネームサーバーが冗長性なく1つのプロバイダーにあるのを見て、あなたのドメインを単一障害点と記録します—勝てたはずの契約に摩擦が生まれます。
• 新しいウェブホストへ移ったりメールプロバイダーを切り替えたりするのに、SOAレコードの『refresh』タイマーが誤っていると、他のDNSサーバーが何日も古いアドレスを配り続け—一部の顧客が死んだサイトに着地し、メールが二分されます。
• セキュリティインシデントでトラフィックを緊急にリダイレクトする必要があるのに、SOAタイマーが古いレコードを1週間キャッシュするよう世界に告げているため、1時間前に行った変更がまだインターネットの半分に届かず、問題が続きます。
• 2つのネームサーバーは技術的には2つの名前ですが、同じネットワークの同じラックに解決されます—持っていると思っていた冗長性は幻で、ひとつの障害が依然としてすべてを落とします。

なぜ重要か。 あなたのウェブサイトへのすべての訪問と、あなた宛のすべてのメールは、ネームサーバーへの照会から始まります。それらは、オンラインの存在の残りが乗る土台です。その土台に冗長性がなければ、ひとつの障害がすべてを一度に倒し、タイミング値が誤っていれば、行うすべての変更が反映に時間がかかります—最も余裕のないまさにそのときに。

これは何か、平易に言うと

誰かがあなたのウェブサイトに到達したりメールを送ったりする前に、そのコンピューターは単純な問いを尋ねなければなりません。『このドメインは実際どこにあるのか？』 その問いに答えるサーバーが、あなたのネームサーバーです。オンラインの存在全体の名簿の項目—サイトや受信トレイが関わる前に、すべての訪問者とすべてのメールが触れる最初のもの—です。

このページはその名簿を正しくする2つの部分を扱います：

1. 多様性 — 少なくとも2つのネームサーバーがあり、ひとつの障害がそのすべてを一度に黙らせないよう、本当に別の部分のネットワークにあるか？
2. SOAレコード — あなたのDNS回答をインターネットの残りがどれだけ信頼しキャッシュするかを制御するタイミング値を保持する小さな『start of authority』レコード。タイマーを誤ると、行うすべての変更が世界に届くのに時間がかかります。

どちらも華やかではありません。どちらも土台です。正しいときは考えもしませんが、誤っているときは、最も都合の悪い瞬間に気づきます。

これが招きうる損失

• すべてが一度にオフライン。 すべてのネームサーバーが1つのネットワークにあり、そのネットワークが障害やDDoS攻撃に見舞われると、ウェブサイトとメールが一緒に消えます。これは理論ではありません—単一のDNSプロバイダーが攻撃されて、潤沢な資源を持つ大企業が丸一日近くインターネットから落ちたことがあります。ネットワークをまたいだ冗長性があれば、ひとつの障害は乗り越えられます。なければ、全滅です。

• ベンダーチェックで失う商談。 大口顧客のセキュリティ・調達チームが契約前にチェックし、すべてのネームサーバーがフォールバックなしで1つのプロバイダーに集中しているのを見て、あなたのドメインを単一障害点と指摘します。勝てたはずの契約に摩擦を加える、小さく避けられる黒星です。

• 反映されない変更。 ウェブホストを切り替え、メールプロバイダーを移し、急いでトラフィックをリダイレクトする必要があります。SOAレコードの『refresh』や『expire』タイマーが誤っていると、他のDNSサーバーが何日も古い回答を配り続けます。顧客の半分は新サイトに、半分は死んだサイトに着地し、一部のメールは古いプロバイダーへ、一部は新しいほうへ流れます。1時間前に行った変更がまだ完了していません。

• すぐに終わらせられない緊急事態。 セキュリティインシデント中、トラフィックを侵害されたサーバーから今すぐそらす必要があります。SOAタイマーがレコードを1週間キャッシュするよう世界に告げていたら、あなたの修正はインターネット全体へじわじわと這い出す間、問題が噛みつき続けます。

• 本物でない冗長性。 ネームサーバーが2つあるので守られていると思い込む—でも両方が同じネットワークの同じラックに解決されます。最初のハードウェア障害がすべてを取り出し、頼っていた安全網は最初から存在しませんでした。

これの実体

ネームサーバーの多様性。 あなたのドメインは少なくとも2つのネームサーバーを列挙すべきで、理想的には本当に独立したネットワーク経路にあるべきです—同じマシンを指す2つの名前ではなく。裏では、各ネームサーバー名が1つ以上のIPアドレスに解決され、本当に重要なのは、それらのアドレスがインターネットのルーティングの異なる部分を占めるかです。本格的なDNSプロバイダーは、ネームサーバーを世界中の多くの別々のネットワークブロックや拠点に広げるので、同じプロバイダーの2つのネームサーバーでも本物で独立した冗長性を与えます。障害のケースはその逆で、両方の『ネームサーバー』が同じマシンである小さな単一ホストでは、ひとつの障害が全滅です。

技術的な読者への注記： 当社の検査はあなたのNSレコードを数え、その背後にどれだけ本物のネットワーク多様性があるかを見ます。主なシグナルは、ネームサーバーが解決される別個のIPネットワークブロックの広がり（おおまかにIPv4は/16範囲、IPv6は/32）で、別個のプロバイダー名の数をバックストップとします。これは意図的に、Anycastの超大手プロバイダー—Cloudflare、Google、AWS Route 53、Azure DNS—を評価します。彼らは1つのネットワーク識別子を世界中の多くの別々のルーティング経路から告知し、単一ブランドからでも本物の多様性を届けるからです。ネームサーバーが2つ未満なのはこの検査で0点、高重大度として扱われます。ドメイン全体の緩和されていない単一障害点だからです。

SOAレコード。 すべてのDNSゾーンには正確に1つのStart of Authorityレコードがあります。主ネームサーバーと管理連絡先を名指しし、変更ごとに増えるシリアル番号を運び、そして—ビジネスにとって重要な部分—4つのタイマーを保持します：

• Refresh — 二次ネームサーバーが主を変更について再確認する頻度。良い範囲：おおよそ1〜24時間（3,600〜86,400秒）。
• Retry — refreshが失敗したらどれだけ早く再試行するか。良い範囲：おおよそ5〜60分（300〜3,600秒）。
• Expire — 二次が主にまったく到達できないとき、あなたのレコードを配り続ける時間。良い範囲：おおよそ1〜4週間（604,800〜2,419,200秒）。
• Minimum TTL — 回答（『この名前は存在しない』という回答を含む）がキャッシュされる時間の下限。妥当な正の値であるべきで、300秒がよくある選択です。

『良い』状態とは：SOAが存在し、有効な管理連絡先を持ち、それらの範囲内のタイマーを運ぶこと。範囲外の値も致命的ではありませんが、変更を遅らせる（タイマーが長すぎる）か、ネームサーバーに無用な負荷をかける（短すぎる）かのどちらかです。欠けている、または本当に壊れたSOAがより深刻なケースです。

修正方法（無料・約15分）

この部分は、ドメインやDNSを管理している人向けです。あなたでない場合はこの項を渡してください。修正は無料で、当社が料金をいただくのは、それが直った状態を保ち続けているか監視する場合のみです。

ステップ1 — 多様なインフラに少なくとも2つのネームサーバーがあることを確認する。

1. 今持っているものを確認します。dig NS yourdomain.comを実行（または任意の『DNS lookup』ウェブツールを使用）してネームサーバーを読み取ります。2つ以上が最低限です。
2. 1つしかない、または両方が小さな単一ホストにある場合、初期状態で冗長性をくれるプロバイダーへDNSを移します。実質的にすべての本格的なプロバイダーがそうします：
   • Cloudflare — ドメイン追加時に、グローバルなAnycastネットワークに広がる2つのネームサーバーを自動で割り当てます。
   • AWS Route 53 — 各ホストゾーンに、別々のRoute 53ネットワークにまたがる4つのネームサーバーを与えます。
   • Google Cloud DNS / Microsoft 365 / Azure DNS — 同様に、独立したインフラにまたがる複数のネームサーバーを提供します。
3. 切り替えるには、ドメインのレジストラ（ドメインを買った場所—例：Blacknight、GoDaddy、Namecheap）で、新しいDNSプロバイダーがくれるものにネームサーバーを設定します。この変更は完全に伝播するのに24〜48時間かかることがあります。
4. 念には念をの回復力には、大規模または高リスクのビジネスは、2つ目の独立したプロバイダーからセカンダリDNSを運用できます（例：Cloudflare + Route 53、NS1 + Cloudflare）。ほとんどの小規模ビジネスにはこれは任意です—1つの評判の良いプロバイダーですでに本物のクロスネットワーク冗長性が得られます。

ステップ2 — SOAタイマーを確認し（必要なら直す）。

1. dig SOA yourdomain.comを実行し、refresh・retry・expire・minimum-TTLの値を読み取ります。
2. 上の範囲と比べます。大多数の場合、DNSプロバイダーがすでに妥当な既定を設定しており、することはありません。
3. 値が範囲外なら、DNSがホストされている場所で直します：
   • マネージドプロバイダー（Cloudflare、Route 53、Google、Azure）ではSOAは大部分任せられます。手で編集するのではなく、プロバイダーのDNS設定やサポートを通じて調整するのが一般的です。
   • 自前運用のネームサーバー（BIND、PowerDNS）では、ゾーンファイルのSOA行を直接編集し、ゾーンを再読み込みします—二次が変更を拾うよう、シリアル番号を上げるのを忘れずに。
4. 変更後、再度照会を実行して、ネームサーバーのリストとSOAタイマーの両方が正しいことを確認します。

よくある間違い

• 『2つの名前』を『2つのネットワーク』と扱う。 同じマシンやラックに解決される2つのネームサーバー名は、変装した単一障害点です。重要なのは名前の数ではなく、独立したネットワーク経路です。
• 多様性なしで、多いほど良いと思い込む。 1つの脆弱なホストにある5つのネームサーバーは、1つと同じくらい安全ではありません。多様性が量に勝ります。
• タイマーを攻めすぎる。 SOAのrefreshやminimum-TTLを『変更を即時に』と思い切り下げると、ネームサーバーを叩きつけるだけで、障害を悪化させかね、実際の利益はほとんどありません。妥当な既定がすでに速度と負荷を釣り合わせています。
• expireを低くしすぎる。 主の障害中に二次が早すぎてゾーンの配信を止めると、回復可能な不具合が全面停止になります。expireは週単位に保ちましょう。
• ゾーンを手で編集してシリアル番号を忘れる。 自前運用のネームサーバーでは、二次はSOAシリアルが増えたときだけ変更を拾います。レコードを変えてシリアルを放置すると、『修正』は決して伝播しません。
• DNSをドメインレジストラの素の既定に残す。 一部のレジストラの内蔵DNSは単一で最小限の構成です。DNSをまともなプロバイダーへ移すと、冗長性と妥当なSOAタイマーがひとつの動きで得られることが多いです。

要するに

あなたのネームサーバーとそのSOAレコードは、他のすべてが乗る土台です。本当に別々のネットワークにある2つのネームサーバーは、ひとつの障害がビジネス全体を一度にオフラインにできないことを意味し、妥当なSOAタイマーは、行う変更が実際に速やかに世界に届くことを意味します。どちらも正しくするのは無料で、どちらもまともなDNSプロバイダーに乗った瞬間にたいていすでに良い状態で、どちらも2分の確認の価値があります—それらが重要になる日は、誤っていることに最も余裕のない日だからです。

よくある質問