ドメイン・DNS - ネットワーク

最終更新日: 2026-07-25

TOP(About this memo)) > 一覧(ネットワーク) > ドメイン・DNS

参考

• https://server-99.com/dns-record/

ドメインの種類

• （例）www.example.com
• トップレベルドメイン
  • .comや.jp、.netなどが該当。.jpであれば、日本が管理するドメインに所属しているということ。
• 第2レベルドメイン
  • トップレベルドメインの次にくるものを第2レベルドメインという。第2レベルドメインの次にくるものは第3ドメインといい、数が増えていく。
• ショートドメイン
  • 取得可能な階層までのドメインのこと。example.comなど。
• サブドメイン
  • ショートドメインにさらに階層を加えたもの。
• FQDN
  • 「Fully Qualified Domain Name」の略。レコードとして登録されている、ショートドメインやサブドメインのこと。

トップレベルドメイン

• gTLD(Generic Top Level Domain)ドメイン
  • 分野別トップレベルドメインのことを指す。
  • 特定の領域・分野ごとに割り当てられたトップレベルドメイン。
  • 一般的に地理的制限なしに世界のどこからでも登録することが可能。
  • .com .net .org .info .biz .mobi .tokyo など。
• 汎用JPドメイン・都道府県型JPドメイン
  • .jp
  • .都道府県.jp

ICANN(The Internet Corporation for Assigned Names and Numbers)

• インターネットの三つの識別子の割り振りや割り当ての管理・調整を行う。
  • ドメイン名
  • IPアドレス及びAS番号
  • 各プロトコルで使われる名前及び番号
• DNSルートサーバーシステムの運用や調整。
• これらの技術的機能に関連するポリシー策定の合理的かつ適切な調整。

レジストリ・レジストラ

• (参考) https://faq.wadax.ne.jp/s/article/93
• gTLDの場合は、ドメイン名登録には「レジストリ・レジストラモデル」と呼ばれる形態が採用されている。
• レジストリ
  • 登録ドメイン名のデータベースを維持管理する機関。
• レジストラ
  • 登録者からドメイン名の登録申請を受け付け、その登録データをレジストリのデータベースに登録する機関。

JPRS・指定事業者

• JPドメイン名は、株式会社日本レジストリサービス（以下、JPRS）に定められた「指定事業者」と呼ばれる業者がドメイン名の管理を行う。
• JPドメインの場合は「指定事業者」が管理する。
• JPドメインは、指定事業者と呼ばれるJPRSが定めたドメイン登録業務を代行する法人を通じて管理される。

JPRS(Japan Registry Services)（日本レジストリサービス）とは

• 「JPドメイン名」の登録管理。
• ドメインネームシステム（DNS）の運用。
• JPドメイン名のレジストリ。

レジストラ・指定事業者の業務

• ドメイン名に関する登録・更新手続き。
• ドメイン名に関する料金の支払い。
• ドメイン名の情報変更。
• ネームサーバーの登録。
• Whois情報の公開。

(IMO)レジストラの選び方

• レンタルサーバーと連携できる
  • レンタルサーバーとドメイン名は、別々の業者で運用管理ができるが、同じ業者に一本化することで管理がよりスムーズに行える。
• ドメイン名の料金と管理コストで選ぶ
  • ドメイン名が利用できなくなると、Webサイトが見れなくなったり、メールが使えなくなったりと、ビジネスでは機会損失や損害に繋がる可能性がある。ドメインの費用以外に、更新忘れの防止や管理の手間を考え、トータルでのコストメリットを考えるとよい。サポートや管理画面が日本語に対応していると安心して運用ができる。

ドメイン移転と指定事業者変更の違い

