Webブラウザで、YouTubeのWebサイトにアクセスするには、https://www.youtube.com/ のように「ドメイン名」を含むURLをアドレスバーに入力するのが一般的です。

しかし、コンピューターネットワークの通信プロトコルでは「IPアドレス」が分からなければ通信ができません。

YouTubeのWebサーバーは冗長化されているため複数のIPアドレスが存在しますが、例えば 142.250.206.238 がその具体値です。

アクセス先を指す名前としてIPアドレスは憶えにくいことや、アクセス先の冗長化などをしたい場合にはIPアドレスを直接扱わない方が都合が良いため、アクセス先を指す名前として「ドメイン名」という概念が導入されました。

ドメイン名を世界中で利用できるようにするには、「ドメイン名レジストラ」と呼ばれるドメイン名の登録機関を通じて、利用したいドメイン名の利用登録を行う必要があります。

youtube.com でも debiru.net でも、ドメイン名の利用者は「ドメイン名の利用登録」を行うことで、登録している期間だけ「そのドメイン名を利用（管理）できる」という構造になっています。

一定期間の利用登録をしているだけであって、購入しているわけではないのです。

携帯電話を買うことはできても電話番号を買うことができないのと同様です。電話番号の割当事業者と契約している期間だけその番号を占有して利用できますが、契約が切れた途端にその電話番号は自分のものではなくなるのです。

あくまで一時的に利用・取得できるものです。あなたができることは「ドメイン名の登録」であって「ドメイン名の購入」や「ドメイン名の永続的な取得」ができないことに注意しましょう。

「ドメイン名」のことを「ドメイン」と呼ぶ人がいますが、youtube.com のような文字列を「ドメイン」と呼ぶのは誤りです。

「私のTwitter(X)アカウントは debiru_R です」のように言うことがありますが、そのような表現が許容されるのは「実体」と「実体の名称」が同一視できる状況に限られます。

TwitterでIDや名前を変更したときに「Twitterアカウントを変更した」と表現しては意味が通らないでしょう。「TwitterアカウントのID/名前を変更した」と表現するはずです。

特に「ドメイン」に関しては、その実体である「IPアドレスが指す先のサーバー」の管理と実体の名前である「ドメイン名」の管理は独立して行われます。サーバーを契約・設置するときに、ドメイン名をその場で設定して使えるようにするわけではありません。

「ドメイン名」のことを「ドメイン」と呼ぶと混乱が生じるので、区別することを意識しましょう。

文脈によって多少定義が異なることがあるが、ここでは以下のように定義しておく。

上記の事業者は一例です。

• あるドメイン名のDNSレコードを管理するスコープをゾーンと言います。
  • ゾーンでは、そのドメイン名自体と、子孫ドメイン名を管理することができます。
  • debiru.net のゾーンサーバーで debiru.net や www.debiru.net のDNSレコードを設定する、といった具合です。
• net ゾーンで debiru.net とその子孫のDNSレコードを管理することもできますが、実際にはゾーンが分離されています。
  • net ドメイン名の管理者（Verisign）と debiru.net ドメイン名の管理者（私）が異なる。
  • 子ドメイン名までしか関心がない。孫以降の情報は、子（孫の親）に管理を任せたい。
• ゾーンを分離することを「ゾーンカット」と言います。ゾーンカットした場合は、親ゾーンから子ゾーンへ委任（Delegation）をします。委任はNSレコードによって設定されます。

• DNSのゾーンを分離することは、企業において次のように社員を管理することと似ています。
  • 社長は、役員の名前しか知らない。
  • 役員は、本部長の名前しか知らない。
  • 本部長は、配下の部長の名前しか知らない。
  • 部長は、配下の課長の名前しか知らない。
  • 課長は、配下の平社員を全員知っている。
• 数千人、数万人規模の会社でも、このように管理することで各責任者（ゾーン管理者）がきちんとしていれば、全ての社員の情報をきちんと管理できます。
• もちろん、社長や本部長が配下の全ての社員を把握して管理するような体制を採ることも可能です。DNSのゾーン管理はそれと同じように設計できます。

