Google Workspaceで使用するDNSレコードを解説

記事タイトルとURLをコピーする

G-gen の荒井です。Google Workspace では、初期設定の際にいくつかの DNS レコードの登録が必要です。本記事では Google Workspace で使用する DNS レコードについて解説します。

前提知識

DNS

DNS はドメインネームシステム(Domain Name System)の略称であり、組織(企業や官公庁、個人など)が保有するドメイン(後述)に関する電話帳のようなものです。

ドメインがどのサーバーで運用されているかを判別し、ユーザーからのリクエストを正しいサーバーに誘導する仕組みです。

DNS は通常、組織ごとに保有されています。また多くの組織が、お名前ドットコムなどのドメイン登録事業者や、Google などのインターネット関連事業者から貸し出される DNS を利用しています。

ドメイン

ドメインとは、インターネット上の住所のようなものです。

インターネットには無数のサーバーが接続されており、Web サーバーやメールサーバーが運用されています。ネットワークに接続されたサーバーは IP アドレス(例 : 172.217.26.227)という正規の住所を保有します。しかしこうした数字の羅列は人間が理解したり、覚えたりしづらいため、IP アドレスに文字列(名前)を付与して管理しています。この名称がドメイン(ドメイン名)です。

ドメインは、Web サイトの URL やメールアドレスの一部として使用されます。例えば、g-gen.co.jpgoogle.com はドメイン名です。

ゾーン

ゾーンとは、DNS が持つ、ドメインと IP アドレスの対応表です。

1つのドメインごとに少なくとも1つのゾーンが用意されます。ゾーンにレコード(後述)を記載することで、DNS を管理します。

レコード

レコードとは、ゾーンに記載された1行1行の設定を指します。

レコードにはタイプ(種類)があり、用途や目的が異なります。タイプには以下のようなものがあります。

タイプ名 説明
A レコード ドメイン名(ホスト名)と IP アドレスの対応を記述するためのレコードタイプ
TXT レコード テキスト情報を持たせるためのレコードタイプ
MX レコード メールサーバーを示すためのレコードタイプ

名前解決

名前解決とは、ドメイン名から IP アドレスに変換する作業を指します。

例えば、Web ブラウザで www.google.co.jp という URL にアクセスすると、ブラウザは www.google.co.jp に対応する A レコードを DNS に問い合わせます。DNS は対応する A レコードから IP アドレスを返答します。これにより、ブラウザは Google の Web サイトにアクセスすることができます。

この「ドメイン名を DNS に問い合わせて、IP アドレスを得る」というプロセスが、名前解決です。

TTL

TTL とは、DNS に問い合わせる側が、そのレコードの返答を何秒間キャッシュに保持してよいかを示す値です。レコードごとに設定します。TTL は「Time To Live」の略称です。

レコードを変更したとしても、TTL の秒数が経過するまでは、DNS 利用者は新たに名前解決を行わず、キャッシュに保存されたレコードを使用するため、設定変更が反映されません。

TTL の単位は ですので、「TTL=3600」は1時間を示します。

Google Workspace で使用するレコード

概要

ここからは、Google Workspace の初期設定時や運用時によく利用される DNS レコードを紹介します。

TXT レコード

TXT レコードとは、ドメインに関する文字列情報が記載されたレコードです。

Google Workspace では初期セットアップの際にドメインの所有権確認として使用します。 またメールの信頼性を高めるため、SPF、DKIM、DMARK(後述)などの設定を行う際も TXT レコードを使用します。

TXT レコードに関する詳細な説明や記述方法については、以下のリンクを参照してください。

CNAME レコード

CNAME レコードとは、ドメイン名の正規の名称と、エイリアス名(別名)を紐づけるためのレコードです。Web サーバーなどにはエイリアス名(別名)を付与することができますが、CNAME レコードは、その別名への問い合わせを、正規名に紐づけるためのレコードです。

Google Workspace では、初期セットアップ時のドメイン所有権確認の際に TXT レコードが利用できない場合に使用したり、Google サイトの URL をカスタマイズする際に使用します。

また特殊な使い方として、管理コンソールにアクセスするパスワードを忘れてしまった場合にも、CNAMEレコードを使用することで再設定を行うことが可能です。

CNAME レコードに関する詳細な説明や記述方法については、以下のリンクを参照してください。

MXレコード

MX レコードとは、ドメインに送られたメールを、指定したメールサーバーへ転送する役割を担うレコードです。MX は、「Mail Exchanger」の略です。

