DNSはどう動く?
Domain Name System(DNS)はインターネットの電話帳です。ブラウザがtools.kernelhost.comを開くと、まずドメインがIPアドレスに翻訳されます。DNSは単一のサーバーではなく階層チェーンです: ルートサーバー(.)、TLDサーバー(.com、.de、.at)、最終的にそのドメインのauthoritativeネームサーバー。リゾルバーがこのチェーンを辿り、結果をローカルにキャッシュします。
DNSクエリは質問と回答からなります: ドメインYに対してタイプXのレコードはあるか? 回答は1つ以上のレコードに加えてTTL(time to live)を含み、リゾルバーがどれだけの間キャッシュできるかを示します。したがってDNSの変更は世界中で即座に見えるわけではなく、キャッシュ階層に沿って伝播します。
本ツールはFrankfurt FRA01のコンテナのシステムリゾルバー経由でUDP/TCPルックアップを実行します。トラッキング、問い合わせドメインのロギング、サードパーティAPIはありません。FrankfurtノードはDE-CIXに直結しているため、応答は通常数ミリ秒で返ります。
どんなレコードタイプがある?
DNSレコードタイプにはそれぞれ役割があります。本ツールはドメイン運用に実際に必要な最も一般的な8タイプを表示します。
- A: ドメインをIPv4アドレスにマップします。1つのドメインに複数のAレコード(ラウンドロビンDNS、ロードバランシング)を持てます。
- AAAA: ドメインをIPv6アドレスにマップします。現代のWeb構成には必須で、GoogleはIPv6接続性をプラスに評価します。
- MX: メールエクスチェンジャー。このドメイン宛のメールを受信するサーバーを示します。フェイルオーバー用に優先度(数値が小さいほど優先)を持ちます。
- TXT: 自由形式テキスト。実務ではほぼSPF、DKIM、DMARC、ドメイン検証(Google、Microsoft)、_acme-challenge(Let's Encrypt)に使われます。
- CNAME: 別ドメインへのエイリアス。www.kernelhost.comをkernelhost.comへのCNAMEにできます。apexドメイン自体ではCNAMEは許可されません。
- NS: このドメインに対してauthoritativeなネームサーバーです。NSレコードはドメイン登録時に設定され、他のレコードがどこで管理されるかを定めます。
- SOA: Start Of Authority。プライマリネームサーバー、管理者メール、ゾーン転送のrefresh/retry/expire/minimum TTLを定義します。
- CAA: Certificate Authority Authorization。このドメインのTLS証明書を発行できるCAを指定します。許可されない発行に対する保護です。
MX 対 SPF 対 DKIM 対 DMARC: メール構成の解説
完全なメール構成は4つのDNSコンポーネントからなります。1つでも欠けるとメールは届かないかスパムフォルダ行きです。
- MX(受信): あなたのドメイン宛のメールを受信するサーバーを世界に伝えます。MXがなければ誰もあなたに書けません。MXは通常mx.kernelhost.comのようなホスト名を指し、A/AAAAで解決されます。
- SPF(送信認証): v=spf1のTXTレコードで、あなたのドメインを正当に名乗って送信できるIPを指定します。末尾の-allは必須です(さもないと誰でもなりすませます)。
- DKIM(暗号署名): 送信メールはすべて秘密鍵で署名され、公開鍵はDNSのselector._domainkey.your-domain.comにv=DKIM1のTXTで置かれます。受信側は署名を検証して改ざんを検出します。
- DMARC(ポリシー + レポーティング): _dmarc.your-domain.com のTXTでv=DMARC1; p=reject; rua=mailto:dmarc@... を指定。DMARCはSPFとDKIMを組み合わせ、失敗時の処理を受信側に伝え、レポートも提供します。
本ツールはSPF、DKIM、DMARCをインラインで解析し、緑/黄/赤のバッジで構成が綺麗かを即座に表示します。例えば-all欠落、DKIM鍵が短い、DMARCがモニタリングモードのみ、などです。
TTLとDNSキャッシュ
TTL(time to live)はリゾルバーがDNSレコードをキャッシュできる秒数です。TTL=3600なら1時間後にしかauthoritativeサーバーへ再問い合わせしません。帯域を節約しますが、DNS変更は即座には見えません。
適切なTTLは目的次第です。安定本番運用なら高いTTL(1時間から1日)。サーバー移行を控えているなら数日前にTTLを60から300秒へ下げ、移行後に戻します。
- 短いTTL(60から300秒): 変更が早く反映されますが、authoritativeサーバーの負荷が増え、ルックアップ遅延がやや高くなります。
- 長いTTL(3600から86400秒): 負荷が下がりキャッシュ応答が速くなりますが、変更が世界中に見えるまで数時間から数日かかります。
- 移行時: 移行の少なくとも24時間前にTTLを60から300秒へ下げ、すべてのリゾルバーキャッシュがカットオーバー直前に切れるようにします。
DNSSECとは、必要か?
DNSSEC(DNS Security Extensions)はDNSレコードを暗号署名し、リゾルバーが応答が途中で改ざんされていないかを検証できるようにします。DNSSECがないと、悪意のあるISPや公衆Wi-Fiリゾルバーが偽のIPを返す可能性があります(DNS spoofing)。
DNSSECは2つの鍵を使います: ZSK(zone signing key)がレコードを署名し、KSK(key signing key)がZSKを署名します。KSKハッシュはレジストラでDSレコードとして公開され、信頼の連鎖をルートまで閉じます。
必要かどうか? 銀行、公共サービス、メールプロバイダー、SMIMEA、TLSA、OPENPGPKEYレコード(DANE)を使う人にはイエスです。普通のWebshopならDNSSECはあると嬉しい程度で、プロバイダーが対応していれば追加コストはありません。KernelHost DNSはDNSSECに最初から対応しています。
KernelHostのDNS
KernelHost Webhostingにはマネージドな完全DNSが含まれます: すべてのレコードはコントロールパネルで管理し、DNSSECはデフォルトで有効、FrankfurtとWienに地理冗長なanycastネームサーバーを配置し、世界中で速い応答を提供します。
Webspace不要でDNSホスティングだけが必要なら、ドメインサービスプランで対応できます。ドメイン登録、移管、DNS管理はすべてのKernelHostホスティングプランに含まれます。複雑な構成(split horizon、GeoDNS、高TTL精度)にはVPS + 自前のauthoritativeサーバーが選択肢で、本ツールはいつでも診断に使えます。