DNSの用語、コンポーネント、および概念の概要

序章

DNS、またはドメインネームシステムは、多くの場合、Webサイトとサーバーの構成方法を学ぶ上で非常に難しい部分です。 DNSがどのように機能するかを理解することは、Webサイトへのアクセスの構成に関する問題を診断するのに役立ち、舞台裏で何が起こっているのかについての理解を広げることができます。

このガイドでは、DNS構成を実行するのに役立ついくつかの基本的なDNSの概念について説明します。このガイドに取り組んだ後、DigitalOceanでドメイン名を設定するか独自のDNSサーバーを設定する準備ができているはずです。

ドメインを解決するための独自のサーバーのセットアップまたはコントロールパネルでのドメインのセットアップに進む前に、これらすべてが実際にどのように機能するかについて、いくつかの基本的な概念を確認しましょう。

ドメイン用語

用語を定義することから始めるべきです。これらのトピックのいくつかは他のコンテキストではおなじみですが、ドメイン名やDNSについて話すときに使用される多くの用語があり、コンピューティングの他の領域ではあまり使用されていません。

簡単に始めましょう：

ドメインネームシステム

ドメインネームシステム（より一般的には「DNS」として知られています）は、人間にわかりやすい名前を一意のIPアドレスに解決できるようにするネットワークシステムです。

ドメイン名

ドメイン名は、インターネットリソースに関連付けるために使用される人間にわかりやすい名前です。たとえば、「google.com」はドメイン名です。「グーグル」の部分はドメインだと言う人もいますが、一般的には結合された形式をドメイン名と呼ぶことができます。

URL「google.com」は、GoogleIncが所有するサーバーに関連付けられています。ドメインネームシステムを使用すると、ブラウザに「google.com」と入力すると、Googleサーバーにアクセスできます。

IPアドレス

IPアドレスは、ネットワークアドレス可能ロケーションと呼ばれるものです。各IPアドレスは、ネットワーク内で一意である必要があります。私たちがウェブサイトについて話しているとき、このネットワークはインターネット全体です。

最も一般的な形式のアドレスであるIPv4は、4セットの数字として記述され、各セットは最大3桁で、各セットはドットで区切られています。たとえば、「111.222.111.222」は有効なIPv4IPアドレスである可能性があります。 DNSを使用すると、名前をそのアドレスにマップするため、ネットワーク上でアクセスしたい場所ごとに複雑な番号のセットを覚えておく必要がありません。

トップレベルドメイン

トップレベルドメイン（TLD）は、ドメインの最も一般的な部分です。トップレベルドメインは、（ドットで区切られた）右端の部分です。一般的なトップレベルドメインは、「com」、「net」、「org」、「gov」、「edu」、および「io」です。

トップレベルドメインは、ドメイン名の観点から階層の最上位にあります。特定の関係者は、ICANN（Internet Corporation for Assigned Names and Numbers）によってトップレベルドメインの管理制御を与えられています。これらの当事者は、通常はドメインレジストラを介して、TLDの下でドメイン名を配布できます。

ホスト

ドメイン内で、ドメイン所有者は、ドメインを介してアクセス可能な個別のコンピューターまたはサービスを参照する個々のホストを定義できます。たとえば、ほとんどのドメイン所有者は、ベアドメイン（example.com）および「ホスト」定義「www」（www.example.com）を介してWebサーバーにアクセスできるようにします。

一般ドメインの下に他のホスト定義を含めることができます。「api」ホスト（api.example.com）を介してAPIアクセスを行うことも、「ftp」または「files」（ftp.example.comまたはfiles.example.com）と呼ばれるホストを定義してftpアクセスを行うこともできます。 ]）。ホスト名は、ドメインで一意である限り、任意にすることができます。

サブドメイン

ホストに関連するサブジェクトはサブドメインです。

DNSは階層で機能します。 TLDは、その下に多くのドメインを持つことができます。たとえば、「com」TLDには、その下に「google.com」と「ubuntu.com」の両方があります。「サブドメイン」とは、より大きなドメインの一部である任意のドメインを指します。この場合、「ubuntu.com」は「com」のサブドメインと言えます。これは通常、単にドメインと呼ばれるか、「ubuntu」部分はSLDと呼ばれ、セカンドレベルドメインを意味します。