• 両方とも、ドメインのレジストラ(指定事業者)を変更すること。
• 以下の2種類がある。
  • ドメイン移転
    • gTLDドメインの場合はこちらの手続きになる(?)。
    • (誤り訂正) 以前「ドメイン移転では残日数を引き継げず放棄になる」と記載していたが、これは誤りだった。ICANNのTransfer Policyにより、移転時は既存の有効期限に1年が加算される（合計で最大10年までという上限はある）形で、残日数は失われない。
  • 指定事業者変更
    • JPドメイン固有の手続き。ドメインのレジストラ(指定事業者)自体をまとめて変更する。
    • 無料なことが多い(?)。
    • 指定事業者変更の場合は、ICANNのTransfer Policyの対象外であるため、期限延長は発生せず、そのままの残日数・有効期限を引き継ぐ。

(参考)ドメイン移転の具体例

• (参考) https://www.kagoya.jp/howto/webhomepage/04/
• JPドメインかgTLDドメインかで変わってくる。
• さくらサーバーだと「指定事業者変更」が無料。
  • (参考) https://www.focusmark.jp/2015/03/jp-domain-change-corp/
  • (参考) https://help.sakura.ad.jp/206052992/?_ga=2.69810448.1275433848.1574050832-860979488.1564374584

ホストゾーン（Hosted Zone）とは

ホストゾーンとは

ホストゾーン（Hosted Zone）とは、あるドメインのDNSレコードを管理する場所のこと。

例えばexample.comのホストゾーンには、以下のようなDNSレコードが保存される。

• Aレコード（WebサーバーのIPアドレス）
• CNAMEレコード（別ドメインへの別名）
• MXレコード（メールサーバー）
• TXTレコード（ドメイン認証など）
• NSレコード（ネームサーバー）

ドメイン・レジストラ・ホストゾーンの関係

example.com（ドメイン）
        │
        ▼
レジストラ（ドメインを購入・管理）
        │
        │ ネームサーバー(NS)を設定
        ▼
ホストゾーン（DNSレコードを管理）
        │
        ├─ www.example.com → Webサーバー
        ├─ api.example.com → APIサーバー
        ├─ MX → メールサーバー
        └─ TXT → ドメイン認証

それぞれの役割

• ドメイン：インターネット上の住所（例：example.com）
• レジストラ：ドメインを購入・管理する会社（お名前.com、ムームードメインなど）
• ホストゾーン：そのドメインのDNSレコードを管理する場所

※ ホストゾーンの実装例として、AWSでは「Route 53 Hosted Zone」がある。

ネームサーバー（NS）の役割

ネームサーバーは、「このドメインのDNS情報はどこに問い合わせればよいか」を示す情報。

例えば、ホストゾーンが発行したネームサーバーをレジストラに設定すると、そのドメインに対するDNSの問い合わせは、そのホストゾーンに送られる。

ブラウザ
    │
    ▼
example.com のIPアドレスは？
    │
    ▼
ネームサーバー
    │
    ▼
ホストゾーンのDNSレコードを参照
    │
    ▼
IPアドレスを返す

ドメイン設定の流れ

1. レジストラでドメインを取得する。
2. DNSを管理するホストゾーンを作成する。
3. ホストゾーンが発行したネームサーバー(NS)をレジストラに設定する。
4. 以後はホストゾーンでDNSレコードを管理する。

ポイント

• ドメインを購入する場所とDNSを管理する場所は別でもよい。
• レジストラは「ドメインの所有者」を管理する。
• ホストゾーンは「DNSレコード」を管理する。
• ネームサーバー(NS)は「DNSをどこで管理しているか」を示している。

DNS（Domain Name System）サーバー、ネームサーバー

• (参考) https://zenlogic.jp/user-support/knowledge/domain/nameserver.html
• インターネット通信時にドメイン名をIPアドレスに変換する名前解決を行うサーバー。
• ネームサーバとも呼ばれる。
  • DNSサーバーは、ルートDNSサーバーやjpのDNSサーバーなども指すが、ネームサーバーは最終地点のDNSサーバーのこと。
  • 例えば、example.jpを最終的に解決してくれるDNSサーバーを指しているような感じもする(IMO)。
• 例
  • NS1.DNS.NE.JP
  • NS2.DNS.NE.JP

