- DynIPは、ホームラボ、エッジルーター、インフラチーム向けの動的DNSサービスで、60秒更新と無料ティアを提供
- RFC 2136 TSIG、REST API、UDP/53更新をサポートし、FortiGate、OPNsense、OpenWRT、MikroTikと統合可能
- IPv6をIPv4とともにサポートし、A・AAAAレコードを並行して更新、デュアルスタックとIPv6専用ゾーンの両方に対応
- DNSSECは、署名鍵の生成、親ゾーンへの公開、レコード署名を自動化し、Let’s Encrypt証明書の発行に必要
- BYODにより保有ドメインを接続して動的サブドメインを作成できるが、
ns1.dynip.devとns2.dynip.devへの委任が必要
DynIP概要
- DynIPは、ホームラボ、エッジルーター、インフラチーム向けの動的DNSサービスで、60秒更新、無料ティア、RFC 2136 TSIG、独自ドメイン利用、DNSSECを特徴としている
- ルーターが更新を送信すると、ホスト名が世界中で約60秒以内に正しく名前解決されるよう設計されている
- 60秒TTL、NOTIFYベースの伝播、マルチリージョンのネームサーバーを提供
- 無料登録とドキュメントを提供
DNS標準とルーター統合
- RFC 2136 TSIGをサポートしており、FortiGate、OPNsense、OpenWRT、DNS UPDATE対応ルーターで利用可能
- MikroTikユーザーはネイティブのHTTP API統合を利用可能
- 対応方式には、RFC 2136 TSIG、REST API、UDP/53ネイティブ更新が含まれる
- 設定スニペット画面では、デバイスタイプ、対象IPアドレス、ドメイン、TSIGキーに基づいて設定ブロックを生成し、コピーできる
- 新しいゾーンがネームサーバーに伝播する間、FortiGateのRFC 2136/TSIG更新は待機する必要がある
- cURL、PowerShell、Python、MikroTikなどのHTTP API更新は即座に動作する
IPv6とDNSSEC
- IPv6をIPv4とともにサポートし、AおよびAAAAレコードを並行して更新できる
- デュアルスタック構成とIPv6専用ゾーンの両方をサポート
- Let’s Encrypt証明書を発行するには、そのゾーンでDNSSECが有効化されている必要がある
- DNSSECを有効にすると、署名鍵の生成、親ゾーンへの公開、すべてのDNSレコードの署名が自動で実行される
- DNSSEC設定は一度きりの手順で、その後そのゾーンは継続的に署名済み状態に保たれる
- 想定所要時間は30秒と表示される
クイックスタートとゾーン管理
- クイックスタートは、デバイス名の入力、基本ドメインの選択、Create Zoneのクリックでゾーンを作成する流れ
- 新しいドメインの横にあるSnippetsボタンから設定を取得し、デバイスタイプを選択したうえで、生成された設定ブロックをルーターCLIにコピーする
- IPv4とIPv6は、着信接続を基準に自動検出・更新される
- ゾーン一覧には、ドメインとツール、現在のIP、TSIG Secret、DNSSEC、SSL証明書の状態が表示される
- 各ゾーンでは、ロック状態、スニペット、削除、通知、同期時刻、DNSSECのオン・オフ、SSL証明書のダウンロード・更新・発行を管理できる
独自ドメインの利用
- **Custom Namespaces(BYOD)**機能により、保有ドメインをDynIPに接続し、そのネームスペース配下に動的サブドメインを作成できる
- ネームスペースを有効化するには、ドメインレジストラで2つのNSレコードを両方とも作成する必要がある
- 単一のNS委任は拒否される
- 必要なNSレコードは
ns1.dynip.devとns2.dynip.dev
- 設定検証は、委任が有効な状態か、またはレジストラで必要な対応を確認する流れとして提供される
クイック同期と自動化
- Quick Syncは、選択したゾーンを現在のデバイスの外部IPアドレスに即座に合わせる機能
- 検出されたネットワークIPを表示し、ユーザーが選択したゾーンをまとめて更新できる
- セッショントークンを使って
/registerエンドポイントにPOSTリクエストを送信し、新しいゾーンをプログラムから登録できる
curl -X POST "{{ backendUrl }}/register?subdomain=my-new-router&base_domain={{ baseDomains[0] }}" \
-H "Authorization: Bearer {{ token }}"
- セッショントークンはログアウト時に失効するため、長期的な自動化にはAPIトークンを使う必要がある
- API tokensはPro以上の機能で、監視スクリプト、CIパイプライン、MSP統合などの自動化に利用できる
- APIトークンはログアウトしても失効せず、読み取り専用またはフルアクセス範囲に制限し、いつでも破棄できる
- 新しいAPIトークンは作成時に一度だけ表示されるため、パスワードマネージャーやシークレットストアに保管する必要がある
料金プランとアカウント保護
- 料金プラン画面には、サブスクリプションティア、ステータス、更新日またはアクセス終了日、課金周期、使用中のゾーン数と最大ドメイン数が表示される
- プランがダウングレードされると、最も古い許容数のゾーンだけが有効状態のままとなり、残りのゾーンはロックされてIP更新を受け取れなくなる
- 決済失敗時は、アクセス維持のために支払い方法の更新が必要
- アカウント保護はメール2FAとTOTPをサポートし、TOTPが有効化されるとメール2FAに置き換わる
- TOTP設定は、Google Authenticator、Authy、または好みの2FAアプリでQRコードをスキャンし、コードを検証する手順で構成される
関連リンク
1件のコメント
Hacker Newsの意見
スウェーデンのネットワークエンジニア Daniel で、既存の DDNS サービスは 2010 年代式のネットワークにとどまっていると感じたため、DynIP を作ったとのこと
独自の HTTP 専用更新プロトコル、弱い IPv6 対応、DNSSEC 不在、最新機器への対応不足が繰り返されており、DynIP は RFC 2136 / TSIG 更新を第一級の経路として扱っている
FortiGate generic DDNS と MikroTik
/tool dns-updateは追加クライアントなしで動作し、それ以外の用途向けに HTTP API も提供している権威 DNS サーバーには IPv6 でアクセス可能で、親
.devゾーンには AAAA glue が公開されており、顧客ゾーンは A/AAAA を発行し、IPv6 専用クライアントにも対応している選択されたゾーンではトグルひとつで DNSSEC を有効化でき、サブドメイン委任によって独自ドメインを持ち込める
構成は、公開トラフィックを受けない hidden primary と、スウェーデン・スイスに地理分散された 2 台の secondary が TSIG をローカル検証したうえで primary に転送する方式とのこと
RFC 1918 と CGNAT アドレスもレコードに許可しており、private APN のセルラーフリートが内部 IP を指す安定した公開 DNS ホスト名を使えるようにしている
ghcr.io/33k-org/dynip-updaterという小さな Docker コンテナもあり、スタックは PowerDNS 4.8 authoritative、FastAPI、Postgres、Postfix、Cloudflare、Paddle で、dynip.devで運用中、無料ティアもあるIPv6、DNSSEC、独自ドメイン利用などの機能を提供しており、オープンソースプロジェクトでありながら安定した無料ホスティングサービスも運営している
ドキュメントで見落としただけかもしれないが、こちらには IPv6 prefix delegation のサポートがあり、ISP がルーターに割り当てた IPv6 prefix が変わったときに任意ドメインのネットワーク prefix だけを更新できる
ヨーロッパではこの prefix は固定ではなく、ISP の再接続のたびに変わるため、ホスト部分は維持してネットワーク部分だけ自動更新する機能が有用
例:
/update?myipv6:nas.home.mydomain.tld=2003:e6:bee:affe::/56メール確認リンクを押したときに確認完了や状態表示がまったくなく、かなり分かりづらかった
ログイン状態ではリンクがダッシュボードのホームにリダイレクトされるので、通常のユーザーはパスワード変更ボタンを押した直後にメールを受け取るため、先にログアウトする必要がある
メールに「先にログアウトしてください」と書くか、リンクが現在のセッションを終了してからリセットページを表示するようにすれば、よりスムーズになりそう
ぼんやりと、こういうのはセキュリティ上の禁忌だった記憶がある
ピッチはかなり良さそうだが、今すぐ試す時間はない
ただ、ここのコメントでの説明を読んでいなければ、ランディングページでそのままタブを閉じていたと思う
率直すぎて申し訳ないが、ページがよくある AI っぽい量産型ランディングページ のように見え、実際にそうだという意味ではないものの、説明が良いだけに、もう少し個性を出して差別化するとよさそう
また、プロジェクト専用の Hacker News アカウントは作らないほうがよい
「ユーザー名を会社名やプロジェクト名にしてはいけない。HN を宣伝目的で使っている印象を与え、人として参加していないように見える。実名を使う必要はないが、ブランドではなく人間としてここにいるというシグナルが必要だ。ユーザー名を変更したいなら hn@ycombinator.com にメールしてほしい。」
https://news.ycombinator.com/item?id=22336638
https://news.ycombinator.com/showhn.html も参考になる
今は、自分が分かっていることと分かっていないこと、希望や夢、そしてかなり大きな技術知識の塊がある段階で、デザイン面は得意ではないが、当面は大丈夫だと思っている
Pangram 基準で 100% で、実際、そうしたツールがなくても見分けられる程度なので、ここでもそれを見分けられない人が少なくない状況は暗い
この領域に競争が入ってくるのは歓迎
ただし、安定性や使いやすさをそれほど気にせず自分でホスティングするなら、bind9 も RFC 2136 DNS UPDATE と DNSSEC をサポートしている
自分の構成では自宅ルーターが DNS UPDATE を話せないため、HTTP リクエストを変換する小さな Go 実行ファイルも自作した
FortiGate でいくつかのテストケースを作り、DynIP も当初は内部 DNS の上に FortiGate 専用として単純にコピペして使う形から始まった
Windows や Linux の複数ホストで内部利用できるコード例があり、ホームラボに IoT 機器があるなら Arduino の例もある
Go 実行ファイルを作るのもよい方向なので、
/docs以下の更新を追ってほしいRFC 2136 対応はボーナスポイントを与えたくなるレベルで、external-dns と簡単に連携できます
ここ数年、オンプレミスの Kubernetes と external-dns を、公開ホスト上の最小構成のセルフホスト BIND サーバーと組み合わせて使っています
すでにフリート運用ガイドはあり、Kubernetes パターンは自然な拡張なので、ガイドを書くべきかもしれません
以前は OpenWrt DDNS スクリプトを自作して AWS Route 53 や Cloudflare DNS を更新していて、それで十分解決できていました
その後 Tailscale が登場してからは、DDNS や CGNAT をもう気にしなくなりました
https://dynip.dev/guides/tailscale に、互いにどのように、なぜ共存できるのかを説明したガイドを書いてあります
OpenWrt DDNS スクリプトはキーやシークレットの都合で少し面倒ですが、snippet 機能のおかげで「どう動くんだろう？」と推測しなくて済むので、かなり満足しています
公開サービスには DynIP を使い、自分だけがアクセスすればよいものには Tailscale を使うことで、攻撃対象領域を大きく減らせました
幸い、CGNAT は気にしなくて済みます
登録を試みましたが、確認メール が届きません
登録直後の時点でメールサーバーのログにもそれらしい痕跡はなく、何度か再送をリクエストしましたが、6〜7時間後になっても受信箱には何もありません
無料ティアの認証トークンは 24 時間後に期限切れになるのか気になります
JWT の
expクレームを見たので、移行に時間をかける前にこの点を知っておきたいです要点は、無料ティアが持続可能かどうか です
すべてのゾーンはすべてのティアで独自の TSIG キーを受け取り、実際の更新はそのキーが担当します
無料ティアではダッシュボードでゾーンを管理し、有料ティアではプログラムによる管理のための API トークンが追加で提供されます
したがって認証トークンは API 用 bearer として使うものであり、TSIG はドメインが削除されない限り有効なままです
無料ティアでは 5 つのゾーンが許可され、それぞれ個別の TSIG キーが常時有効なので、何百ものゾーンを作成して更新・削除するような使い方でない限り、支払いは不要です
素晴らしいコメントと質問が多くて感謝しています。数時間、娘を水泳教室に連れて行って戻ってきたところなので、引き続きスレッドを見ます
https://github.com/hickory-dns/hickory-dns のようなものも検討したのか気になります
もちろん、何でもかんでも Rust で作る必要はありませんが
面白そうですし、自宅サーバーから複数のサービスを外部クライアントに提供するために DDNS を使っています
今は NO-IP DDNS を使っていますが、無料ティアはかなり寛大な一方で、Let’s Encrypt のようなものをサポートしていない点が不満です
Cloudflare でドメインを買おうか迷っていますが、DynIP は具体的に何が違うのか気になります
2000年代風の HTTP(S) 専用更新 も良いです
curl/wget/fetchさえあればどこでも動き、必要ならトークンを追加するだけで済みますduckdns もまだこの方式をサポートしているようで、別途クライアントが不要なのでほとんどどこでも動作します
curl/wget/fetchもその通りで、/docsでそれ以外にできる特殊な機能を見ればよいですここでは
curl/wget/fetchだけでなく、より広い機能基盤を扱おうとしています