ウェブホスティング

オールインクルのDNS管理 - 最適な設定のためのヒント

オールインクルのDNSは、ドメインが指す場所、コンテンツの読み込み速度、および電子メールが確実に届くかを制御します。KASに適切なレコードを設定し、競合を回避し、以下を使用してドメインを設定する方法をお見せします。 セキュリティ そしてスピード。

中心点

KASアクセス 素早く使用し、エントリーをきれいに維持する
TTL 迅速なアップデートのために戦略的に設定する
MX/SPF/DKIM メールトラストを正しく設定する
ワイルドカード サブドメインを賢く使う
モニタリング およびドキュメンテーションの一貫性

KASにおけるオールインクルのDNS：クイックスタート

メンバーエリアにログインし、技術管理を開き、KASログインで目的のドメインに行き、次に DNS設定 [1].概要では、既存のA、AAAA、CNAME、MX、TXTレコードをチェックし、重複を取り除きます。サーバーの変更については、A（IPv4）と、必要に応じてAAAA（IPv6）を調整し、新しいIPを保存します。変更は数分で反映されることが多いが、世界的にはもっと時間がかかることもある。保存が終わるたびに、入力ミスで本番稼動ができないことがないように、もう一度エントリーをチェックします。

TTL、プロパゲーション、クリーンデプロイメント

を扱っている。 TTL をロールアウトのコントロール・レバーとして使用している。移転の前には、クライアントがすぐに新しい値を採用できるように、一時的にTTLを下げる（例えば300秒に）。変更後は、DNSの負荷を軽減するためにTTLを再び引き上げます。クリティカルな立ち上げの場合は、タイムウィンドウを計画し、古くなったレコードを削除し、複数のリゾルバの解決をテストします。賢明な値の詳細な比較はこちらをご覧ください：最適なTTL値.

ネームサーバー、NS、SOAの一覧

まずチェックする、誰は権威ネームサーバーを提供する。NSがAll-Inklに委任されている場合、私のKASエントリーは直ちに有効になります。外部のネームサーバーが保存されている場合（CDNやSaaSプロバイダーなど）、KASレコードは直ちに有効になります。ない.その後、NSが指すゾーンを管理します。ネームサーバーを変更する場合、TLDレジストラとキャッシュが遅れてデリゲーションの変更を引き継ぐ可能性があるため、個々のレコードの更新よりも時間を多めに取ります。