DNSサーバーの変更

• (参考) http://qa.future-shop.jp/faq/show/2192?site_domain=default
• レジストラ(指定事業者)変更には、ネームサーバーの変更も伴うはず(?)。
  • ネームサーバーの変更は名前解決する際のサーバーの変更（そのままの意味）。
• つまり、名前解決のルートを変更すること。具体的に下記のような手段がある。
  • ネームサーバー自体を変える
    • 例：ドメインのネームサーバー情報を ns1.xxxxxx.xxx,ns2.xxxxxx.xxx → ns1.yyyyyy.yyy,ns2.yyyyyy.yyy という感じに変更する。
  • DNSゾーン情報（Aレコードとか）を変更
    • メールサーバー、及び独自で設定のサブドメインなど引き続き変更前の業者のものを使いたいのであれば、ドメインのDNSゾーン情報にAレコードなどを設定すればよい。
    • 例

      www.example.com A 　000.00.000.00
      example.com MX mail.example-mailservice.com
      

プライマリDNSサーバーとセカンダリDNSサーバー

• プライマリサーバー
  • 「マスターサーバー（Master Server）」とも呼ばれる。
  • 最初にゾーン情報が設定される権威DNSサーバーを指す。人間がゾーンファイルを設定する。
• セカンダリサーバー
  • 「スレーブサーバー（Slave Server）」とも呼ばれる。
  • ゾーン転送の仕組みを使用してプライマリサーバーからゾーン情報を得る権威DNSサーバーを指す。
  • こちらは人間が設定するのではなく、プライマリからゾーン情報を読み取る。

NSレコード(DNSレコード)

• NS（ネームサーバー）レコードは、プライマリDNSサーバーを指定するレコードのこと。

サブドメインの委任

• 委任元からNSレコードで、委任先へ向けること。
  • (参考) https://www.atmarkit.co.jp/fnetwork/dnstips/007.html
• ドメインのツリー構造は委任によって成り立っている。
  • ドメインのツリー構造の一番トップはルート（「.」で表される）。
  • ここから、さらにjpやcom、orgなどのTLD（Top Level Domain）にサブドメインを委任している。
  • そして、それ以降も同様に委任している。

@マーク

• DNSレコードで、@.sample.comのような表記がある。@は空白を入れた場合と意味的には同じと考えられる(?)。
  • ただし、TXTレコードを同じドメインに対して複数定義すると重複エラーになる場合があるが、@と空白（何も指定しない）はそれぞれ別のレコードとして登録できる(?)。
• (参考) https://help.onamae.com/answer/7885

TTL

• DNSにはTTLを設定しておくことが可能。
• DNSの仕組みとして、名前解決のたびに全て検索するとコストがかかるため、DNSキャッシュの仕組みがある。
• つまり、TTLの時間の間は前に検索した結果のキャッシュをDNSの問い合わせへの応答として使ってよいということ。
• ただし、IPアドレスを変更した場合でもTTLの時間はキャッシュが生存しているため、すぐには切り替わらない(?)。
• このため、IPアドレスを変更するときは事前にTTLを短くしておくなどの対策がある(?)。
• (参考) https://www.nic.ad.jp/ja/newsletter/No51/0800.html

逆引・正引・whois

逆引

• さくらでは標準でホスト名が逆引登録されている。
• 逆引はサーバの信頼性を担保するもので、たとえば送られてきたメールのIPアドレスを検証するとしたら、以下のような流れになる(IMO)。
  • ① IPアドレスを逆引き（①だけだといくらでも登録できるので不十分）
  • ② 出てきたFQDNを正引きして①と一致するか確認。
• (参考) https://help.sakura.ad.jp/hc/ja/articles/206208061-DNS%E9%80%86%E5%BC%95%E3%81%8D%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B
• (参考) http://d.hatena.ne.jp/japanrock_pg/20090602/1243942825

