DNSレコードアナライザー
DNS(Domain Name System)レコードはドメイン名をIPアドレスにマッピングし、メールルーティングを設定します。このツールはdigまたはBINDのゾーンファイル出力を解析し、メール認証レコード(SPF、DMARC、DKIM、BIMI)を分析し、一般的な設定ミスについて警告します。
仕様
よくあるユースケース
- トラブルシューティングのためのdigまたはhostコマンド出力の分析
- 移行前のドメインDNS設定の監査
- メール認証設定の検証(SPF、DMARC、DKIM)
- メール配信性の問題のデバッグ
- コンプライアンスのためのドメインDNSレコードの文書化
- SSL証明書リクエスト前のCAAレコードの確認
機能
- BIND/digゾーンファイル出力の解析
- A、AAAA、NS、MX、TXT、CNAME、SOA、SRV、CAA、TLSAレコードの表示
- 人間が読めるTTLフォーマット(5m、2h、1d)
- SPFレコードの自動検出とメカニズム説明付き分析
- DMARCポリシーとレポート設定の分析
- DKIMレコード分析(鍵タイプ、セレクタ、有効性、テストモード)
- BIMIレコード分析(VMCの有無、有効性)
- DNSSECサポート(DNSKEY、DS、RRSIGレコードの有効期限付き)
- TLSA/DANE証明書ピニングの表示
- SPF DNSルックアップ数の検証(RFC 7208により最大10)
- メール認証の設定ミスに関する警告
例
ゾーンファイル出力
試してみる →各種レコードタイプを表示するdigの出力。
example.com. 300 IN A 192.0.2.1
example.com. 172800 IN NS ns1.example.com.
example.com. 172800 IN NS ns2.example.com.
example.com. 300 IN MX 10 mail.example.com.
example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"SPFレコード
試してみる →GoogleとMailgunにメール送信を許可するSPFレコード。
v=spf1 include:_spf.google.com include:mailgun.org ip4:192.168.1.0/24 ~allDMARCレコード
試してみる →集計レポートとフォレンジックレポート付きの厳格なDMARCポリシー。
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s; pct=100ヒント
- すべてのレコードを取得: dig example.com ANY +noall +answer
- SPFは最大10回のDNSルックアップが許可されています。「include」は控えめに使用してください。
- DMARC p=rejectが最も強力ですが、まずp=noneとruaレポートから始めてください。
- CAAレコードはドメインの証明書を発行できるCAを制限します。
- TLSAレコードは証明書検証のためのDANEを有効にします。
解説 DNSレコードアナライザー
DNS(Domain Name System)はインターネットのディレクトリサービスであり、人間が読めるドメイン名をIPアドレスに変換し、その他の重要なマッピングを提供します。DNSレコードは権威ネームサーバーのゾーンファイルに保存され、それぞれ名前、タイプ、クラス、TTL(Time to Live)、および型固有のデータを持ちます。
最も基本的なレコードタイプは名前解決を処理します。AレコードはドメインをIPv4アドレスにマッピングし、AAAAレコードはIPv6にマッピングします。CNAMEレコードは1つの名前を別の名前に指すエイリアスを作成します。NSレコードはサブドメインを特定のネームサーバーに委任します。MXレコードは優先度値付きでメールサーバーにメールを転送します。SOAレコードはプライマリネームサーバーとシリアル番号を含むゾーンメタデータを含みます。
TXTレコードはメール認証データを運びます。SPFレコード(v=spf1 ...)は承認されたメール送信者を指定します。DMARCレコード(v=DMARC1; ...)はSPF/DKIM失敗時の処理方法を受信者に通知します。DKIMレコードはメール署名検証用の公開鍵を保存します。メール認証の設定ミスは配信性の問題の主要な原因です。
TTL値はリゾルバがレスポンスをキャッシュする時間を制御します。高いTTL(86400秒 = 1日)はDNSトラフィックを減少させますが、変更の伝播が遅くなります。低いTTL(300秒 = 5分)は迅速な更新を可能にしますが、クエリ量が増加します。移行前にはTTLを事前に下げて、古い値が速く期限切れになるようにしてください。
DNSは「伝播」という用語が示すような方法で実際に伝播するわけではありません。レコードが変更されると、リゾルバはTTLが期限切れになるまでキャッシュされた古い値を提供し続け、その後権威サーバーから新しい値を取得します。TTLが86400(24時間)だった場合、変更がすべての場所で見えるようになるまで最大24時間かかる可能性があります。変更を速めるには、事前にTTLを下げ(例えば、移行の48時間前に300秒に)、更新を行い、その後再びTTLを上げてください。
AレコードはドメインをIPv4アドレスに直接マッピングしますが、CNAMEは別のドメイン名を指すエイリアスを作成します。リゾルバはチェーンをたどって最終的なAレコードに到達します。CNAMEはゾーンの頂点(example.comのようなネイキッドドメイン)では使用できません。頂点にはSOAおよびNSレコードが必要なため競合が発生します。一部のDNSプロバイダーはこの制限を回避するために独自のALIASまたはANAMEレコードタイプを提供しています。
メール認証の設定には3つのDNSレコードが必要です。SPFについては、"v=spf1"に続いて承認された送信者を含むTXTレコードを追加します。DKIMについては、メールサービスが提供する公開鍵を含むTXTレコードをセレクタサブドメインに追加します。DMARCについては、ポリシー(none、quarantine、またはreject)とレポートアドレスを指定するTXTレコードを_dmarc.yourdomain.comに追加します。p=noneから始めると、強制する前にアライメントを監視できます。SPFの失敗は一般的に、10回のDNSルックアップ制限の超過、送信サービスの承認忘れ、すべての送信者が確認される前の-all(ハードフェイル)の使用、同じドメインに複数のSPFレコードがあることが原因です。v=spf1レコードは1つだけ許可され、複数のレコードは永続的なエラーを引き起こします。