同様に、各ドメインは、その下にある「サブドメイン」を制御できます。これは通常、サブドメインが意味するものです。たとえば、学校の歴史学部のサブドメインを「www.history.school.edu」にすることができます。「履歴」部分はサブドメインです。

ホスト名とサブドメインの違いは、ホストがコンピューターまたはリソースを定義するのに対し、サブドメインは親ドメインを拡張することです。これは、ドメイン自体を細分化する方法です。

サブドメインについて話している場合でも、ホストについて話している場合でも、ドメインの左端の部分が最も具体的であることがわかります。これがDNSの仕組みです。左から右に読むと、最も具体的なものから最も具体的なものへと変化します。

完全修飾ドメイン名

完全修飾ドメイン名は、しばしばFQDNと呼ばれ、絶対ドメイン名と呼ばれます。 DNSシステム内のドメインは、相互に関連して指定できるため、多少あいまいになる可能性があります。 FQDNは、ドメインネームシステムの絶対ルートに関連する場所を指定する絶対名です。

これは、TLDを含む各親ドメインを指定することを意味します。適切なFQDNは、DNS階層のルートを示すドットで終わります。 FQDNの例は「mail.google.com.」です。 FQDNを要求するソフトウェアは、終了ドットを必要としない場合がありますが、ICANN標準に準拠するために末尾ドットが必要です。

ネームサーバー

ネームサーバーは、ドメイン名をIPアドレスに変換するように指定されたコンピューターです。これらのサーバーは、DNSシステムでほとんどの作業を行います。ドメイン変換の総数は1つのサーバーでは多すぎるため、各サーバーは要求を他のネームサーバーにリダイレクトしたり、担当するサブドメインのサブセットの責任を委任したりする場合があります。

ネームサーバーは「権限のある」ものにすることができます。つまり、ネームサーバーは自分の管理下にあるドメインに関するクエリに回答します。それ以外の場合は、他のサーバーを指しているか、他のネームサーバーのデータのキャッシュされたコピーを提供する可能性があります。

ゾーンファイル

ゾーンファイルは、ドメイン名とIPアドレス間のマッピングを含む単純なテキストファイルです。これは、ユーザーが特定のドメイン名を要求したときに、DNSシステムが最終的にどのIPアドレスに接続する必要があるかを見つける方法です。

ゾーンファイルはネームサーバーに存在し、通常、特定のドメインで利用可能なリソース、またはその情報を取得するために移動できる場所を定義します。

記録

ゾーンファイル内に、レコードが保持されます。最も単純な形式では、レコードは基本的にリソースと名前の間の単一のマッピングです。これらは、ドメイン名をIPアドレスにマップしたり、ドメインのネームサーバーを定義したり、ドメインのメールサーバーを定義したりすることができます。

DNSのしくみ

DNSに関連するいくつかの用語に精通しているので、システムは実際にどのように機能しますか？

システムは、大まかな概要では非常に単純ですが、詳細を見ると非常に複雑です。しかし、全体として、今日私たちが知っているように、インターネットの採用に不可欠なのは非常に信頼性の高いインフラストラクチャです。

ルートサーバー

上で述べたように、DNSは、その中核となる階層システムです。このシステムの最上位には、「ルートサーバー」と呼ばれるものがあります。これらのサーバーはさまざまな組織によって管理されており、ICANN（Internet Corporation for Assigned Names and Numbers）から権限が委任されています。

現在、13台のルートサーバーが稼働しています。ただし、毎分解決する名前の数は非常に多いため、これらの各サーバーは実際にはミラーリングされています。この設定の興味深い点は、単一のルートサーバーの各ミラーが同じIPアドレスを共有していることです。特定のルートサーバーに対して要求が行われると、その要求はそのルートサーバーの最も近いミラーにルーティングされます。

これらのルートサーバーは何をしますか？ルートサーバーは、トップレベルドメインに関する情報の要求を処理します。そのため、下位レベルのネームサーバーが解決できないものに対するリクエストが発生した場合、ドメインのルートサーバーに対してクエリが実行されます。

ルートサーバーは、ドメインがホストされている場所を実際には認識しません。ただし、特別に要求されたトップレベルドメインを処理するネームサーバーにリクエスターを誘導することはできます。

したがって、「www.wikipedia.org」の要求がルートサーバーに対して行われた場合、ルートサーバーはその結果をレコードで検出しません。「www.wikipedia.org」に一致するリストがないかゾーンファイルをチェックします。見つかりません。