nslookup 203.0.113.10
10.113.0.203.in-addr.arpa   name = ik1-xxxxxx-xxxxx.vs.sakura.ne.jp.
# ※コマンドの最初に出てくるserverは問い合わせ先のネームサーバ（多分）

dig -x 203.0.113.10
10.113.0.203.in-addr.arpa. 3432 IN  PTR    ik1-xxxxxx-xxxxx.vs.sakura.ne.jp.

dig ik1-xxxxxx-xxxxx.vs.sakura.ne.jp
ik1-xxxxxx-xxxxx.vs.sakura.ne.jp. 2663 IN A  203.0.113.10

正引き

dig example.com
example.com. 1323   IN A  203.0.113.10
dig example2.org
example2.org.       2040   IN A  203.0.113.10
dig example3.com
example3.com.  3600   IN A  203.0.113.10

whois

• (参考) https://blog-bootcamp.com/start/wordpress-domain-whois/
• whoisではドメインの登録者・管理者の連絡情報を提供して公開することが、管理団体のICANNによって義務付けられている。
• whoisではドメインが誰に所有されているかが分かるが、一方で個人情報が公開されるプライバシーの問題がある。
• これについては、Whois代理公開サービスを利用するとよい。
• Whois代理公開サービス
  • (参考) https://www.xserver.ne.jp/manual/man_domain_about_whois.php
  • Whoisで公開される情報をレジストラの名義にしてくれるサービス。
  • ただし、ICANNの定めにより、このサービスの利用に関わらず、情報の登録自体は必要である。(公開はされない)

DNSキャッシュ削除

sudo killall -HUP mDNSResponder

送信ドメイン認証

• 送信ドメイン認証の２つの手法
  • ①IPアドレスに基づく方式（SPFなど）
    • Envelope-Fromのドメイン認証を行う（Header-Fromを参照するケースもあり）。
    • メールのソース
      • Authentication-Results: spf=pass (sender IP is xxx.xxx.xxx.xxx)と書いてある箇所。spf=noneだとSPFレコードが設定されていない状態と考えられる(?)。
      • あと、Received-SPF: Passという箇所もある(?)。
  • ②電子署名に基づく方式（DKIMなど）
    • Header-Fromのドメイン認証を行う。
    • (?) ただ、以下のURLの質問ではEnvelope-Fromを指していると回答されていたような気もする。
      • (参考) https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10247992835
  • この2つの認証結果を組み合わせて、失敗時の扱い（ポリシー）を指定したりレポートを受け取ったりする仕組みとしてDMARCがある（詳細は下記「DMARCレコード」を参照）。
• エンベロープFrom、ヘッダFrom
  • ヘッダFromはよくプログラムでfromとして設定するものに該当する感じ(IMO)。
  • エンベロープFromはメールのソース上の「Return-Path」の部分。
  • エンベロープFromも自分で設定することができる(?)。
  • 配信サーバーなどによってはエンベロープFromとヘッダFromが一致しないこともある(?)。
  • 両者が異なっているとメールソフトが迷惑メールの可能性があるものと判断してしまうことがある(?)。
    • (?) それとも、エンベロープFrom、ヘッダFromが異なっていてもよくあるものとして、特になりすましとは判断しないのか。
    • (?) あるいは、SPFレコードが設定されていて送信元サーバーのIPが認証された場合は、たとえ両者が異なっていてもOKになるのか。
  • (参考) PHPでエンベロープFromを変える方法： https://kaworu.jpn.org/kaworu/2008-02-17-2.php
• 参考
  • https://www.cuenote.jp/documents/smtp/000204.html
  • https://baremail.jp/blog/2021/05/25/1377/
  • https://support.biglobe.ne.jp/ask/nesco/header.html
  • https://faq.support.biglobe.ne.jp/faq_detail.html?faq_id=10571
  • https://www.dekyo.or.jp/soudan/contents/taisaku/4-2.html

ドメイン移行に伴い迷惑メール扱いになった事例(IME)