私はSOAレコードのパラメータに注目している： シリアル (ゾーンのバージョン番号）、 リフレッシュ/再試行/期限切れ (セカンダリ・サーバの制御）と ネガティブTTL が存在しない名前に適用されます。削除された名前や新しく作成された名前が、NXDOMAINのTTLが切れた後に初めて表示されることがあるのは、この負のキャッシュ期間によるものです。All-Inklはほとんどの値を自動的に管理しますが、ロールアウト時間にはこれらの値を含めています。

A、AAAA、CNAMEを正しく設定する

ウェブサイトでは、新しいIPv4をAの下に、IPv6をAAAAの下に入力して、すべてのクライアントが アクセス を取得します。サービスが私に1つのホスト名しか割り当てない場合、私はこのターゲットホストへのエイリアスとしてCNAMEを使用します[2]。プロバイダが特別なソリューションをサポートしていない限り、ルートドメインでのCNAMEは避けています。wwwの場合、集中IPを避けたい場合はルートにCNAMEを作成する。更新後は、HTTPSが警告なしに実行されるように、解決と証明書をチェックする。

リダイレクト、WWWの正規化、CNAMEトラップ

私はDNSとHTTPを厳密に区別している。DNSではなく、サーバー側で301/308を使ってリダイレクト（例えば非www ⇒ www）を解決する。DNSでは通常、wwwをCNAME経由でルート（またはCDNで直接ターゲット）に向ける。CNAMEと他のタイプは異なるので、すでに同じ名前の他のレコード（例えばルートのMX/TXT）があるところにCNAMEは作らない。 締め切る.クリーンな証明書の場合、使用されているすべてのホスト名（ルート、www、アプリケーション固有）が解決され、証明書に含まれていることを確認する。

サブドメインとワイルドカードを賢く使う

ショップ、ブログ、apiなどのサブドメインを作成することで、サービスをきれいに分けることができます。 メインドメイン を危険にさらすことになる。頻繁に変更されるプロジェクトでは、ワイルドカードのAレコード（*）を使えば、新しいサブドメインに自動的にアクセスできるので、時間の節約になる。とはいえ、重要なサブドメインについては、独自のターゲット、TTL、セキュリティ値を持つように明示的に定義している。外部プラットフォームについては、プロバイダーによるIPの変更が私に影響しないようにCNAMEエントリーを設定する。本番稼動前に、hostsファイルまたは別のリゾルバを使ってサブドメインをテストする。

CDN、マルチリージョン、フェイルオーバー

私はCNAME経由でCDNを統合し、ルーティングの変更がすぐに反映されるようにTTLを控えめにしている。静的コンテンツには、キャッシュポリシーと証明書を別々に管理できるように、サブドメイン（staticなど）を使う価値がある。単純なロードバランシングのために、私はいくつかのA/AAAのエントリー（ラウンドロビン）を使っています。ターゲットが失敗した場合、ユーザーはクライアントが別のターゲットを試すまで待たなければなりません。計画的なメンテナンスの場合は、短いTTLを使用してメンテナンスインスタンスに切り替えるか、CNAMEスイッチ経由でトラフィックをリダイレクトしています。

MX、SPF、DKIM、DMARC: 信頼性の高い電子メールセキュリティ

私は正しいMXレコードを設定し、メールが目的のサーバーに届くようにし、コミュニケーション・パートナーが信頼を築けるようにしています。送信者認証のために、私はTXTを使って SPF-これは、すべての正当なディスパッチパスを含む [3]。また、受信者が署名をチェックできるように、DKIMも有効にしています。DMARCを使用して、SPF/DKIMの評価と、報告を含むポリシー（none/quarantine/reject）を定義します。その後、値が正しくなるまで、配信、スパム評価、アライメントをテストします。

練習で得たSPFの詳細

私はSPFをのみ名前ごとのTXT行と、ルックアップの制限（DNSクエリで最大〜10メカニズム）に注意してください。多すぎる含む-チェーンを短くしたり、まとめたりする。
私はこうしている。 アイピーフォー/アイピーロク 自分の送信者のために、含むのような高価なメカニズムを避けることができる。 ピーティーアール.最後に私はいつもこう言う。 ~すべて (softfail)がスタートし、その後 -ぜんぶ.
長い値の場合は、正しい引用符付けに注意する。TXTはセグメントに分割されることがあり、リゾルバはそれを再びマージする。

DKIMのクリーンな運用

管理する セレクタ (例えば、s2025)をディスパッチパスごとに使用することで、ディスパッチを止めることなくキーを回転させることができる。
私は2048ビットのキーを好み、切り替え後に古いセレクタTXTレコードを削除する。
私は、テストとロールバックを別々にするために、送信者プラットフォームごとに別々のセレクタを使っている。

DMARCポリシーの策定

私は次のように始める。 p=なし とレポート（rua）の評価。SPF/DKIMのアライメント値が正しければ、以下の手順で進める。隔離にとって拒む必要に応じて増量する。 パーセント 段階的に
必要であれば sp=-サブドメインのポリシーと選択 アドキム/アスプ (リラックス／ストリクト）をセットアップに合わせる。

さらなるメール面

リバースDNS（PTR）： 自分のIPからメールを送る場合、プロバイダにHELO/SMTP名にPTRを設定しています。PTRがないと配信品質が落ちます。
MTA-STS/TLS-RPT： 私はまた、MTA-STS（TXT/HTTPSごとのポリシー）を介してトランスポート暗号化を確保し、TLS-RPTを介して配信の問題が報告されている。

エラーの原因を回避し、迅速に修正する。

IPの数字の入れ替え、レコードの重複、CNAME宛先の設定ミス、TXTの改行など、些細なことが原因であることがよくあります。そのため、私はすべての新しいエントリーをKASで直接チェックし、複数のリゾルバで検証しています。障害が発生した場合は、まずA/AAAとMXをチェックし、次にCNAME/TXTをチェックします。 TTL について。私は構造化された分析のためにチェックリストやツールを使っている。 DNSエラー分析.それでも引っかかるようなら、時間、影響を受けるホスト、サンプルを添えてチケットを発行する。

一目でわかるDNSレコード実用的な表

私は最も重要な記録タイプをコンパクトな概要にまとめ、素早く簡単に変更できるようにしている。 セーフ を使用しています。ウェブアクセスにはA/AAAA、エイリアスにはCNAME、メールにはMX、認証にはTXTを使っています。SRVはVoIPやチャットなどのサービスに役立ちます。各エントリーのフォーマット、名前、宛先、TTLに注意しています。以下の表は、エントリーを計画する際に役立ちます。

記録	目的	記入例	備考
A	ドメインのIPv4アドレス	192.0.2.123	ウェブサイトとサブドメインの場合重要
AAAA	ドメインのIPv6アドレス	2001:0db8:85a3:0000:0000:8a2e:0370:7334	可能であれば、常に追加ケアを提供する
CNAME	別ドメインへのエイリアス	www ⇒ mydomain.com	ルートでCNAMEを使用しない
MX	メールサーバーの割り当て	メールサーバー	優先順位のある複数エントリー
TXT	検証／ポリシー	v=spf1 include:...	SPF、DKIM、DMARCの保存
SRV	サービスの割り当て（VoIPなど）	_sip._tcp.mydomain.com	必要な場合のみ使用

SRV、CAA、TLSAおよび特殊ケース

ポート、重み付け、優先度を必要とするサービス（_sip._tcp、_xmpp、_autodiscoverなど）にはSRVエントリーを使用しています。サービス、プロトコル、ターゲットホスト、ポート、優先度、ウェイトを正しく設定し、依存関係を文書化しています。

証明書については、私は次のように制限している。 CAA どのCAが証明書の発行を許可されているか。私は問題 (通常の証明書）、 イシューワイルド (ワイルドカード）とオプションの ヨード 通知用。こうして不要な展示を防いでいる。DNSSECを使用する場合、TLSサービスには以下を使用できます。 TLSA (DANE） - これは高度なものだが、DNSとトランスポート暗号化の間のチェーン・セキュリティを高める。

ACME/Let's Encrypt via DNS-01

私はACMEチャレンジを通じて、トリッキーな証明書シナリオ（ワイルドカードなど）を解決している。 DNS-01.このために _acme-challenge.yourdomain.tld を使っている。エキシビジョンの間、私はTTLを短く設定し、CAがすぐに値を確認できるようにする。検証に成功したら、TTLを再び高く設定し、ゾーンをクリーンに保つために古いチャレンジ・エントリーを削除する。

キャッシングの理解とターゲットテストの実施

私は、ローカルOS、ブラウザ、プロバイダーのリゾルバ、ダウンストリーム・フォワーダーなど、いくつかのレベルでキャッシュを区別している。不明な点があれば、ローカルキャッシュを（システムツールなどで）クリアし、権威あるネームサーバーに対して特別にテストする。と掘る私はこう見る。 TTL, 権威と +トレース にある。予期せぬNXDOMAINの応答があった場合、さらなる変更を計画する前に、SOAからの負のTTLに注意する。

サブドメインの委任

必要に応じて、NSレコードを使用して、個々のサブドメインを他のネームサーバーに委譲する。内このサブドメインのゾーンの例えば、SaaSチームは app.yourdomain.tld メインゾーンを引き渡すことなく、自分自身でそのドメインで自分のネームサーバーを運用する場合は、適切なグルーレコードを考えます。

国際化ドメイン（IDN）

私はウムラウト/IDNを考慮に入れている。 ピュニコード (xn--...）。UIが変換してくれることが多いのですが、ログや手動ツールで名前と証明書が完全に一致するかどうかをチェックします。

DNSSEC、IPv6、自動化

私は、レジストラがDNSSECを提供していれば、それを有効にして、リゾルバが応答を暗号的にチェックできるようにしています。同時に アイピーブイシックス-多くのネットワークがv6を好んでいるからだ。定期的なセットアップの場合は、一貫性のあるレコードをより迅速に展開できるように、テンプレートやAPIを使用している。自分自身でリゾルバやネームサーバを運用する場合は、クリーンなグルーレコードとシリアルバージョン管理を行うようにしている：ネームサーバーの設定.このようにして、変更を理解しやすく、テストしやすく、すぐにプレーできるようにしている。

複数の環境とステージングを扱う

本番用、ステージング用、テスト用をサブドメインや別ゾーンで分けて、変更を安全にチェックできるようにしている。ステージング用には TTL新しいビルドがすぐに見えるようにするためだ。私は、ステージング、開発、プレビューなどのユニークなホスト名を予約し、ターゲットを文書化しています。切り替えるときは、CNAMEスイッチを使うか、低いTTLでA/AAAのIPを入れ替える。その後、TTLを再び引き上げ、古い値をアーカイブします。

徹底したメンテナンス：限界、フォーマット、清潔さ

TXTの長さ： 私は255文字のセグメントに注意を払い、長いキー（DKIM）を正しく引用符で囲まれた部分に分割する。
名前とポイント 私は、UIがそれを期待する場合にのみ終点を設定する。そうでなければ、相対名は不要な添付ファイルを作成します。
ミックスフォームはない： ホストにCNAMEを作成する 或いは その両方はない。
衝突を避ける： ワイルドカードは、名前が明示的に存在する場合には機能しない。そのため、私は意図的にクリティカルホストを定義している。

ドキュメンテーション、バックアップ、変更管理

変更を始める前に現在のゾーンファイルを保存し、日付、目的、チケットIDをメモしておく。各調整には短い コメント後で原因を見つけられるようにね。大きなプロジェクトでは、変更ログをレポに残し、ゾーンをエクスポートし、テストログを収集する。祝祭日やキャンペーンの前には、メンテナンスウィンドウを計画し、ロールバック戦略を準備しています。最も重要なホストを定期的にチェックすることで、不測の事態を防ぐことができます。

結論と明確なToDo

私は、少数のクリーンなレコード、適切なTTL戦略、一貫した電子メール認証に重点を置いています。その後、すべてのテストが完了するまで、解決、証明書、配信をチェックします。 グリーン です。成長のために、私はDNSSEC、IPv6、自動化でアップグレードします。私は変更を直ちに文書化し、何がいつ起こったのかを後で正確に把握できるようにしています。これにより、All-Inklのセットアップを迅速かつ信頼性の高い状態に保ち、将来のプロジェクトに備えることができます。