• net ゾーンと debiru.net ゾーンを分離しておきながら、net ゾーンで www.debiru.net の情報を管理することはできません。委任したら、委任先の子孫の情報は扱えないということです。
• 実在するゾーンサーバーは、ドメイン名のラベル毎にゾーンカットされているわけでもありません。例えば jp ゾーンサーバーがあり、u-tokyo.ac.jp ゾーンサーバーがありますが、ac.jp ゾーンサーバーがあるわけではありません。
• ドメイン名の上位のラベル毎にゾーンカットすることもできますが、実際にゾーンカットすべきなのは「管理対象のドメイン名の管理者が、親ゾーンと異なる」という場合が典型的です。
• あるいは、何らかの理由でDNSレコードを管理している権威DNSサーバーを分けたい場合です。例えば debiru.net ゾーンは AWS Route 53 で管理していますが、_acme-challenge.debiru.net ゾーンは自身のWebサーバー上の tinydns で管理しています。
  • ACME（アクミー）は、Automatic Certificate Management Environment（自動証明書管理環境）です。

• DNSSEC
  • DNSを管理・運用する上で、可用性（Availability）を低下させる要因です。
  • DNSSEC はなぜダメなのか - https://www.e-ontap.com/dns/criticism/
• nslookup コマンド
  • いますぐ窓から投げ捨てよう。
  • 再帰クエリと非再帰クエリの違いも理解せずにこんなコマンドを使ってはいけません。
• DNS Propagation Checker という謎ツール
  • こんなツールを使って「浸透」を待つと、期待する結果になるまでに余計に時間がかかる。
  • ネガティブキャッシュについて理解する必要がある。
• 権威/キャッシュ兼用DNSサーバー
  • 歴史的遺産として調べる分にはよいかもしれない。
• グルーレコード
  • In-domain / Sibling domain / In-bailiwick / Out-of-bailiwick あるいは Unrelated ……うっ！頭がッ！

• DNSの浸透待ち
  • DNSレコードの設定後に「DNSの浸透」を待つ人が後を絶たない。
  • これはDNSサービス事業者が始めた嘘・デマが原因。
  • DNSサービス事業者が「DNSレコードの設定変更後は、インターネット全体に情報が浸透するまでに72時間かかります」などとデタラメを言っている。
• DNS伝播待ち・DNS反映待ち
  • 「浸透」を「伝播」や「反映」に置き換えればよいという問題ではない。
  • 待つ必要が生じている時点で何かが間違っていることに気づかなければならない。

• 「浸透と言って何が悪い？」
  • "DNS propagation takes between 24-48 hours to complete" のような文章が散見される。
  • 海外で DNS Propagation と言われているから、その表現が正しいと思うのは危険。
  • 海外でも、日本と同様にDNSを誤解している人が多いだけ。
  • うそはうそであると見抜ける人でないと（DNSを使うのは）難しい
• DNS には "propagation" という専門用語がある
  • プライマリゾーンサーバーのゾーン情報を書き換えた後、セカンダリゾーンサーバーにゾーン情報を転送する処理のことを propagation と言う。
  • これは、何時間も待つ必要があると言われるような "DNS Propagation" とは関係がない。

• 運用中のサイトやメールが2日間使えなくなる
  • 運用中の顧客のドメイン名のNSレコードを無意味に誤って変更してしまうWeb受託制作会社（実話）
  • レジストリ側のNSレコードのTTLが172800（2日間）の場合、復旧に2日間かかる。
• 1日あたり7億7500万0000円の損失（1ドル155円換算）
  • NULL の発明は（40年間で）10億ドルの経済的損失と言われている（Billion Dollar Mistake）
  • DNS の浸透待ちは（40年間で）732億ドルの経済的損失と試算できる（Trillion Dollar Mistake?）
    • 1日あたり25万件のサイトが新設されている。10万件として計算しよう。
    • 10人に1人が浸透待ちをしているとしよう。つまり1日に1万件のサイトで浸透待ちが生じる。
    • 24時間待つ羽目になったとして、作業者の拘束時間（4時間×時給50ドル）とサイト公開遅延による機会損失（300ドル）で1件500ドルの損失。
    • 1日あたり1万件×500ドルで500万ドル。1年で18.3億ドル。40年で732億ドルの損失となる。
    • 少なく見積もってこの値である。浸透待ちをする人の割合は10人に1人よりももっと多いかもしれない。

• ドメイン名の乗っ取り
  • VALUE-DOMAIN に存在していた2種類のドメインハイジャック脆弱性について
  • DNSゾーン管理サービスの脆弱性。第三者が正規ユーザーのドメイン名のDNSレコードを設定できてしまう。
• Lame Delegation
  • 間違ったNSレコードを設定する（あるいは不適切な設定が放置される）ことで、第三者がそのドメイン名のDNSレコードを設定できてしまう状態。
• Dangling A/CNAME / Subdomain Takeover
  • 間違ったA/CNAMEレコードを設定する（あるいは不適切な設定が放置される）ことで、第三者がそのドメイン名の先のコンテンツを乗っ取れる状態。
