ヘッツナーDNS設定を正しく行う - ヘッツナーDNS設定例

ヘッツナーDNSの設定 このガイドでは、ヘッツナーDNSで必要な設定、試行錯誤された設定例、実践的なテスト方法を紹介します。このガイドでは、Hetzner DNSで必要な設定、試行錯誤を重ねた設定例、実践的なテスト方法を紹介し、早い段階でエラーを回避し、ゾーンをクリーンに保つことができるようにします。

中心点

以下の要点は、信頼性の高いDNSゾーンのために何が重要かを簡単に説明するものです。

• ネームサーバー レジストラに正しく入力する
• A/AAAA ウェブ用、 MX/TXT 郵便用
• TTL 適切に選択し、伝播を待つ
• SPF/DKIM スパム・なりすまし対策
• モニタリング 変更後のテスト

DNSの概要：本当に必要なもの

ドメインは 記録 ブラウザやメールサーバーが私のサービスを見つけられるように、特定の宛先を指定します。A Aレコード はIPv4アドレスを指し、AAAAはIPv6を指し、MXは電子メールの配信を定義する。CNAMEは別の名前を指すエイリアスを形成し、TXTは以下の情報を含む。 SPF または検証。クリーンなベースラインは、メインドメインのA/AAA、wwwのCNAME、メールのMX、SPF-TXTで構成されます。こうすることで、ゾーンをクリアに保ち、素早くメンテナンスでき、後の拡張にも対応できるようになります。

ヘッツナーDNSコンソールにドメインを追加する

DNSコンソールで、まず新しい ゾーン そしてドメインのスペルが正確に正しいことを確認する。それから 記録特定のエントリーを作成したり変更したりできるように。ヒント：私はIPアドレスとメールの宛先をあらかじめメモしておき、中断することなくすべてを入力できるようにしている。こうすることで入力ミスを防ぎ、落ち着いた順序でエントリーを設定できる。ゾーンの準備ができ次第、ネームサーバーの変更とその後のチェックを計画する。

レジストラにネームサーバーを正しく入力する。

ゾーンを作成した後 ネームサーバー ヘッツナー社のDNSコンソールで一元管理できる。通常のエントリーは ns1.first-ns.de, robotns2.second-ns.de そして robotns3.second-ns.com..deや.atドメインの場合、私は自分のネームサーバーを グルーレコードで、参照とIPが保存されるようにします。この作業を行ったことがない場合は、ガイドの各ステップを参照してください。 グルー記録の設定.アップデートは世界中で異なるスピードで到着する可能性があるため、私はその後、切り替えに時間がかかる。

設定例：ウェブサイトと電子メールを実行可能にする

典型的なウェブプレゼンスには Aレコード ルートドメイン用のCNAME、www用のCNAME、および適切なメールレコード。SPF-TXTは、外部サーバーがドメイン名でメールを送信するのを防ぎます。オプションとして、ウェブサーバーが以下のような場合、AAAAレコードを追加します。 アイピーブイシックス を提供しています。ForwardMXのような外部のメールサービスについては、MXをカスタマイズしてその仕様を保存しています。次の表は、多くのセットアップの確かな出発点を示しています。

名称	タイプ	価値	ヒント
@	A	195.201.210.43	ウェブサーバー IPv4
@	AAAA	オプション：2a01:4f8:xxxx:xxxx::1	ウェブサーバー IPv6
www	CNAME	@	ルート上のエイリアス
@	MX	mx1.forwardmx.net	プリオ10
@	TXT	"v=spf1 include:_spf.forwardmx.net -all"	なりすましに対するSPF

DNSSECの有効化とDSレコードの設定

操作の安全性が私にとって重要であるなら、私はそれを有効にする。 ディナセック ゾーンのための署名鍵を生成する。ヘッツナーのコンソールで、このための署名キーを生成し、必要な DSデータこれをレジストラに預ける。アルゴリズムとダイジェストが正しく転送されたことを確認する。その後、レジストラからゾーンへのチェーンが正しく検証されるまで 待つ。主要な鍵ローテーションの前に、私はTTLを下げ、リゾルバが新しい署名を 適切なタイミングで見ることができるように時間的余裕を計画する。重要: 変更中にエラーが発生した場合、受信者のバリデーションは失敗する。

TTLを正しく設定し、伝搬を理解する