• ドメインの完全移行作業（旧ドメインから新ドメインへの移行）の際にSPFレコードの設定漏れが発生し、送信メールがスパム扱いされてしまったことがある。
• 移行作業の切り替え直後は、旧設定のDNSキャッシュが残っていたため一時的に正常に送信できていたが、キャッシュが切れたタイミングで迷惑メール扱いになる事象が発生したと考えられる。
• 対応としては、新ドメイン側にSPFレコードを再設定し、あわせてDKIMの設定に誤りがあったため修正した。設定の反映後、正常に送信できることを確認した。
• (IMO) ドメイン移行や送信元の切り替えを行う際は、SPF/DKIM等の送信ドメイン認証系のレコードを移行前にあわせて確認しておくべきだと感じた。

DMARCレコード（Domain-based Message Authentication, Reporting & Conformance）

• SPF・DKIMの認証結果を踏まえて、認証に失敗したメールをどう扱うか（そのまま配信／隔離／拒否）を送信ドメイン側が指定できる仕組み。あわせて、認証結果の集計レポートを受け取ることができる。
• SPF・DKIMはそれぞれ単体でも機能するが、DMARCはこの2つの結果を「アライメント（Header-Fromのドメインとの一致）」まで含めて評価する。
  • SPFアライメント：Envelope-From（Return-Path）のドメインと、Header-From（メールソフトに表示される送信者）のドメインが一致しているか。
  • DKIMアライメント：DKIM署名のドメイン（d=タグ）と、Header-Fromのドメインが一致しているか。
  • どちらか一方でもアライメントが取れてpassしていれば、DMARC自体はpassと判定される(?)。
• DMARCレコードもTXTレコードとして、_dmarc.example.comに登録する。

  _dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
  

• 主なタグ
  • v=DMARC1：バージョン。固定値。
  • p=：適用ポリシー。none（何もしない・監視のみ）／quarantine（隔離＝迷惑メールフォルダ等に振り分け）／reject（拒否）のいずれか。
  • rua=：認証結果の集計レポート（Aggregate Report）の送付先。
  • ruf=：失敗時の詳細レポート（Forensic Report）の送付先(?)。対応していない受信側も多い(?)。
  • pct=：ポリシーを適用する対象の割合（%）。指定しない場合は100%(?)。
  • sp=：サブドメイン向けのポリシー。省略時はpの値が継承される(?)。
• いきなりp=rejectにすると正規のメールまで届かなくなるリスクがあるため、まずp=noneでレポートを受け取りながら現状を把握し、問題ないことを確認してからquarantine→rejectと段階的に厳格化していくのが定石とされる(?)。
• (参考) https://dmarc.org/
• (参考) https://datatracker.ietf.org/doc/html/rfc7489

(IME) DMARCレコード未設定でGmailの迷惑メールに振り分けられた事例

• 自社ドメインから送信したメールがGmailで迷惑メールフォルダに振り分けられたため、Gmailの「メッセージのソースを表示」機能でヘッダーを確認した。
• サマリー欄では、SPF・DKIMはいずれもPASS（かつHeader-Fromとのドメインアライメントも一致）と表示されていたにもかかわらず、DMARCの欄だけFAILと表示されていた。
• ドメインのDNSを確認したところ、_dmarc.<自社ドメイン>のTXTレコード自体が登録されておらず、DMARCポリシーが未設定の状態だった。
• (?) 本来、DMARCレコードが存在しない場合はプロトコル上dmarc=none（評価対象外）という結果になるはずだが、Gmailの「メッセージのソースを表示」画面のサマリーでは、DMARCポリシーが確認できない場合に簡易的にFAILと表示されることがあるようだ。SPF・DKIMが個別にPASSしていても、DMARCレコードが無ければこの表示になりうる。
• (IMO) SPF・DKIMを設定していても、DMARCレコードまで設定していないと、受信側によっては迷惑メール判定の材料にされる可能性がある。まずはp=noneでDMARCレコードを追加し、監視から始めるのがよい。

Aレコード（エーレコード）