• ドロップキャッチ
  • ドメイン名を登録して利用した後に、ドメイン名を手放してしまうことで第三者にそのドメイン名を奪われてしまう問題。ドメイン名は安易に新規登録してはいけない。

• 「サーバー移転作業のため、サイトにアクセスできません」
  • ドメイン名の移管なり、NS移転なり、A変更なりが必要であっても、サイトの可用性を落とす必要はない。
  • Webで商売しているのであればダウンタイムが発生するような計画で作業を実施してはいけない。
• DNSの設定変更は待ち時間が発生するという誤解
  • TTLをコントロールする術を知らない人々
  • フルサービスリゾルバーにキャッシュを生成してしまう人々
  • 自分の環境（ISP）でアクセスできるかどうかを判断基準にしている人々
  • ダウンタイムが発生するという案内をする暇があるなら、DNSの仕組みを理解しよう
• ダウンタイムの発生はセキュリティ事故
  • 可用性（Availability）はセキュリティ三大要素の一つ
  • 安易に可用性を落としてはならない。
  • 適切なDNSレコードの設定手順を知る必要がある。

• ドメイン名は信用資産
  • ドメイン名は一度公開・宣伝し利用したら、未来永劫に亘ってそのドメイン名の管理をしなければならない。
• ドメイン名は「プロダクト名」ではなく「ブランド名」にすべし
  • 2025年末に見かけた良くないドメイン名：新作ごとにドメイン名を登録するつもり？
    • https://manosaba.com/ 魔法少女ノ魔女裁判
    • https://hanoura-maze.com/ 配信少女ノ裏垢迷宮
    • 後者は "hanoura.com" が既に取得されていたためか、前者との対応が取れていない。
  • 制作元である Acacia というブランドのドメイン名のサブドメインにすることが望ましい。
    
• Web制作会社がクライアントのドメイン名を登録すべきではない
  • そのドメイン名とコンテンツを永続的に保守し続ける覚悟があるのですか？
  • ドメイン名登録ではなく、サブドメインを使うべき。
  • クライアントの資産はクライアントに管理させましょう。

• DNSレコードの設定ができたかを確認するには
  • 権威DNSサーバーでDNSレコードを設定した後は、手元の端末から権威DNSサーバーに問い合わせる。
  • そのドメイン名にブラウザからアクセスしたり、フルサービスリゾルバーを経由して問い合わせてはいけない。
• ネガティブキャッシュを防ぐ
  • DNSレコードが設定されていない状態でその情報を問い合わせると、「情報がなかった」という結果がキャッシュされてしまう。そのキャッシュの生存時間がどうなるかについてはSOAレコードの仕様を調べてみよう。
• 権威DNSサーバーに直接問い合わせるには
  • 非再帰問い合わせができる dig などのコマンドを用いて、問い合わせ先DNSサーバーの指定と非再帰問い合わせオプションを設定して問い合わせよう。
  • コマンド例： dig _acme-challenge.debiru.net txt @ns.debiru.net +norec

最後にDNSを実践してみましょう。

1. certbot コマンドで「ワイルドカードのドメイン名」に対して証明書を発行する
2. ドメイン名の所有権確認を dns-01 challenge で実行する
3. certbot コマンドの --manual-{auth,cleanup}-hook オプションにシェルファイルを指定して、dns-01 challenge のトークンを権威DNSサーバーのTXTレコードに設定する
4. certbot コマンドの実行を cron で定期実行する

この仕組みを用意することで、自身のWebサーバーで用いているドメイン名に対して、その頂点ドメイン名と直下の全てのサブドメインに有効なWebサーバー証明書を発行することができるようになります。

Ubuntu 24.04 LTS に構築する手順を紹介します。

sudo apt install snapd                # snapd のインストール
sudo snap install --classic certbot   # certbot のインストール
type certbot                          # certbot のパスが通っているかを確認
certbot --version                     # certbot コマンドの動作確認

https://cr.yp.to/djbdns/install.html

https://debiru.hatenablog.com/entry/20220911/tinydns-stops-replying

cd /etc && sudo mkdir _tinydns && cd _tinydns                                # 作業ディレクトリへ移動する
sudo apt install daemontools                                                 # 手順書に daemontools が必要と書かれている

sudo wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz                          # tinydns をダウンロードする
sudo tar xzf djbdns-1.05.tar.gz && cd djbdns-1.05/                           # アーカイブを展開してディレクトリに移動する

sudo sh -c "echo 'gcc -O2 -include /usr/include/errno.h' > conf-cc"          # 手順書に書かれているもの
sudo perl -i -pe "BEGIN{undef $/;} s@-d300000@-d400000@smg" tinydns-conf.c   # メモリの softlimit を上げる