仝 TTL は、リゾルバがエントリーをキャッシュする時間を決定する。変換の場合は、短い TTL (例えば300秒）。最終的なセットアップの後、リクエストを節約し、一貫した解像度を達成するために、私は再び値を増やします。頻繁にデプロイする人は600-1200秒にこだわり、めったに変更を加えない人は3600-14400秒を使う。 この決定に関する実用的な概要は、私が行った 最適なTTL選択.

エイペックス・ドメイン、CAA、証明書を管理

のSaaSターゲットの場合 ゾーン・エイペックス 私はそれを覚えている。 CNAME は許可されていません。そのため、プロバイダーのA/AAAAを使用するか、ウェブサーバー・レベルでwwwへのリダイレクトを設定しています。証明書の割り当てについては CAAレコードどのCAが証明書を発行する権限を持つか。例えば、私は実際に使用するCAだけを管理し、オプションで報告用のメールアドレスを追加している。CAを変更した場合は、発行前にTTLを簡単に増やし、CAAを更新する。ACME DNS-01経由のワイルドカードについては、以下のTXTレコードを確認しています。 アクメ・チャレンジ を素早く設定し、古い課題を残さないように自動的にクリーンアップすることができる。

サブドメインとサービスをきれいに作成する

各サブドメインに適切な A- または CNAMEサブドメインがIPを直接指すか、名前を指すかに応じて、-recordを指定する。例：blog.example.deはブログVMへのAレコードとして、cdn.example.deはCDN名へのCNAMEとして。APIについては、リスクを避けるため、内部名と公開名を厳密に区別している。api、app、imgといった標準化された名前は、メンテナンスとモニタリングに役立ちます。こうすることで、ゾーンを構造化し、変更を明確に割り当てることができます。

ワイルドカード、SRV、特殊レコードタイプ

私はこうしている。 ワイルドカード・レコード (*.example.de)、例えばマルチクライアント対応セットアップの場合。ワイルドカードよりも正確なエントリーが常に優先されるようにしています。SIP、Matrix、Autodiscoverのようなサービスの場合は、次のように作成します。 SRVレコード そして、フォーマットと優先順位をチェックする。 TXTレコード 長い内容のもの（たとえば2048ビットのDKIM）は、パーサが正しくマージできるように、いくつかの引用セグメントに分割される。ルックアップの制限を破らないように、複数のSPFレコードを避け、エントリーを有効なSPFにまとめる。

信頼性の高い電子メール配信SPF、DKIM、DMARC

信頼できる電子メールには MX 私の送信システムをカバーするクリーンなSPF-TXT。また ディーケーアイエム でDKIMセレクタをTXTとしてselector._domainkeyの下に公開します。私はDMARCを使って、SPF/DKIMを通らないメールを受信者がどう扱うかを定義しています。私はよく "p=none "から始めて、レポートを評価し、後で "quarantine "か "reject "に切り替えます。この順序でリスクを減らし、配信品質を徐々に高めていきます。

SPF/DKIM/DMARCの実践を深める

SPFは必要なものだけにしている。 含む-また、ホスト名1つにつきSPFを1つ以上使用することはない。DNSルックアップの10回制限を遵守するために、チェーンを減らすか、安定していればIP4/IP6メカニズムを使う。以下はその例である。 DKIMローテーション 私は2つのアクティブなセレクタ（新旧）を操作し、新しいキーを公開し、メールサービスを切り替え、数日後に古い方だけを削除する。と ＤＭＡＲＣ 私は最初に報告アドレス（rua/ruf）を設定し、アライメント（aspf/adkim）をチェックします。サブドメインには sp= 別々に送信する場合は、別のポリシーを定義する。こうすることで、思い込みではなく、実際のトラフィックデータに対応することができる。

クリーンなメール配信のためのリバースDNS（PTR）

MX、SPF、DKIMに加えて、私は次のように設定しました。 リバースDNS (PTR)を使用する。IPのPTRはホスト名を指し、そのホスト名はA/AAを介して同じIPに正しく解決される(フォワード／リバース・マッチ).私は、ドメインのゾーン管理ではなく、IP所有者と直接IPごとにPTRを設定します。IPv6にはニブルフォーマットを使用しています。適切なPTRはスパム分類を減らし、レピュテーションに役立ちます。メールが外部サービスを経由する場合、私はそのPTRをそのままにしておき、SPFをカスタマイズせずに送信元が混在しないようにします。

典型的なエラーと迅速な解決策

ドメインが解決しない場合、私は最初に次のことを確認する。 TTLネームサーバーのエントリーとレコードの正しいスペル。2つ目は 伝播リゾルバによっては、特にTTLが増加した後に、より長くキャッシュするものもある。私は、地域差を認識するために、さまざまなDNSチェッカーを使って解像度を比較します。ローカルで問題が発生した場合は、一時的に1.1.1.1や8.8.8.8などのパブリックリゾルバに切り替えます。エラーが内部ネットワークでのみ発生する場合は、内部リゾルバとコンテナ、Kubernetes、CoreDNS設定のルールをチェックする。

テスト方法：dig、nslookup、end-to-end

レコードだけをテストするのではなく、パス全体をテストするんだ：

• 掘る A/AAA/CNAME/MX/TXT：レスポンス、TTL、権限のチェック
• ディグ＋トレースデリゲーションチェーンとネームサーバーの動作を参照
• SMTPテストHELO/EHLO、TLS、バナーのチェック
• HTTPS リアル証明書チェーン、ホスト名、リダイレクト

この方法で、不正なバーチャルホストのマッピングや期限切れの証明書など、純粋なDNSレスポンスでは見えないエラーも認識します。変更を加えた後、最終的な結論を出す前に少なくとも1回のTTLを待ちます。

ヘッツナーのコンソールで効率的に作業

関連するものをまとめる エントリー 時間をかけ、大きな変更を加える前に短いTTLを設定し、すべてを一度に公開する。保存する前に、もう一度チェックする MX-優先順位、SPF構文、AレコードのターゲットIP。サーバーの管理および処理については、以下のコンパクトな説明書を参照されたい。 ヘッツナー・ロボットのヒント.デプロイ後は、http、https、メールをpingだけでなく、実際のリクエストでテストしています。これにより、純粋なDNSクエリでは表示されないエラーを認識することができます。

自動化：API、テンプレート、ACME

私は自動化によって時間を節約している。通常のデプロイには API DNSコンソールのレコードを作成、変更、または削除します。私は、繰り返されるパターン（例：Web + Mail + DMARC）のテンプレートを使用して作業し、プロジェクト固有の値のみを挿入します。Let's Encrypt DNS-01については、自動TXTレコードライターを組み込み、更新ワークフローに統合しています。重要：私はAPIトークンをパスワードのように扱い、特定のプロジェクトに割り当て、不要になったらアクセスを取り消します。

高度なセットアップ：スプリット・ホライゾン、CDN、ACME

必要に応じて内部ユーザーと外部ユーザーを分ける DNS-内部アプリがプライベートIPを指し、ビジターがパブリック宛先を指すように。この場合 シーディーエヌサブドメインをCNAME経由でCDN名に参照し、そこでTLSを有効にしている。ACME/Let's Encrypt経由の自動証明書については、HTTP-01が一致しない場合、オプションでTXT経由でDNS-01チャレンジを設定している。更新が適切なタイミングで行われるように、ここでは自動化が重要だ。ログと通知は、失敗を適時に認識するのに役立つ。

パフォーマンスと可用性のパターン

私は単純な手段で稼働率を高めている：いくつかの A/AAAの記録 (ラウンドロビン)バックエンドがステートレスかセッションを共有していれば、追加サービスなしで負荷を共有できる。メンテナンスの際には、一時的に個々のIPを削除し、再度エントリーを立ち上げます。短すぎるTTLの実行はリゾルバに負担をかける可能性があるため、私は応答速度とキャッシュヒット率のバランスを見つける。私は、ヘルスチェックなしでフェイルオーバーするためのクリアプロセスを設定している：障害が発生した場合、私はエントリーを入れ替え、積極的に監視し、復旧後に再びリセットする。

安全性とゾーン衛生

不要なものは使わない ゾーン移動 (AXFR）のみを公開する。 NS真に権威のあるもの私は、古いサブドメインや孤児となったサブドメインを定期的に削除し、シャドウ・サーフェスを作らないようにしている。IDNについては ピュニコード-スペルミスや特殊文字のミスを避ける。コンソールの役割ベースのアクセスは、適切な人だけがゾーンを変更できるようにします。また、非常に実際的なことですが、私はチームツールで変更を簡単に文書化しています。

移行とロールバック戦略

引っ越しの前にTTLを下げ（24～48時間前）、ミラーリングを行う。 記録 を新しいゾーンに追加し、新しいネームサーバーを経由して直接解決をテストします。すべてが正しい場合にのみ ネームサーバー レジストラで。委任後、私はトラフィックとエラーを監視する。何か問題が発生したら、管理された方法でロールバックするか、個々のエントリを修正します。私はDNSSECの移行を特に保守的に計画し、新しい署名チェーンが安全に配置されるまで古い署名チェーンをそのままにしておきます。最後に、TTLを本番準拠の値にリセットします。

パフォーマンスと柔軟性に関するプロバイダーの簡単な比較

性能、機能 DNSの自由 プロジェクトをどれだけ柔軟に展開できるかを決める。実際のところ、大手ホスティング会社は 応答時間が、操作、機能、サポートの点で異なる。私は、性能、機能の範囲、ヘルプの質、DNSのオプションによって選択を評価する。以下の概要は、私が決断を下すために使える凝縮されたイメージを示している。最終的に重要なのは、私のプロジェクトが本当に必要としているものであり、最大の機能リストではない。

プロバイダ	パフォーマンス	機能の範囲	サポート	DNSの柔軟性	ランキング
webhoster.de	高い	非常に広範囲	トップ	最大	1
ヘッツナー	高い	広範囲	グッド	高い	2
コンタボ	ミディアム	スタンダード	O.K.	ミディアム	3

簡単にまとめると

を設定した。 ヘッツナーDNS-ゾーンを構造化する：ゾーンを作成し、ネームサーバーをレジストラに登録し、ウェブとメールのコアレコードを設定し、テストする。適切な TTL 切り替え時間を短くし、完了後に再び長くすることで負荷を軽減している。SPF、DKIM、DMARCは配信を強化し、悪用からドメインを守る。サブドメインは一貫性を保ち、内部宛先と公開宛先を分けています。このサンプル設定と日常的なチェックにより、ヘッツナーDNS設定は信頼性が高く、高速で保守が簡単です。