• ドメインとIPアドレスを関連づけるもの。
• Aレコードには取得したショートドメインをそのまま登録することが可能。
• wwwなどをつけた、サブドメインとして登録することも可能。

  example.com　→　IPアドレス
  www.example.com →　IPアドレス
  

(参考)Route53のドメインをさくらで使用する方法（例）

• AWSで管理するドメインをexample.jpとする。
• さくらの方でexample.jpを設定（他社のドメインを設定、から行う）。
• AWS側でexample.jpのAレコードをユーザー名.sakura.ne.jpのIPアドレスに向ける。
• HTTPSを利用する際は、さくらの方でSSLの証明書を発行申請すればよい（数分程度で発行される）。

TXTレコード

• テキスト情報を提供する役割。
• 身近な用途では、GoogleのSearch Console（通称サチコ）へサイトを登録する際に、サイトの所有権を確認するために利用する。
• 基本的に、ドメインのレコードを修正できるのは所有者だけとなるので、Google指定のテキスト情報を「TXTレコード」へ登録することで所有者の証明ができる（metaタグなどでもできる）。
• また、所有者の証明に関連して、メールを送信する場合に正規のサーバから送信されていることを証明するために、SPFレコードとして利用することもある。

TXTレコードを複数設定したい場合

• 値を""で囲んで、改行する。
• (参考) https://dev.classmethod.jp/articles/route53-txt-multiple/

Gmailの迷惑メール回避

• TXTレコードでSPFを設定する。（Google Workspaceに登録したドメインで、そのドメインを送信元としてGoogleを経由してメール送信するケース）
• v=spf1 include:_spf.google.com ~all
• これでGmailがメール受信するときに、例えばhello@sample.comのTXTレコードに問い合わせをして、このレコードが返ってくるはずなので迷惑メールと判定されないようになるはず。
• (参考) https://support.google.com/a/answer/10685031
• digでTXTレコードを確認したらすぐ反映されていたが、しばらくは迷惑メールとして分類されてしまうことがあった(IME)。時間の経過とともに解消した(?)。

サブドメインは別で登録しないといけない

• (参考) https://support.google.com/a/answer/10684623
• 親ドメインでSPFが登録されていても、サブドメインには適用されない。サブドメインはサブドメインで登録する必要がある。

(参考) CNAMEを設定すると、TXTレコード等の他のレコードは設定できない

• (IME) Firebase Authのカスタムドメイン設定のためにDNSレコードの設定をしたが、TXTレコードが反映されない、という事象に遭遇したことがある。（dig でTXTレコードを確認しても該当のレコードが表示されない）
  • firebase1._domainkey.<サブドメイン>などのCNAMEレコードはきちんと反映されていた。また、Firebase Hostingの方で設定したサブドメインへのCNAMEもちゃんと反映されていた。
• ホスティング業者に問い合わせたところ、当日中に「DNS浸透待ちと思われる」と回答があった。
• 40時間程度経過しても反映されなかったため、一旦TXTレコードを削除して再登録した。
  • なお、別ドメインの方にTXTレコードを設定してみたところ、翌朝確認すると反映されていた。
• 再度問い合わせをしたところ、翌日CNAMEレコードを設定していることが原因と回答を受領した。
  • 該当のサブドメインに対して、以下のように設定していた。
    • Firebase Hostingの方でCNAMEを設定
    • Firebase Authの方でTXTを設定

対応

• Route53だとエイリアスを利用することでCNAMEとTXTレコードを併用できるらしい(?)。
• ただ、利用していたDNS管理サービスの設定ではできなかったため、ホスティング用と、メールの送信元用のサブドメインを分けることで対応した。

CNAMEレコード（シーネームレコード）

• Aレコードと同じく、ドメインに対応するIPアドレスを教えてあげるのが役割。
• Aレコードとの違いは以下。
  • 指定の仕方がIPアドレスではなく、Aレコードに登録されているFQDNになる。
  • CNAMEレコードには、Aレコードとして存在しないFQDNを登録することはできない。
  • Aレコードのようにショートドメインの登録ができない。