代わりに、「org」TLDのレコードを検索し、要求元エンティティに「org」アドレスを担当するネームサーバーのアドレスを提供します。

TLDサーバー

次に、リクエスターは、リクエストのトップレベルドメインを担当するIPアドレス（ルートサーバーから指定された）に新しいリクエストを送信します。

したがって、この例を続けると、「org」ドメインを認識しているネームサーバーにリクエストを送信して、「www.wikipedia.org」がどこにあるかを認識しているかどうかを確認します。

もう一度、リクエスターはゾーンファイルで「www.wikipedia.org」を探します。このレコードはファイルに見つかりません。

ただし、「wikipedia.org」を担当するネームサーバーのIPアドレスをリストしたレコードが見つかります。これは私たちが望む答えにはるかに近づいています。

ドメインレベルのネームサーバー

この時点で、リクエスターは、リソースの実際のIPアドレスを知る責任があるネームサーバーのIPアドレスを持っています。ネームサーバーに新しいリクエストを送信し、「www.wikipedia.org」を解決できるかどうかをもう一度尋ねます。

ネームサーバーはゾーンファイルをチェックし、「wikipedia.org」に関連付けられたゾーンファイルがあることを検出します。このファイルの中には、「www」ホストのレコードがあります。このレコードは、このホストが配置されているIPアドレスを示します。ネームサーバーは、最終的な回答をリクエスターに返します。

解決ネームサーバーとは何ですか？

上記のシナリオでは、「リクエスター」を参照しました。この状況でのリクエスターは何ですか？

ほとんどの場合、リクエスターは「解決ネームサーバー」と呼ばれるものになります。解決ネームサーバーは、他のサーバーに質問するように構成されたサーバーです。これは基本的に、速度を向上させるために以前のクエリ結果をキャッシュし、ルートサーバーのアドレスを知っているユーザーが、まだ知らないことに対して行われた要求を「解決」できるようにするための仲介者です。

基本的に、ユーザーは通常、コンピューターシステムにいくつかの解決ネームサーバーを構成します。解決するネームサーバーは通常、ISPまたは他の組織によって提供されます。たとえば、 Googleは、クエリ可能な解決DNSサーバーを提供しています。これらは、コンピューターで自動または手動で構成できます。

ブラウザのアドレスバーにURLを入力すると、コンピュータはまず、リソースがどこにあるかをローカルで検出できるかどうかを確認します。コンピュータと他のいくつかの場所にある「hosts」ファイルをチェックします。次に、解決するネームサーバーにリクエストを送信し、リソースのIPアドレスを受信するまで待機します。

次に、解決するネームサーバーは、そのキャッシュで回答を確認します。見つからない場合は、上記の手順を実行します。

ネームサーバーを解決すると、基本的にエンドユーザーの要求プロセスが圧縮されます。クライアントは、リソースが配置されている解決するネームサーバーに問い合わせることを知っているだけでよく、調査して最終的な回答を返すことを確信している必要があります。

ゾーンファイル

上記のプロセスで、「ゾーンファイル」と「レコード」の概念について説明しました。

ゾーンファイルは、ネームサーバーが知っているドメインに関する情報を保存する方法です。ネームサーバーが認識しているすべてのドメインは、ゾーンファイルに保存されます。平均的なネームサーバーに送信されるほとんどのリクエストは、サーバーがゾーンファイルを持つものではありません。

ネームサーバーの解決など、再帰クエリを処理するように構成されている場合は、回答を見つけて返します。それ以外の場合は、要求側に次にどこを見ればよいかを通知します。

ネームサーバーが持つゾーンファイルが多いほど、より多くの要求に正式に応答できるようになります。

ゾーンファイルは、DNS「ゾーン」を記述します。これは基本的にDNSネーミングシステム全体のサブセットです。通常、単一のドメインのみを構成するために使用されます。問題のドメインのリソースがどこにあるかを定義する多数のレコードを含めることができます。

ゾーンの$ORIGINは、デフォルトでゾーンの最高レベルの権限に等しいパラメーターです。

したがって、ゾーンファイルを使用して「example.com.」ドメインを構成する場合、$ORIGINはexample.com.に設定されます。