Google Workspace を使わない場合でも、新しいドメイン名でメールを送受信するためには必ず設定します。運用中の MX レコードを変更すると、メールが受信できなくなってしまう可能性もあるため、設定変更の際には注意が必要です。

Google Workspace では、Gmail でメールを送受信できるようにするために、必ず設定が必要です。

MX レコードに関する詳細な説明や記述方法については、以下のリンクを参照してください。

A レコード

A レコードとは、ドメイン名やホスト名と、IP アドレスを対応させるためのレコードです。

「名前解決」の項でも記載した例を再掲します。例えば、Web ブラウザで www.google.co.jp という URL にアクセスすると、ブラウザは www.google.co.jp に対応する A レコードを DNS に問い合わせます。DNS は対応する A レコードから IP アドレスを返答します。これにより、ブラウザは Google の Web サイトにアクセスすることができます。

Google Workspace では、Google サイトで作成したサイトの URL を、カスタムドメインに変更する際に使用します。

A レコードに関する詳細な説明や記述方法については、以下のリンクを参照してください。

DNS の詳細

ここまで、DNS に関する基礎知識を解説しました。より詳細な説明は、以下のリンクを参照してください。

メールセキュリティに関するレコード

概要

組織がメールを使用する際は、受信者のメールボックスに確実にメールが配信されるよう、メールセキュリティに関する DNS レコードを適切に設定する必要があります。

Google Workspace では適切に DNS レコードを設定することで、以下の効果が期待できます。

  • 自組織から送信されたメールが、受信者の迷惑メールボックスに分類されることを防ぐ
  • 第三者が自組織のドメインを偽装して「なりすましメール」や「フィッシングメール」を送信した場合に、受信者が偽装に気がつくようになる(迷惑メールに分類されたり、ブロックされるようになる)

これから記載するメールセキュリティに関する DNS レコードは、Gmail の利用開始にあたっては必須ではありません。しかし、相手方にメールが確実に配信されるよう、適切に設定することが強く推奨されます。

SPF レコード

SPF とは、送信メールのドメイン(メールアドレス)が詐称されていないことを確認するための技術です。

SPF に対応したメールサーバーでは、メール受信時に SPF レコード(実体は、メール送信者のドメインに設定された TXT レコード)の内容を確認し、正規のサーバーからメールが送信されているかどうかを確認します。正規サーバーからの送信ではない場合、受信メールサーバーの仕様に従い、迷惑メールに分類したり、受信拒否するなどの処理を行います。

Google Workspace では、確実にメールが送信できるよう、SPF を設定することを強く推奨しています。

SPF レコードに関する詳細な説明や記述方法については、以下のリンクを参照してください。

DKIM レコード

DKIM とは、送信メールのドメイン認証技術です。DKIM が送信者側で適切に設定されていると、メール送信時に送信メールサーバーが電子署名を行い、受信者がそれを検証することでメールの改ざん(なりすまし等)を検知することができます。送信者側の DNS に DKIM レコード(実体は TXT レコード)を追加することで設定できます。

Google Workspace では、SPF と同様に、DKIM も設定することが強く推奨されています。

DKIM に関する詳細な説明や記述方法については、以下のリンクを参照してください。

DMARC レコード

DMARC とは、SPF や DKIM と同じく、送信メールのドメイン認証技術です。DMARC レコード(実体は TXT レコード)を設定することで、SPF と DKIM の認証が失敗した際の当該メールの処理方法を、送信者側から受信メールサーバーに指示することが出来ます。

SPF と DKIM では、受信メールの正当性検証に失敗したメールをどのように処理するか(廃棄するのか、迷惑メールに分類するのか、あるいはそのまま受信するか)は、受信メールサーバー側の設定に従います。そのため、メール送信者は、そのようなメールの処理方法を指示することもできませんし、処理の結果を把握することも、そのように処理された理由も把握できません。

それに対して DMARC では、認証失敗時に受信メールサーバーが当該メールに対してどういった処理を行わせるかを、送信者側の DNS にポリシー定義することが可能です。また DMARC では、受信メールサーバーからレポートを取得することが可能なため、メール配信が失敗する原因を把握することも可能です。

DMARC レコードに関する詳細な説明や記述方法については、以下のリンクを参照してください。

blog.g-gen.co.jp

荒井 雄基 (記事一覧)

クラウドソリューション部

オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。
Google Cloud 認定資格 7冠
現在は Google Workspace を中心に企業の DX 推進をサポート。
最近頑張っていることは、子どもがハマっている戦隊モノの踊りを踊れるようになること。