DNSを正しく設定する方法

08.03.2020  - 投稿者  カテゴリー: ドメイン名

DNSレコードの編集はある種の難解な知識のように扱われ、高い秘密を守っている厳選された管理者グループによって管理されているかのように扱われる場合がよくあります。また、誤った操作を1回行うとゾーンファイルが破損し、ウェブサイトがオフラインになり、メールが届かないようになることがよくあります。

しかし、実際にはDNSゾーンに神秘的な難解さはありません。誰でもDNSゾーンの編集方法とDNS設定の管理方法を学ぶことができます。

DNSを扱うことは簡単だと言っているのではありません。これまでに確認した最も一般的な間違いのいくつかをご案内し、間違いを回避するためにここにいます。

DNSレコードの構文

コンピュータサイエンスや言語のオタクであれば、おそらく ”syntax” (構文) という言葉は知っているかもしれません。そうでない場合は、 ”syntax” (構文) とはDNSの文法のようなものだと考えてください。そして、DNSは、厳格な文法しか意味をなす文章として受け入れられません。

この「正しい文法しか受け入れない」という決まりが、DNSレコードの編集において様々な問題を引き起こします。

DNSレコードの構造

DNSレコードの内容を簡単に分解してみましょう。

全てのDNSレコードは、上記の基本的な部分で構成されています。

上記画像 Name はそのDNSレコードで定義されているものです。 TTLは “Time to Live” という意味で「存続時間」という意味です。基本的にDNSサーバーがこのレコードが変更されたかどうかを確認する頻度を制御します。

その時間は秒単位です。Type はDNSレコードのタイプです。各レコードタイプには異なる役割があります。 CNAMEはエイリアスとも呼ばれ、あるドメイン名を別のドメイン名に関連付けさせることができます。 Aレコードを使用すると、ドメイン名をIPアドレスに関連付けをすることができます。 MXレコードはドメイン名をメールサーバーに関連付けします。

DNSにおける一般的な間違い

それでは、簡単な説明はこのあたりにしておいて、DNSの一般的な間違いを見てみましょう。

1.ドットが欠けている

ドメインまたはサブドメインを別のドメイン名に関連付ける場合、そのドメイン名はドットで終わる必要があり、ドットがない場合は機能しません。

相対構文と絶対構文、完全修飾と部分修飾の比較

理由は次のとおりです。DNSプロバイダまたはDNSレコードを編集するインターフェースによっては、相対構文を使用するか、絶対構文を使用する必要がある場合があります。

違いについて

ファーストネームとフルネームの関係のように考えてください。誰かを探しているときは、適切な人物を確実に探すために、姓、名、ミドルのフルネームを確認する必要があります (ドメイン名と違って名前の場合は重複があります)。

ただし、家族の中で誰かを探している場合は、姓を指定する必要はありません。名前 (ファーストネーム) だけを使用して本人を特定することができます。

DNSでも同じです。ドメインのフルネーム (姓、名、ミドルネーム) は、「完全修飾ドメイン名」 (“fully qualified domain name” 略してFQDN)と呼ばれます。つまり、完全なドメイン名をリストする必要があります。そして、これはドット( . )を含むことを覚えておくことが重要です。

なぜドット( . ) を含むのか? これは「ルートゾーン」を表していて、私たちがDNSについて話しているのであって、他のネーミングシステムではないことを示しています。上のツリーに沿って階層的にドメイン名を実際に右から左に読むことができます。 FQDNである 「news.gandi.net.」 を見てみましょう。

  • .  – これのドット ( . ) により、ドメインネームシステム(DNS)が使用されます。理論的には、ドメイン名はDNSの外にありますが、その話は以下はおいておきましょう。
  • .net – DNS内の「.net」ゾーン内にドメイン名が存在していることを示します。
  • gandi – DNSでは「.net」ゾーンの「gandi」ゾーンに存在します。
  • news – DNSシステムの「.net」ゾーンの「gandi」ゾーンの「news」ゾーンにあることを意味します。

DNSゾーンでは相対構文を使用できます。つまり「部分的に修飾された」ドメイン名を使用するだけで物事が簡単になります。したがって、gandi.netゾーン内では、「news」を部分的に修飾されたドメイン名 (partially qualified domain name) として扱うことが可能です。

ここで気をつけなければいけない点は、サブドメインを別のドメイン名に向ける場合で、通常 CNAME、ANAME、またはMXレコードの設定時に必要になります。サブドメインに完全修飾ドメイン名 (fully qualified domain name, FQDN) を指定しない場合、相対構文を使用するゾーンは、現在のゾーンのサブドメインを意味していると考えます。

したがって、news.gandi.net がドメイン名 gandi.net を指すようにする CNAME を作成したが、最後にドットを付けて gandi.net. にするのを忘れた場合、レコードは 「gandi.net.gandi.net」を指すものとして読み取られます。

2. @を使用していない

このエラーは、上記のエラーと表裏一体です。 [名前 (Name)] 列には通常、定義しようとしているサブドメインを入力します。つまり、example.com のゾーンで www を定義している場合は www、つまりこのレコードが www.example.com の場合は www を入力します。

しかし、example.comのレコードを配置したいだけで、wwwがない場合はどうでしょうか。その場合、ドメイン名を表すには記号 @ を使用します。

次に、@ではなくドメイン名自体を入力するなどエラーは他の何かを使用することで発生します。

3. MXレコードの重複

登録したドメイン名で使用する新しいメールサービスのMXレコードを追加する前に、既存のメールサービスのMXレコードを必ず削除してください。そうしないと、エラーが発生し、異なる場所を指す重複したMXレコードが設定されることになります。

このエラーは、DNSゾーンに任意の数のMXレコードをフォールバックとして機能させることができるため、最も優先度の高いメールサーバーが利用できない場合でも、送信されるメールはフォールバックに送られるようになります。

ただし、2つの異なるメールサービスを指すMXレコードがある場合、一部のメールは1つのメールサービスで取得され、一部のメールは別のメールサービスで取得されます。

このエラーは、メールが両方のメールサービスに配信されることを期待して、新しいMXレコードを追加する、というような、メールを別のメールサービスに転送したい場合にも発生します。

4. TTLの変更

これは、構文エラーよりもTTLについての誤解が原因です。

エラーはTTL (Time To Live、レコードの存続時間) に関するものであり、過去のある時点で、DNSレコードのTTLが非常に長い、または少なくとも必要以上に長く設定されているという状況にある、ということです。

ドメイン名の管理者はレコードを変更し、それを迅速に反映させる必要があります。

基本的にTTLが制御するのは、レコードがキャッシュされる期間です。インターネット上のDNSサーバーは、すべてのDNSレコードが必要になるたびに更新の有無を常にチェックしているわけではないことを覚えておいてください。DNSレコードは一定の時間キャッシュされ、その時間はTTLによって制御されます。

レコードに新しいTTLを設定すると、その新しいTTLもインターネット全体に伝播するか、そこにあるすべてのDNSサーバーに広がる必要があります。また、DNSサーバーは、現在のキャッシュが期限切れになるまで、新しいTTLをチェックしません。

これは、DNSレコードを1つのTTLで更新し、その結果、新しいレコードがより早く有効になることを期待して、TTLがはるかに短い新しいレコードで更新することを意味します。

実際にはレコードをより迅速に伝播させるためにできることは何もありません。 TTLが長い場合は待つ必要があります。

今回ご説明した間違いの原因は最も一般的なものの一部です。Gandiでドメイン名を管理するにあたって、DNSについてサポートが必要な場合は、カスタマーケアチームにお問い合わせください。