これは、ゾーンファイルの先頭で構成するか、ゾーンファイルを参照するDNSサーバーの構成ファイルで定義できます。いずれにせよ、このパラメーターは、ゾーンが何に対して権限を持つかを記述します。

同様に、$TTLは、提供する情報の「存続時間」を構成します。基本的にはタイマーです。キャッシングネームサーバーは、TTL値がなくなるまで、以前に照会された結果を使用して質問に答えることができます。

レコードタイプ

ゾーンファイル内には、さまざまな種類のレコードを含めることができます。ここでは、より一般的な（または必須のタイプ）いくつかについて説明します。

SOAレコード

Start of Authority（SOA）レコードは、すべてのゾーンファイルの必須レコードです。これは、ファイル内の最初の実際のレコードである必要があります（ただし、$ORIGINまたは$TTLの仕様が上に表示される場合があります）。また、理解するのが最も複雑なものの1つです。

権限レコードの開始は次のようになります。

domain.com.  IN SOA   ns1.domain.com. admin.domain.com. (
                          12083           ; serial number
                          3h              ; refresh interval
                          30m             ; retry interval
                          3w              ; expiry period
                          1h              ; negative TTL
                          )

各部分の目的を説明しましょう。

domain.com。：これはゾーンのルートです。これは、ゾーンファイルがdomain.com.ドメイン用であることを指定します。多くの場合、これは@に置き換えられます。これは、上記で学習した$ORIGIN変数の内容を置き換える単なるプレースホルダーです。
IN SOA ：「IN」の部分はインターネットを意味します（そして多くのレコードに存在します）。 SOAは、これがStartofAuthorityレコードであることを示すインジケーターです。
ns1.domain.com。：これはこのドメインのプライマリネームサーバーを定義します。ネームサーバーはプライマリまたはセカンダリのいずれかであり、ダイナミックDNSが構成されている場合、1つのサーバーを「プライマリ」にする必要があります。これはここにあります。ダイナミックDNSを構成していない場合、これはプライマリネームサーバーの1つにすぎません。
admin.domain.com。：これはこのゾーンの管理者のメールアドレスです。メールアドレスの「@」はドットに置き換えられます。メールアドレスの名前部分に通常ドットが入っている場合は、この部分を「」に置き換えます（[email protected]はyour\name.domain.comになります）。
12083 ：これはゾーンファイルのシリアル番号です。ゾーンファイルを編集するたびに、ゾーンファイルを正しく伝播するために、この数を増やす必要があります。セカンダリサーバーは、ゾーンのプライマリサーバーのシリアル番号がシステム上のシリアル番号よりも大きいかどうかを確認します。そうである場合は、新しいゾーンファイルを要求し、そうでない場合は、元のファイルの提供を続行します。
3h ：これはゾーンの更新間隔です。これは、ゾーンファイルの変更についてプライマリをポーリングする前にセカンダリが待機する時間です。
30m ：これはこのゾーンの再試行間隔です。リフレッシュ期間が終了したときにセカンダリがプライマリに接続できない場合、セカンダリはこの時間待機し、プライマリのポーリングを再試行します。
3w ：これは有効期限です。セカンダリネームサーバーがこの時間プライマリに接続できなかった場合、このゾーンの信頼できるソースとして応答を返すことはなくなります。
1h ：これは、このファイルで要求された名前が見つからない場合に、ネームサーバーが名前エラーをキャッシュする時間です。

AおよびAAAAレコード

これらのレコードは両方とも、ホストをIPアドレスにマップします。「A」レコードはホストをIPv4IPアドレスにマップするために使用され、「AAAA」レコードはホストをIPv6アドレスにマップするために使用されます。

これらのレコードの一般的な形式は次のとおりです。

host     IN      A       IPv4_address
host     IN      AAAA    IPv6_address

したがって、SOAレコードが「ns1.domain.com」のプライマリサーバーを呼び出したため、「ns1.domain.com」は「[ X162X]」このファイルが定義しているゾーン。

レコードは次のようになります。

ns1     IN  A       111.222.111.222

フルネームを付ける必要がないことに注意してください。 FQDNなしでホストを指定するだけで、DNSサーバーが残りの部分に$ORIGIN値を入力します。ただし、セマンティックであると感じた場合は、FQDN全体を同じように簡単に使用できます。

ns1.domain.com.     IN  A       111.222.111.222