• メリットの具体例
  • 例えば、IPアドレスが変更になった場合、（１）の場合は全部変更しないといけないが、（２）の場合は一つでよい。はてなブログもCNAMEで設定しているが、その理由はこのコストのため(IMO)。
  • （１）Aレコードで登録した場合

    www1.server-99.com A 192.168.10.102
    www2.server-99.com A 192.168.10.102
    www3.server-99.com A 192.168.10.102
    www4.server-99.com A 192.168.10.102
    www5.server-99.com A 192.168.10.102
    

  • （２）CNAMEレコードで登録した場合

    www1.server-99.com A 192.168.10.102
    www2.server-99.com CNAME www1.server-99.com
    www3.server-99.com CNAME www1.server-99.com
    www4.server-99.com CNAME www1.server-99.com
    www5.server-99.com CNAME www1.server-99.com
    

注意: CNAMEは他のレコードと共存できない

• 例えば、CNAMEを設定して、他にAレコードやTXTレコードを設定することはできない。
• これはRFC1912で規定されている。
• SPFレコードを設定したい場合などは困ることがある。
• Route53の場合はエイリアスの機能を利用することで対応できるが、他のDNSレコード管理サービスだとできないことがある。
• (参考) https://qiita.com/sugimount-a/items/0b7f80eae8ca3ddb136a
• (参考) https://tech.blog.aerie.jp/entry/2014/09/09/162135
• (参考) https://zenn.dev/naoki_mochizuki/articles/d0d9fd2459250baeb37d

(参考)具体的なCNAMEの事例

• 例えば、さくらVPSの場合、ゾーン設定の画面から「タイプ」をCNAMEレコード、「エントリ」を例えば「blog」とすることでblog.***.comといったサブドメインを取得できる。デフォルトとして「www」「mail」「ftp」はCNAMEレコードが登録されているようだ。
• また、「タイプ」をAレコード、「エントリ」を「blog」、「値」をサーバのIPアドレスに設定したとしても、同じことができる。
  • (参考) http://mekori.hatenablog.com/entry/2013/04/20/231157
• 「ネームサーバ利用申請」メニュー
  • 基本的にさくらで取得した独自ドメインは、標準でさくらのネームサーバが利用される。
    • ※ゾーン情報に、NSとして登録されているns1.dns.ne.jpやns2.dns.ne.jpがさくらのネームサーバのこと。
  • 他社で取得した独自ドメインをさくらのネームサーバで名前解決したい場合は、この設定が必要になる。
  • やることは、
    • 「ネームサーバ利用申請」から対象ドメインについて申請する。
    • 取得した会社の方の設定画面でも、ネームサーバをさくらのネームサーバへ変更する。
  • これによって他社の独自ドメインをさくらのネームサーバで解決でき、ゾーン編集では各レコードを追加することもできる。
  • (?) さくらのネームサーバを利用するメリットは大きくないかもしれない。他の会社のネームサーバがそのまま利用できるのであればそれを使えばよい気もする。ゾーン情報についても、他社の画面からAレコードでさくらのサーバのIPアドレスを指定すれば済むはず。管理を一元化できる、といったメリットはあるのかもしれない。
