はじめに
―― お名前.comでDDNSを利用したいがLinuxからは利用できないため、ドメインごと他のサービスへ移管したかった……。
…が、後述の事情によりドメインの移管が叶わないため、お名前.comでドメインを維持したまま、権威サーバを外部サービス(Cloudflare)へ移管し、外部サービスのネームサーバを利用してLinux環境でDDNSを構成する方法について紹介。
※ お名前.comの特定サービスを利用している場合、ネームサーバを変更すると再設定の必要やサービスが利用できなくなる場合があります。
公式クライアント
お名前.com では「お名前.com ダイナミックDNSクライアント」という名前で、Windows向けにDDNSクライアントが提供されており、動的IP環境でも自動的にドメインのAレコードを最新のIPアドレスに更新する機能が提供されている。
有志がこれの通信仕様を解析し、非公式クライアントとしていくつかLinuxでも利用可能な実装があった。
かくいう私も @miya-masa 氏の実装した miya-masa/onamae-go を利用させていただき、これをカスタマイズした gretchi/onamae-go-on-docker Raspberry Piに構築して使用していた。
API仕様の変更
クライアントのメジャーバージョンアップ(Ver5.0.0.0)を機に、通信仕様が変更され、これらの実装は2024年8月20日を以て利用不可となった。
そもそもは、お名前.comを辞めたかった (爆
私は自宅からインターネットにいくつかサービスを公開しているのだが、特にIP固定契約なんてしていないので、ルータの再起動など、PPセッションが張り直される時々でIPアドレスが変わる。API使用が変更になって以降は都度画面からぽちぽちレコードを更新していたのだがそろそろやってられんくなってきた。
仕様変更は仕方のないことだが、DDNS以前にお名前.comには色々と思うところがあり、そもそも他のサービスにドメインを移管し乗り換えてしまいたかった。
しかし、所有しているドメインのTLDが未対応であることなど条件に合うサービスを見つけられず、仕方なく使い続けざるを得なかった。
移管先検証のさなか……
Google Cloud か Cloudflare 辺りを移管先に検討しているのだが、各サービスの検証中にふと…「（ネームサーバだけでもこっちにすりゃ良くない…？）」と思い立ち、ドメイン移管は最終目標としつつも、移行期間中となるフェーズ「ネームサーバの変更」を設定し、無事DDNS機能も利用できるようになったので、「お名前.comでドメインを維持したまま、ネームサーバを他サービスへ移管し、LinuxでDDNSを利用できるようにする」その過程を共有する。
ちなみに、移行先は Cloudflare DNS に仮決定した。
Google Cloud DNS は、業務で日常的に使っていた経験があり、真新しさがなく、今後も嫌というほど触る機会には恵まれるであろうため、個人のプロジェクトでは相対的に触れる機会の少なさそうな、Cloudflareを利用することにした。
料金
Cloudflare DNS のネームサーバ機能は、無料で利用できるが、これは、まずは使ってもらって…、の導入促進のために無料で提供されていると考えられる。
したがって、2025年6月現在は無料で利用できるが、いずれ料金体系が変更となる可能性もご留意いただきたい。
手順
以下のセクションでお送りする。
- Cloudflare アカウントの作成
- DNSレコードの移行
- ネームサーバの移管
- DDNS(ddclient)の設定
§1. Cloudflare アカウントの作成
アカウントをお持ちでない方は、サインアップページより、アカウントを作成してほしい。
手順は以下のリンクを参考にしてほしい。
§2. DNSレコードの移行
ダッシュボードへログインしたら右上の[＋追加 ]より、「ドメインを接続する」を押下
お名前.com(もしくは他サービス)で取得したドメインを入力、「DNS レコードのクイック スキャン」を選択し、続行
有料機能を使用しない場合はFreeプランを選択
設定済みのDNSレコードの一覧が表示されるので、内容を確認し、アクティベーションへ進む
アクティベーションが完了するとCloudflareのネームサーバが表示されるので、お名前.com Naviへログインし、これを設定していく
§3. ネームサーバの移管
お名前.com Naviへログインし、左のメニューより「ネームサーバー設定」を押下
1.ドメインの選択にて、前章で入力したドメインにチェック、2.ネームサーバーの選択では「その他のサービス」タブより「その他ネームサーバーを使う」を選択、Cloudflare側で取得したネームサーバ２つを入力し「確認」を押下
続いて表示される確認のダイアログで内容を確認の上、「OK」を押下し設定を反映する
確認
反映には通常、数時間〜48時間かかる。(最近では案外すぐに反映されるイメージはあるが…)
いわゆる浸透というのを待つ必要があるためである。
設定が反映されているかを確認するに、 dig コマンドを実行する。
ANSWER SECTION に xxxx.ns.cloudflare.com. のようなCloudflareのNSレコードがあればOK
$ dig NS gretel-net.tokyo
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> NS gretel-net.tokyo
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28851
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 13
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;gretel-net.tokyo. IN NS
;; ANSWER SECTION:
gretel-net.tokyo. 6262 IN NS hasslo.ns.cloudflare.com.
gretel-net.tokyo. 6262 IN NS brenda.ns.cloudflare.com.
;; ADDITIONAL SECTION:
brenda.ns.cloudflare.com. 6262 IN A 108.162.192.77
hasslo.ns.cloudflare.com. 6262 IN AAAA 2a06:98c1:50::ac40:2386
hasslo.ns.cloudflare.com. 6262 IN A 162.159.44.134
brenda.ns.cloudflare.com. 6262 IN AAAA 2803:f800:50::6ca2:c04d
brenda.ns.cloudflare.com. 6262 IN A 172.64.32.77
hasslo.ns.cloudflare.com. 6262 IN A 108.162.195.134
brenda.ns.cloudflare.com. 6262 IN A 173.245.58.77
hasslo.ns.cloudflare.com. 6262 IN AAAA 2803:f800:50::6ca2:c386
hasslo.ns.cloudflare.com. 6262 IN AAAA 2606:4700:58::a29f:2c86
brenda.ns.cloudflare.com. 6262 IN AAAA 2606:4700:50::adf5:3a4d
brenda.ns.cloudflare.com. 6262 IN AAAA 2a06:98c1:50::ac40:204d
hasslo.ns.cloudflare.com. 6262 IN A 172.64.35.134
;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Jun 27 20:33:30 JST 2025
;; MSG SIZE rcvd: 368
§4. DDNS(ddclient)の設定
ここまでの作業で、権威サーバとなるネームサーバがCloudflareへと変更されため、Cloudflareに設定したレコードがこのドメインのレコードに対する全ての親となる。
ここでようやく表題のLinuxでDDNSを回収できる。
手順の確認
DDNSクライアントには ddclient を使用する。
実行環境
M/B: Raspberry Pi 3
OS: Debian 12 (Raspberry Pi OS Lite (64-BIT))
引き続き onamae-go を実行していたラズパイ3に ddclient を構築していく。
アカウント API トークンの取得
サイドバーより、「アカウントの管理」、「アカウント API トークン」を開き、「トークンを作成する」を押下
Cloudflare では、ユーザーに関連付けられていない資格情報を希望される場合、アカウント所有トークンの使用を推奨しています。
レコード設定はアカウントに関連付けられているため、推奨に従いアカウンに紐付くAPIトークンを取得したが、ユーザー API トークンでもDNSレコードの編集は機能した。
テンプレートより「ゾーン DNS を編集する」を選択
権限が、ゾーン, DNS, 編集 であることを確認 (デフォルト)
ゾーン リソース に、編集したいドメインを選択。複数ある場合は、「＋さらに追加する」より適宜追加する。
「概要に進む」を押下し、次の画面にて内容を確認し、「トークンを作成する」を押下
作成したトークンをコピーして控える
画面に書いてある通り、トークンは再表示することはできないので、画面遷移する前に控えよう。また、脅しではないが、API トークンが漏えいした場合は、第三者がDNSレコードを書き換えられる状態となり、なりすましによる犯罪被害など重大なセキュリティリスクとなる。例えプライベートリポジトリであってもホスティングサービスなどへのアップロードは控えよう。
特にGitHubなどは標的型攻撃の対象となりやすく、Gitがリーナス・トーバルズ氏らによって開発された経緯や、オープンソースソフトウェア文化を支えてきたその歴史から一部のソースコードホスティングサービスは他のサービスと比較して操作ミスによってソースコードが公開状態になりやすい特徴があり、万が一ソースコードの漏えいが発生した際などには、それが"何の"キートークンであるかが一目瞭然となるためにより危険性が高い。これはCloudflareのトークンに限らず、情報セキュリティ全般における基本事項として、セキュリティ管理者がいる環境ではその指示に従い、個人で管理する場合は基本的にローカル環境で厳重に管理しよう。クラウドストレージ(Dropbox, Google Drive等)を利用する場合でも、何のキーかが第三者に分からないようファイル名や構造に配慮することが大切である。漏えいが発覚した際には速やかにAPIキーを無効化し、(組織利用に限り)管理者がいる場合には管理者へ報告すること。
また、この場を借りて改めて、リーナス・トーバルズ氏並びにGNUプロジェクトの成果に対し最大限の敬意と感謝を表します。
ddclient の構築
ddclient のインストール
sudo apt install -y ddclient
色々と聞かれるが後で編集するので適当に「OK」や「了解」する
設定
(Recommended) The
ddclient.conffile, which defaults to/etc/ddclient/ddclient.conf.
設定ファイルは /etc/ddclient/ddclient.conf にあるらしいので、ここに設定を記述し実行してみたがエラー。エラーログを見ると /etc/ddclient.conf を参照しに行っているようだ。
WARNING: file /etc/ddclient.conf: Cannot open file '/etc/ddclient.conf'. (No such file or directory)
こちらの記事でも /etc/ddclient.conf に設定しているようだが、理由は Issue #756 に書いてあった。
README.mdsuggests passing--sysconfdir=/etc/ddclientto theconfigurescript when building ddclient, which is how you would get/etc/ddclient/ddclient.conf. The Debian package passes--sysconfdir=/etcinstead, which is why it differs. I'll see if I can get that changed for Debian's v4.0.0 package.
Debianパッケージ版ではビルド時のオプションに /etc/ddclient ではなく、 /etc が渡されており、そのため apt でインストールしたddclientでは /etc/ddclient.conf を参照するようになっているようだ。また、これは将来のアップデートで変更される可能性もあるため、特に長期運用を検討されている方などは、設定ファイル場所がインストール方法やタイミングによって以下のいずれかになることをご留意いただきたい。
/etc/ddclient/ddclient.conf/etc/ddclient.conf
以降は、/etc/ddclient.conf に統一して説明する。
root権限にて以下のファイルを編集する
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf
protocol=Cloudflare \
use=web, web=https://api.ipify.org/ \
zone=example.com \
password='${account_api_token}' \
www.example.com,
example.com と ${account_api_token} は、適宜お持ちのドメインと、先ほど取得したアカウントAPIトークンに読み替えてほしい。
最後の www.example.com, だけ解説しておくと、example.com のサブドメイン www.example.com のAレコードに設定することを指している。
例えば、自宅でWebサーバを立ち上げて、それを外部公開したいときのURLを https://www.example.com/ としたい場合には、www.example.com を、https://example.com/ としたい場合には、example.com を、設定するといった流れだ。例えば Minecraft のゲームサーバを自分のドメインで公開したいときには、サブドメイン minecraft.example.com などが設定可能だ。
基本的な設定は、以上となる。
ddclient の実行に関しては、 cron を使う場合などが紹介されているが、 apt でインストールすればそのまま systemd で管理されるので、特に crontab の設定などは不要であった。やログを見る限りは設定変更後のサービス再起動は不要であった。
$ sudo systemctl status ddclient.service
● ddclient.service - Update dynamic domain name service entries
Loaded: loaded (/lib/systemd/system/ddclient.service; enabled; preset: enabled)
Active: active (running) since Fri 2025-06-20 20:33:26 JST; 1 week 0 days ago
Docs: man:ddclient(8)
Process: 1223 ExecStart=/usr/bin/ddclient -daemon $daemon_interval -syslog -pid /run/ddclient.pid (code=exited, status=0/SUCCESS)
Main PID: 1226 (ddclient - slee)
Tasks: 1 (limit: 760)
CPU: 43min 42.650s
CGroup: /system.slice/ddclient.service
└─1226 "ddclient - sleeping for 280 seconds"
起動間隔とレートリミット
最後に起動間隔とレートリミットについて、 ddclient で叩いているAPIは以下のエンドポイントを5分間隔で叩いている。
-
[PATCH]:/client/v4/zones/$ZONE_ID
レートリミットについては、エンドポイントに関わらずユーザ(アカウント)あたりでカウントされ、1ユーザあたり 1200/5分 (240/分)、同一IPからは 200 request/秒であるため、5分間隔で実行する分には制限は掛からない。(2025年6月現在)
Type Limit Client API per user 1200/5 minutes Client API per IP 200/second GraphQL Varies by query cost. Max 320/5 min User API token quota 50 Account API token quota 500
Rate limits - Cloudflare API より引用
起動間隔の変更
記事を締めくくりに起動間隔の変更手順を記載する。
起動間隔が設定されていそうなファイルはUnitファイルと /etc/default/ddclient のふたつがあるが、後者で設定された内容が優先されるようだ。
/lib/systemd/system/ddclient.service-
/etc/default/ddclient👈これが優先っぽい
# Configuration for ddclient scripts
# generated from debconf on Fri Jun 20 20:33:23 JST 2025
#
# /etc/default/ddclient
# Set to "true" if ddclient should be run every time DHCP client ('dhclient'
# from package isc-dhcp-client) updates the systems IP address.
run_dhclient="false"
# Set to "true" if ddclient should be run every time a new ppp connection is
# established. This might be useful, if you are using dial-on-demand.
run_ipup="false"
# Set the time interval between the updates of the dynamic DNS name in seconds.
# This option only takes effect if the ddclient runs in daemon mode.
daemon_interval="5m"
たとえば、15分間隔に変更したければ daemon_interval="15m" と記述を変更する。設定変更後はサービスを再起動する。
sudo systemctl daemon-reload # Unitファイルを変更した場合
sudo systemctl restart ddclient.service
反映を確認するために daemon_interval="1m" と設定してみたが、どこかしらで5分(300秒)未満での更新を制限するような制御が入っているようであった。しかし、5分間であるならば実用上十分であると考えられる。
Jun 28 03:42:44 gn-pi-01 ddclient[29603]: WARNING: Wait at least 5 minutes between update attempts.
Jun 28 03:43:46 gn-pi-01 ddclient[29609]: SUCCESS: updating a.gn1.gretel-net.tokyo: IPv4 address set to 153.211.16.143
Jun 28 03:44:47 gn-pi-01 ddclient[29613]: WARNING: skipping update of a.gn1.gretel-net.tokyo from <nothing> to 153.211.16.143.
Jun 28 03:44:47 gn-pi-01 ddclient[29613]: WARNING: last updated Sat Jun 28 03:43:44 2025 but last attempt on Sat Jun 28 03:43:44 2025 failed.
Jun 28 03:44:47 gn-pi-01 ddclient[29613]: WARNING: Wait at least 5 minutes between update attempts.
Jun 28 03:45:49 gn-pi-01 ddclient[29620]: SUCCESS: updating a.gn1.gretel-net.tokyo: IPv4 address set to 153.211.16.143
Jun 28 03:46:50 gn-pi-01 ddclient[29624]: WARNING: skipping update of a.gn1.gretel-net.tokyo from <nothing> to 153.211.16.143.
Jun 28 03:46:50 gn-pi-01 ddclient[29624]: WARNING: last updated Sat Jun 28 03:45:47 2025 but last attempt on Sat Jun 28 03:45:47 2025 failed.
Jun 28 03:46:50 gn-pi-01 ddclient[29624]: WARNING: Wait at least 5 minutes between update attempts.
Jun 28 03:47:52 gn-pi-01 ddclient[29630]: SUCCESS: updating a.gn1.gretel-net.tokyo: IPv4 address set to 153.211.16.143
以上
参考