ほとんどの場合、ここでWebサーバーを「www」として定義します。

www     IN  A       222.222.222.222

また、ベースドメインがどこに解決されるかを通知する必要があります。これは次のように実行できます。

domain.com.     IN  A       222.222.222.222

代わりに、「@」を使用してベースドメインを参照することもできます。

@       IN  A       222.222.222.222

このドメインでこのサーバーに明示的に定義されていないものを解決するオプションもあります。これは、「*」ワイルドカードを使用して実行できます。

*       IN  A       222.222.222.222

これらはすべて、IPv6アドレスのAAAAレコードでも同様に機能します。

CNAMEレコード

CNAMEレコードは、サーバーの正規名のエイリアスを定義します（AまたはAAAAレコードで定義されたもの）。

たとえば、「server1」ホストを定義するA名レコードを作成し、「www」をこのホストのエイリアスとして使用できます。

server1     IN  A       111.111.111.111
www         IN  CNAME   server1

これらのエイリアスは、サーバーへの追加のクエリを必要とするため、パフォーマンスが低下することに注意してください。ほとんどの場合、追加のAまたはAAAAレコードを使用しても同じ結果が得られます。

CNAMEが推奨される1つのケースは、現在のゾーン外のリソースにエイリアスを提供することです。

MXレコード

MXレコードは、ドメインで使用されるメール交換を定義するために使用されます。これにより、電子メールメッセージがメールサーバーに正しく到着します。

他の多くのレコードタイプとは異なり、メールレコードはゾーン全体に適用されるため、通常、ホストを何かにマップしません。そのため、通常は次のようになります。

        IN  MX  10   mail.domain.com.

最初にホスト名がないことに注意してください。

また、そこには余分な番号があることに注意してください。これは、複数のメールサーバーが定義されている場合に、コンピューターがメールの送信先サーバーを決定するのに役立つ優先番号です。数値が小さいほど優先度が高くなります。

MXレコードは通常、CNAMEで定義されたホストではなく、AまたはAAAAレコードで定義されたホストを指している必要があります。

したがって、2つのメールサーバーがあるとしましょう。次のようなレコードが必要になります。

        IN  MX  10  mail1.domain.com.
        IN  MX  50  mail2.domain.com.
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

この例では、「mail1」ホストが優先される電子メール交換サーバーです。

次のように書くこともできます。

        IN  MX  10  mail1
        IN  MX  50  mail2
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

NSレコード

このレコードタイプは、このゾーンに使用されるネームサーバーを定義します。

「ゾーンファイルがネームサーバーにある場合、なぜそれ自体を参照する必要があるのか」と疑問に思われるかもしれません。 DNSを成功させる要因の一部は、複数レベルのキャッシングです。ゾーンファイル内でネームサーバーを定義する理由の1つは、ゾーンファイルが実際には別のネームサーバー上のキャッシュされたコピーから提供されている可能性があるためです。ネームサーバー自体で定義されたネームサーバーが必要になる理由は他にもありますが、ここでは詳しく説明しません。

MXレコードと同様に、これらはゾーン全体のパラメータであるため、ホストも使用しません。一般的に、それらは次のようになります。

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.

1台のサーバーに問題がある場合に正しく動作するには、各ゾーンファイルに少なくとも2台のネームサーバーを定義する必要があります。ほとんどのDNSサーバーソフトウェアは、ネームサーバーが1つしかない場合、ゾーンファイルを無効と見なします。

いつものように、AまたはAAAAレコードを持つホストのマッピングを含めます。

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.
ns1     IN  A      111.222.111.111
ns2     IN  A      123.211.111.233

使用できるレコードタイプは他にもかなりありますが、これらはおそらく最も一般的なタイプです。

PTRレコード

PTRレコードは、IPアドレスに関連付けられた名前を定義するために使用されます。 PTRレコードは、AまたはAAAAレコードの逆です。 PTRレコードは、.arpaルートで始まり、IPアドレスの所有者に委任されるという点で独特です。地域インターネットレジストリ（RIR）は、組織およびサービスプロバイダーへのIPアドレスの委任を管理します。地域インターネットレジストリには、APNIC、ARIN、RIPE NCC、LACNIC、およびAFRINICが含まれます。

111.222.333.444のPTRレコードの例は次のようになります。

444.333.222.111.in-addr.arpa.    33692   IN  PTR host.example.com.