• お名前.comの例
  • 例えばお名前.comでは、以下のように設定されていた（過去にどこかのサイトを参考にして実施したもの）。
  • Aレコードで対象サーバのIPアドレスを指定するのではなく、CNAMEで登録されていることがわかる。

    ホスト名 TYPE   TTL    VALUE
    example-blog.work NS 86400 01.dnsv.jp
    example-blog.work NS 86400 02.dnsv.jp
    example-blog.work NS 86400 03.dnsv.jp
    example-blog.work NS 86400 04.dnsv.jp
    www.example-blog.work CNAME   3600 hatenablog.com
    

  • このようにはてなブログはCNAMEで登録する仕様なので、ショートドメインで登録することはできないはず。
  • また、wwwを付けないとGoogleアドセンスの審査が通らないという情報もあった(?)。
    • (参考) https://www.humbert-tomoyuki.com/entry/hatena-domain
  • 参考
    • https://webkaru.net/vps/sakura-domain-setting/
    • https://help.sakura.ad.jp/hc/ja/articles/206207381-%E3%83%8D%E3%83%BC%E3%83%A0%E3%82%B5%E3%83%BC%E3%83%90%E5%88%A9%E7%94%A8%E7%94%B3%E8%AB%8B （他社のドメインをネームサーバ利用申請で登録して、ゾーン編集する手順が一通り書いてある）
    • https://www.onamae.com/guide/details.php?g=18&_ga=2.197434665.787928170.1536636102-1255044962.1536636102 （お名前.comでDNSレコードの設定）

（参考）委任が難しいためCNAMEで対応した例

• サブドメインの委任が難しいと言われ、代わりにCNAMEを設定してもらったケース(IME)。
• CNAMEでロードバランサーのDNS名を指定してもらう。
• ACMでSSL証明書発行の際も、DNS検証をCNAMEで先方に登録しておけば対応できる。
• 注意点として、CNAMEで登録するとMXレコードなどもこちらに飛んでくること。
  • もし先方でメールサーバー管理などが必要になった場合、さらにこちらからMXレコードを向けてあげる必要がある(?)。
• AレコードではなくCNAMEにしたのは、Aレコードだとロードバランサーを指定できないため。
  • IPアドレスしか指定できない。ロードバランサーはIPアドレスがなく、DNS名しかない。
• (?) そもそもサブドメインの委任ができないのはなぜか（セキュリティ的な理由か）は把握できていない。

MXレコード

• (参考) https://norm-nois.com/blog/archives/3636
• ドメインに対するメールの届け先を教える役割。
• 設定はIPアドレスではなく、CNAMEと同様に、Aレコード登録済みのFQDNを指定する。
• MXレコードが省略されている場合は、該当するFQDNのAレコードの設定先にメールが届く。
• ウェブサーバーとメールサーバーを別々のサーバーで管理したい場合は、MXレコードを利用する。
• 複数のメールサーバを登録しておいて「優先順位」を設定すれば冗長化できるらしい(?)。
• メールサーバを立てる流れ
  • 例えば、値をmail.***.comとして「MXレコード」として登録しておき、
  • サーバー側でFireWallのポート（25、110、143、587あたり）を開けて、
  • SMTPサーバー（postfix）、POP3／IMAPサーバー（Dovecotあたり）、認証サーバー（SASL）を立てておく。
  • MXレコードを登録しなくても違うポートでメールが飛んでくるため、登録しなくても動作は可能だが、分けておく方が無難と思われる(IMO)。
• 実際のところ、メールサーバーを立てるのは大変なため、GoogleやMicrosoft 365などのメールサーバーを使うのが便利(IMO)。
  • 例えば、レジストラでドメイン取得、Route53でDNS設定、SMTPやPOP,IMAPサーバーはGoogle WorkspaceやMicrosoft 365を使う、といったやり方がよくある方法と思われる(IMO)。
    • Route53でDNS設定ができるようにするには、レジストラ側でネームサーバー１〜４をRoute53に向ければよい（つまり委任してもらうということ）。
  • (参考) https://tech.ga-tech.co.jp/entry/value-domain-to-route53
  • (参考) https://www.dondari.com/%E3%81%AF%E3%81%98%E3%82%81%E3%81%A6%E3%81%AERoute_53

サブドメインについて

• (参考) https://help.onamae.com/answer/7889
• 例えば、「onamae.com」という名前でMXレコードを登録していたとしても、xyz.onamae.comには適用されないはず。
  • 逆に、適用されたらまずい気もする。
  • つまり「onamae.com」とは別に「xyz.onamae.com」も登録する必要があるということ。

This site is open source. Improve this page.