sudo make                                                                    # ビルドを実行する
sudo make setup check                                                        # setup と check を実行する

ls -la /usr/local/bin/ | grep tinydns                                        # tinydns コマンドが生成されたことを確認する

debiru.net というドメイン名は利用したいドメイン名に読み替えてください。

sudo apt install svtools daemontools-run
sudo useradd tinydns && sudo useradd axfrdns && sudo useradd dnslog
sudo tinydns-conf tinydns dnslog /etc/tinydns $(hostname -I | ag -o '\d+\.\d+\.\d+\.\d+')

sudo ln -s /etc/tinydns /etc/service   # サービス起動
sleep 5                                # 数秒待つ
sudo svstat /etc/service/tinydns       # 起動しているかを確認
cd /etc/service/tinydns/root           # root ディレクトリへ移動
sudo emacs data                        # data ファイルを編集

._acme-challenge.debiru.net::ns.debiru.net:60
'_acme-challenge.debiru.net:tinydns-install-succeeded:60

sudo make   # data を基に data.cdb を生成

# 自身の権威DNSサーバーに対して DNS 問い合わせを試す
dig _acme-challenge.debiru.net txt +norec @$(hostname -I | ag -o '\d+\.\d+\.\d+\.\d+')

certbot-auth-hook.sh

#!/bin/sh
DATA_PARENT_DIR="/etc/service/tinydns/root"
DATA_PATH="${DATA_PARENT_DIR}/data"
DOMAIN="_acme-challenge.${CERTBOT_DOMAIN}"         # _acme-challenge.debiru.net のようなドメイン名
TXT_RECORD="'${DOMAIN}:${CERTBOT_VALIDATION}:60"   # '_acme-challenge.debiru.net:xxxxx:60 のようなTXTレコード
echo "${TXT_RECORD}" >> ${DATA_PATH}               # data ファイルに追記する
make -C ${DATA_PARENT_DIR}                         # data から data.cdb を生成する
sleep 1

certbot-cleanup-hook.sh

#!/bin/sh
DATA_PARENT_DIR="/etc/service/tinydns/root"
DATA_PATH="${DATA_PARENT_DIR}/data"
DOMAIN="_acme-challenge.${CERTBOT_DOMAIN}"          # _acme-challenge.debiru.net のようなドメイン名
TARGET_RECORD="'${DOMAIN}:${CERTBOT_VALIDATION}:"   # '_acme-challenge.debiru.net:xxxxx: という文字列
sed -i.bak -e "/${TARGET_RECORD}/d" ${DATA_PATH}    # を含む行を削除する
make -C ${DATA_PARENT_DIR}                          # data から data.cdb を生成する

update_letsencrypt.sh

#!/bin/bash -eu

DOMAIN_APEX_LIST=(                     # 証明書を発行したいドメイン名
    lavoscore.org
    debiru.net
    coeurl.org
)
MAIL_ADDRESS="certbot@lavoscore.org"   # 証明書発行者のメールアドレス

SCRIPT_DIR="/etc/ssl"
AUTH_HOOK_PATH="${SCRIPT_DIR}/certbot-auth-hook.sh"
CLEANUP_HOOK_PATH="${SCRIPT_DIR}/certbot-cleanup-hook.sh"

for DOMAIN_APEX in ${DOMAIN_APEX_LIST[@]}; do   # 指定したドメイン名と、その一段階下のサブドメインに対するワイルドカード証明書を発行する
    certbot certonly --agree-tos --manual --preferred-challenges dns-01 --force-renewal \
        -d "*.${DOMAIN_APEX}" -d "$DOMAIN_APEX" -m "$MAIL_ADDRESS" \
        --manual-auth-hook "$AUTH_HOOK_PATH" --manual-cleanup-hook "$CLEANUP_HOOK_PATH"
done

# Update sslcert (Let's Encrypt)
10 6    1 * *   root    /etc/ssl/update_letsencrypt_and_postprocess.sh

update_letsencrypt_and_postprocess.sh は証明書の発行（更新）に加えて、service apache2 restart のように証明書を利用しているサービスの再起動などを行っているスクリプトです。

Ubuntu で構築したWebサーバー上でワイルドカード証明書を自動発行する手順は https://server.lavoscore.org/#id-20 にも掲載しています。

自分で試してみたければ Linux サーバーでも用意してみてください。
XServer 無料VPS なんかがおすすめです。契約日数が2日間（手動で延長更新可能）ですが無料でVPSを使えます。