このIPv6アドレスのPTRレコードの例は、GoogleのIPv6DNSサーバー2001:4860:4860::8888の逆のnibble形式を示しています。

8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.

-xフラグを指定したコマンドラインツールdigを使用して、IPアドレスの逆引きDNS名を検索できます。

digコマンドの例を次に示します。 +shortは、出力を逆引きDNS名に減らすために追加されます。

dig -x 8.8.4.4 +short

上記のdigコマンドの出力は、IPアドレスのPTRレコードのドメイン名になります。

google-public-dns-b.google.com.

インターネット上のサーバーは、PTRレコードを使用して、ログエントリ内にドメイン名を配置し、情報に基づいたスパム処理の決定を行い、他のデバイスに関する読みやすい詳細を表示します。

最も一般的に使用される電子メールサーバーは、電子メールの受信元のIPアドレスのPTRレコードを検索します。送信元IPアドレスに関連付けられたPTRレコードがない場合、送信される電子メールはスパムとして扱われ、拒否される可能性があります。 PTRのFQDNが送信される電子メールのドメイン名と一致することは重要ではありません。重要なのは、対応する一致するフォワードAレコードを持つ有効なPTRレコードがあることです。

通常、インターネット上のネットワークルーターには、物理的な場所に対応するPTRレコードが与えられます。たとえば、ニューヨーク市またはシカゴのルーターの「NYC」または「CHI」への参照が表示される場合があります。これは、tracerouteまたはMTRを実行し、インターネットトラフィックがたどるパスを確認するときに役立ちます。

専用サーバーまたはVPSサービスを提供するほとんどのプロバイダーは、顧客にIPアドレスのPTRレコードを設定する機能を提供します。 DigitalOceanは、ドロップレットにドメイン名が付けられている場合、ドロップレットのPTRレコードを自動的に割り当てます。ドロップレット名は作成時に割り当てられ、後でドロップレットコントロールパネルの設定ページを使用して編集できます。

注： PTRレコードのFQDNに、対応する一致するフォワードAレコードがあることが重要です。例：111.222.333.444のPTRはserver.example.comであり、server.example.comは111.222.333.444を指すAレコードです。

CAAレコード

CAAレコードは、ドメインに対してSSL / TLS証明書を発行できる認証局（CA）を指定するために使用されます。 2017年9月8日の時点で、すべてのCAは、証明書を発行する前にこれらのレコードを確認する必要があります。レコードが存在しない場合、どのCAも証明書を発行できます。それ以外の場合は、指定されたCAのみが証明書を発行できます。 CAAレコードは、単一のホストまたはドメイン全体に適用できます。

CAAレコードの例は次のとおりです。

example.com. IN  CAA 0 issue "letsencrypt.org"

ホスト、IN、およびレコードタイプ（CAA）は、一般的なDNSフィールドです。上記のCAA固有の情報は、0 issue "letsencrypt.org"の部分です。これは、フラグ（0）、タグ（issue）、および値（"letsencrypt.org"）の3つの部分で構成されています。

Flags は、CAが理解できないタグを処理する方法を示す整数です。フラグが0の場合、レコードは無視されます。 1の場合、CAは証明書の発行を拒否する必要があります。
タグは、CAAレコードの目的を示す文字列です。現在、CAが特定のホスト名の証明書を作成することを承認するissue、ワイルドカード証明書を承認するissuewild、またはCAがポリシー違反を報告できるURLを定義するiodefにすることができます。。
Values は、レコードのタグに関連付けられた文字列です。 issueおよびissuewildの場合、これは通常、アクセス許可を付与しているCAのドメインになります。 iodefの場合、これはお問い合わせフォームのURL、または電子メールフィードバック用のmailto:リンクの場合があります。

digを使用して、次のオプションを使用してCAAレコードをフェッチできます。

dig example.com type257

CAAレコードの詳細については、 RFC 6844 、またはチュートリアルDigitalOceanDNSを使用してCAAレコードを作成および管理する方法を参照してください。

結論

これで、DNSがどのように機能するかをかなりよく理解できたはずです。戦略に慣れれば、一般的な考え方は比較的簡単に理解できますが、それでも、経験の浅い管理者が実践するのは難しい場合があります。

概要については、DigitalOceanコントロールパネル内でドメインを設定する方法を確認してください。