よくある質問

一般的な家庭やオフィスの回線では、プロバイダから割り当てられるグローバルIPアドレスが再接続などのたびに変わります。そのため、外部から自宅のサーバーやNASにアクセスしようとすると、その都度アドレスを調べ直す必要があります。

ダイナミックDNSは、変わり続けるIPアドレスに「変わらないホスト名」を割り当てる仕組みです。ルーターや常駐ソフトから新しいIPアドレスを通知すると、DNSレコードが自動的に書き換わるため、常に同じホスト名でアクセスできるようになります。

無償でご利用いただけます。

ただし本サービスは無保証で、動作の継続性についても保証はありません。障害や仕様変更で停止することがあるため、業務利用など停止が許されない用途にはお使いにならないでください。

現在は招待制で運用しており、一般公開はしておりません。ご利用には運営者が発行した招待リンクが必要です。

招待リンクからメールアドレスとパスワードを登録し、届いた確認メールのリンクを開くと登録が完了します。

なお、サービス全体の登録者数には上限があり、上限に達している間は新規登録を受け付けできません。

自宅サーバー、NAS、監視カメラ、VPNの接続先など、外部から自宅・オフィスの機器へアクセスする用途を想定しています。

一方で、次の用途は利用規約で禁止しています。

• フィッシングサイトの開設やマルウェアの配布
• 迷惑メール（スパム）の送信や、その踏み台としての利用
• 貸与されたホスト名を第三者へ再貸与・販売する行為

くわしくは利用規約をご確認ください。

また、ログイン機能を持つサービスなど、セキュリティ的に重要な用途には本サービスを利用しないでください。理由は「認証やログイン機能のあるサイトを公開してもいいですか？」をご覧ください。

Public Suffix List とは — .jp や .co.jp のように「ここから下の階層は別々の人が使う」という区切りを集めた一覧で、ブラウザが参照しています。この一覧に載っているドメインの直下どうしは、たとえ文字列が似ていても別のサイトとして扱われ、クッキーを共有できません。

ドメインを共同利用するサービスは、この一覧への登録を申請することで利用者どうしを分離します。

本サービスの貸出ドメイン（hizone.jp / nochg.net）はいずれも未登録のため、ブラウザは各ドメイン全体をひとつのサイトとして扱います。その結果、同じドメインを使う他の利用者のホストとクッキーの領域が共有されてしまいます。

クッキーの領域が共有されるのは同じドメインの中だけです。別の貸出ドメインを使うホストとの間では共有されませんが、いずれのドメインを選んでも「そのドメインの他の利用者とは共有される」点は変わりません。

具体的には、次のようなことが起こり得ます。

• 同じドメインを使う他の利用者のホストから Domain= にそのドメインを指定したクッキーを発行されると、そのクッキーはあなたのホストにも送信されます（セッション固定攻撃の足がかりになります）
• あなたのサイトが発行したクッキーを、同じドメインの別ホストから上書きされる可能性があります
• SameSite=Lax / Strict を指定しても、同じドメイン内のホストどうしは「同一サイト」と判定されるため、防御になりません

ブログや静的な公開ページ、SSH・VPNの接続先といった、ブラウザのクッキーに依存しない用途であれば問題ありません。一方、認証を伴うWebアプリケーション、管理画面、決済に関わるものなどは、ご自身で取得した独自ドメインをお使いください。

やむを得ず利用する場合は、クッキーに __Host- プレフィックスを付ける（ドメインを固定し、他ホストからの上書きを防げます）、VPN やクライアント証明書でアクセス元を限定するなどの対策を検討してください。

貸出ドメインを変えても解決しない点にご注意ください。

ホスト名は 好きなラベル.貸出ドメイン（例: myhome.hizone.jp）の形式になります。貸出ドメインは hizone.jp / nochg.net から登録時に選べます。ラベル部分には次のルールがあります。

• 使える文字は半角英小文字・数字・ハイフン
• 先頭と末尾にハイフンは使えません
• 長さは1〜63文字

大文字で入力した場合は小文字に変換されます。登録は先着順で、すでに他の利用者が使用しているホスト名は登録できません。

ホスト名が重複しているかの判定は貸出ドメインごとに独立しています。同じラベルでも別のドメインであれば登録できます（それぞれが1件のホストとして、登録できるホスト数の枠を消費します）。

すでに登録済みの場合のほか、次に該当するホスト名は登録できないようにしています。

• www・mail・ns など、DNSやメール、電子証明書の発行に必要な名称
• 実在する企業名・サービス名・商標と誤認されるおそれのある名称
• login・payment など、フィッシングに使われやすい名称

なお判定では、ハイフンの有無、数字による文字の置き換え（0 と o、1 と l など）、末尾の連番は同じ名称として扱います。adm1n や www2 のような書き換えでは回避できません。

アカウントごとに登録できるホスト数の上限があります。現在の登録数と残りの空き枠は、ダッシュボードの「ホスト枠の使用状況」で確認できます。

上限に達すると新しいホストを登録できません。追加が必要な場合は運営者へご相談ください。

削除したホスト名は、7日間は再登録できません（ご自身であっても登録できません）。

これは、削除した直後に第三者が同じホスト名を取得し、設定変更の間に合わなかった機器からの通信を受け取ってしまうことを防ぐための措置です。

7日が経過すると、あらためて先着順で登録できるようになります。

DynDNS2 互換の更新APIを用意しています。ホスト詳細画面で更新トークンを発行し、ルーターや常駐ソフトから次のURLへHTTPS でアクセスしてください。

認証はBasic認証で、ユーザー名にFQDN、パスワードに更新トークンを指定します。

curl -u '<FQDN>:<発行したトークン>' \
  'https://<DASH_HOST>/nic/update?hostname=<FQDN>'

<DASH_HOST> は zone.helloidea.io、<FQDN> は登録したホスト名（例: myhome.hizone.jp）に置き換えてください。

myip パラメータを省略した場合は、リクエストの送信元IPアドレスが登録されます。

ホスト詳細画面には、ご自身のFQDNを埋め込んだコマンドがそのまま表示されるので、コピーしてお使いください。

なお、画面上の「現在のIPで更新」ボタンからも、ブラウザのアクセス元IPで手動更新できます。

DynDNS2 互換のため、「DynDNS」「Custom DNS」などに対応したルーターであれば、サーバー名に本サービスのダッシュボードのホスト名、ユーザー名にFQDN、パスワードに更新トークンを設定すれば動作します。

ddclient を使う場合の設定例です。<DASH_HOST> は zone.helloidea.io、<FQDN> は登録したホスト名に置き換えてください。

protocol=dyndns2
use=web, web=https://<DASH_HOST>/nic/checkip
ssl=yes
server=<DASH_HOST>
login=<FQDN>
password='<発行したトークン>'
<FQDN>

ホスト詳細画面に、実際の値を埋め込んだ設定例とコピーボタンを用意しています。

5分から10分程度の間隔をおすすめします。ddclient の既定値（300秒）のままで問題ありません。

サーバー保護のため、同一ホストに対する更新は1分あたり1回までに制限しています。これを超えるリクエストには abuse を返し、更新は行われません。

この間隔を守っていれば、IPアドレスが変わっていない場合でも更新要求自体は受け付けられ、nochg が返ります。定期的に送信し続けても問題ありません。

対応しています。AレコードとAAAAレコードを同時に持たせることもできます。

送信元IPアドレスをそのまま登録する場合は、IPv4で接続すればAレコード、IPv6で接続すればAAAAレコードが更新されます。

明示的に指定したい場合は、myip にIPv4アドレス、myipv6 にIPv6アドレスを渡してください。myip にカンマ区切りで両方を指定することもできます。

トークンは発行時に一度だけ表示され、あとから再表示することはできません。紛失した場合は、ホスト詳細画面から新しいトークンを発行してください。

トークンは用途ごとに分かれています

ホスト1件につき、用途の違う2種類のトークンがあります。

有効なトークンは用途ごとに1つです。同じ用途で新しく発行すると、それまでのトークンは自動的に失効します。一方で、別の用途のトークンは失効しません。証明書取得用トークンを発行しても、ddclient による IP アドレスの更新が止まることはありません。

用途を分けているのは、片方が漏れてももう片方に影響が及ばないようにするためです。証明書取得用トークンで書けるのは検証用の TXT だけで、IP アドレスの向き先を変えることはできません。

再発行と失効

同じホストを複数の機器から更新している場合は、再発行のたびにすべての機器へ新しいトークンを設定し直してください。

漏洩のおそれがある場合は、ホスト詳細画面から速やかに失効させてください。失効したトークンによる更新は、ただちに badauth として拒否されます。

作れます。ホスト詳細ページの「ワイルドカード」を有効にすると、*.myhome.hizone.jp が登録され、ホスト配下のどんな名前でもホストと同じ IP アドレスに解決するようになります。

app.myhome.hizone.jp や nas.myhome.hizone.jp のように好きな名前を使えて、名前ごとの登録は要りません。リバースプロキシ（Caddy / Nginx / Traefik など）を立てて、1つの IP アドレスで複数のサービスを名前で振り分ける使い方を想定しています。

ワイルドカード証明書（*.myhome.hizone.jp）も ACME DNS-01 で取得できます。取得方法は「ワイルドカード証明書を取りたいです」をご覧ください。

注意点 — ホストの孫にあたる名前（例: web.myhome.hizone.jp）のさらに下に TXT や MX、CNAME、SRV、CAA を置くと、DNS の仕様（RFC 4592）により、その名前だけワイルドカードが効かなくなります。

たとえば _acme-challenge.web.myhome.hizone.jp に TXT を置くと、web.myhome.hizone.jp の A / AAAA が返らなくなります。証明書取得の検証用 TXT は取得後に消えるため影響は一時的ですが、サイトの所有権確認のように消さずに残すレコードを置いた場合は、その名前だけ解決しない状態が続きます。

常設のレコードは、ホストの直下（例: _acme-challenge.myhome.hizone.jp）に置けばワイルドカードに影響しません。どうしても孫の名前の下に常設のレコードが必要な場合は、その用途を別のホストとして登録してお使いください。

なお、孫の名前そのものに CNAME を置いた場合（例: web.myhome.hizone.jp を外部のサービスへ転送する）は、その名前だけ CNAME の転送先が優先され、ワイルドカードの IP アドレスは返らなくなります。こちらは転送のために意図して置くレコードなので、そのままで問題ありません。

できます。ただし、更新トークンはホストごとに別々です。1本のトークンで複数のホストを更新することはできません（トークンの発行元と異なるホスト名を指定すると nohost が返ります）。

ホストごとにトークンを発行し、機器側でもホストごとに認証情報を設定してください。

ddclient の場合は、ホスト名の行の直前に、そのホストの login と password を書きます。

protocol=dyndns2
use=web, web=https://<DASH_HOST>/nic/checkip
ssl=yes
server=<DASH_HOST>

login=<FQDN1>
password='<FQDN1のトークン>'
<FQDN1>

login=<FQDN2>
password='<FQDN2のトークン>'
<FQDN2>

<DASH_HOST> は zone.helloidea.io、<FQDN1> <FQDN2> はそれぞれのホスト名に置き換えてください。

ルーターの設定画面では、多くの場合ホスト名を1つしか登録できません。複数のホストを扱う場合は、ddclient のように複数のホストに対応したソフトを常時起動しておくか、ホストごとに更新する機器を分けてください。

更新の間隔制限（1分に1回）はホストごとに判定します。複数のホストを同時に更新しても、互いに影響することはありません。

なお、1つのIPアドレスに複数の名前を割り当てたいだけであれば、ホストを増やすよりもワイルドカードを使うほうが簡単です。詳しくは「ホスト名の下にサブドメイン（app.myhome... など）を作れますか？」をご覧ください。

ホスト詳細ページの「DNSレコード」タブから、次の5種類を登録できます。IP アドレス（A / AAAA）は更新APIが自動で管理するため、ここには含まれません。

置ける名前

登録できるのは、自分のホスト名そのものか、その配下の名前だけです。

• myhome.hizone.jp
• _acme-challenge.myhome.hizone.jp
• _minecraft._tcp.myhome.hizone.jp

配下に付けられるラベルは3段までです（_acme-challenge.web.nas.myhome.hizone.jp まで）。他の利用者のホスト配下や、貸出ドメインそのものには登録できません。

上限

同じ名前と種別に複数の値を置けるのは、ワイルドカード証明書のように同じ名前へ2つの値が必要になる場合があるためです。

反映までの時間

登録・削除はすぐに DNS へ反映されますが、レコードの TTL は 60 秒です。問い合わせ元のキャッシュが切れるまで、最大で1分ほど古い内容が返ることがあります。

なお、ワイルドカード（*.myhome.hizone.jp）を有効にしている場合は、レコードを置く名前によってワイルドカードが効かなくなることがあります。詳しくは「ホスト名の下にサブドメインを作れますか？」をご覧ください。

TXT は任意の文字列を DNS に置くレコードです。主な用途は次の2つです。

サイトの所有権確認 — Google Search Console や Microsoft 365 などが発行する確認用の文字列を、ホスト名そのもの（myhome.hizone.jp）に置きます。確認が終わったあとも消さずに残しておく必要があるサービスが多いので、そのまま置いたままにしてください。

証明書の取得（ACME DNS-01） — _acme-challenge.myhome.hizone.jp に置きます。こちらは ACME クライアントが自動で登録・削除するため、手動での操作は基本的に不要です。設定方法はホスト詳細ページの「証明書の取得」タブをご覧ください。

制限

• 値は 255 バイトまでです（日本語などマルチバイト文字はバイト数で数えます）
• 改行やタブなどの制御文字は使えません
• メール認証に使われる値は登録できません（次の項目で説明します）

255 バイトを超える値を分割して登録することはできません。DNS の仕様上は複数に分けて置けますが、分け方によって受け取り側の解釈が変わる用途があるため、このサービスでは受け付けていません。

CNAME は、ある名前を別のホスト名へ転送するレコードです。GitHub Pages や Cloudflare Pages のような外部サービスに、自分のホスト名でアクセスさせたいときに使います。

たとえば web.myhome.hizone.jp に example.pages.dev を登録すると、web.myhome.hizone.jp へのアクセスが転送先の設定に従って解決されるようになります。

ホスト名そのものには置けません

CNAME を登録できるのは配下の名前だけです。ホスト名そのもの（myhome.hizone.jp）には登録できません。

DNS の仕様（RFC 1034）で、CNAME は同じ名前の他のレコードと共存できないと決まっているためです。ホスト名そのものには更新APIが管理する A / AAAA が載るので、そこに CNAME を置くことはできません。

同じ理由から、すでに他のレコードがある名前にも CNAME は置けません。逆に、CNAME がある名前へ他の種別を追加することもできません。付け替えるときは、先に既存のレコードを削除してください。

転送先のサービスを解約するときの注意

このサービスは転送先のドメインを制限していません。A レコードで任意の IP アドレスを指せるのと同じ範囲の自由度ですが、上記の注意点だけはご自身で管理をお願いします。

受け取れます。MX レコードを登録すると、ユーザー名@myhome.hizone.jp 宛てのメールを、指定したメールサーバへ配送させられます。

値は「優先度 メールサーバ名」の形式です。優先度は 0〜65535 の整数で、小さいほど優先されます。

10 mail.example.com

複数のサーバを並べたい場合は、優先度を変えて複数のレコードを登録してください。

メールを受け取らないことを明示する

そのホスト名でメールを受け取る予定がないなら、次の値を登録しておくと、誤って送られたメールを送信側で早く弾けます（RFC 7505 の Null MX）。

0 .

送信については設定できません

理由は「SPF や DKIM のレコードが登録できないのはなぜですか？」で説明しています。受信だけを開けて送信の認証を開けないのは、貸出ドメイン全体を名乗ったなりすましを防ぐための設計です。

SRV は「このサービスは、どのホスト名の何番ポートで提供しているか」を案内するレコードです。Minecraft サーバや Matrix、XMPP など、対応するクライアントが自動で接続先を見つけられるようになります。

名前の形式が決まっています

SRV のレコード名は、必ず次の形式にしてください（RFC 2782）。

プロトコルの部分に使えるのは _tcp / _udp / _sctp の3つです。たとえば Minecraft なら _minecraft._tcp.myhome.hizone.jp になります。

形式を強制しているのは、クライアントが必ずこの名前で問い合わせるためです。違う形の名前で登録できてしまうと、「登録はできたのに誰も引いてくれない」という状態になります。

値の形式

「優先度 重み ポート ホスト名」の4つを空白で区切ります。優先度・重み・ポートはいずれも 0〜65535 の整数です。

0 5 25565 game.example.com

そのサービスを提供していないことを明示する場合は、次のように書きます。

0 0 0 .

登録できない組み合わせ

CAA は「この名前の証明書を発行してよい認証局（CA）」を宣言するレコードです（RFC 8659）。宣言に反する CA は証明書の発行を拒否するため、意図しない CA からの発行を防げます。

値は「フラグ タグ 値」の形式です。フラグは通常 0（必須扱いにする場合は 128）、タグは次の3つが使えます。

Let's Encrypt だけに絞る場合は、ホスト名そのもの（myhome.hizone.jp）に次の値を登録します。

0 issue "letsencrypt.org"

どの CA にも発行させたくない場合は、値を ; にします。

設定を誤ると証明書が取れなくなります

CAA の影響が及ぶのはあなたのホスト名とその配下だけです。CAA の探索は自分と祖先の名前しか見ないため、貸出ドメインそのものや他の利用者のホスト名には影響しません。だからこそ、この機能を開放しています。

制限

• 値は 255 バイトまでです
• 値に " と \ は使えません
• iodef の通報先は mailto: か https:// で始まる必要があります（平文の http:// は通報内容がそのまま流れるため受け付けません）

メール認証に関わる名前と値は、サービス側で登録を禁止しています。

登録できないもの

名前 — 次の語を含む名前は、位置を問わず登録できません。

_dmarc / _domainkey / _mta-sts / _smtp / _tls

TXT の値 — 次で始まる値は登録できません。

v=spf1 / spf2.0 / v=DKIM1 / v=DMARC1 / v=STS1

理由

貸出ドメイン（hizone.jp / nochg.net）の頂点には、認証を通らないメールを受信側で拒否させる宣言（DMARC の p=reject）を置いてあります。この宣言はサブドメインにも引き継がれるため、あなたのホスト名を差出人にしたメールは受信側で拒否されます。

ところが、ホスト名の配下に自前のメール認証レコードを置けてしまうと、この宣言をホスト名の単位で上書きできてしまいます。そうなると、貸出ドメインの名前を差出人にした「認証を通ってしまうメール」を作れることになり、ドメイン全体が迷惑メールやフィッシングの送信元として扱われます。

影響を受けるのは設定した本人だけではありません。同じドメインを使っている他のすべての利用者が、自分のサイトへのアクセスやメールの到達性ごと巻き添えになります。個人が1人でも悪用すればドメイン全体の信用が落ちるため、コードで固定して封鎖しています（管理画面からも解除できません）。

受信は制限していません

メールの受信は MX レコードで自由に設定できます。「受信は開ける、送信の認証は開けない」という切り分けです。MX は受信先を指定するだけのレコードで、送信側の認証には一切関与しないため、封鎖する必要がありません。

送信用のドメインが必要な場合

ご自身で取得したドメインをお使いください。このサービスが貸し出しているのは、動的な IP アドレスに名前を付けるためのホスト名であり、メールの送信元として使うことは想定していません。

取得できます。Let's Encrypt をはじめとする ACME 対応の認証局から、DNS-01 方式で証明書を取得できます。

ホスト詳細ページの「証明書」タブで証明書取得用トークンを発行し、お使いの ACME クライアントに設定してください。あとはクライアントが _acme-challenge.myhome.hizone.jp の TXT レコードを自動で出し入れし、ホスト名の所有権を証明します。

ポート開放は不要です

DNS-01 は DNS レコードだけで所有権を確認する方式です。HTTP-01 と違って外部から 80番ポートへ到達できる必要がないため、プロバイダに 80番を塞がれている回線でも取得できます。

CNAME の委任も不要です

貸出ドメイン（hizone.jp / nochg.net）の権威DNSは本サービスが持っているため、_acme-challenge を別のサービスへ向ける CNAME の設定は要りません。ホスト名を登録して、証明書取得用トークンを発行するだけで使えます。

ACMEクライアントの設定

入口を2種類用意しています。お使いのクライアントに合うほうを選んでください。

acme.sh の場合:

export ACMEDNS_BASE_URL='https://<DASH_HOST>/acme-dns'
export ACMEDNS_USERNAME='<FQDN>'
export ACMEDNS_PASSWORD='<発行した証明書取得用トークン>'
export ACMEDNS_SUBDOMAIN='<FQDN>'
acme.sh --issue --dns dns_acmedns -d <FQDN>

lego の場合:

export HTTPREQ_ENDPOINT='https://<DASH_HOST>/acme'
export HTTPREQ_USERNAME='<FQDN>'
export HTTPREQ_PASSWORD='<発行した証明書取得用トークン>'
lego --dns httpreq --domains <FQDN> --email you@example.jp run

<DASH_HOST> は zone.helloidea.io、<FQDN> は登録したホスト名（例: myhome.hizone.jp）に置き換えてください。証明書タブには、ご自身の値を埋め込んだコマンドがそのまま表示されます。

取得できます。ワイルドカード証明書は ACME の仕様で DNS-01 方式でしか発行できないため、まさに本サービスの証明書取得機能が必要になる場面です。

コマンドに -d '*.myhome.hizone.jp' のように、アスタリスク付きの名前を足してください。ホスト名そのものと配下の名前を1枚の証明書でまかなう場合は、両方を指定します。

acme.sh --issue --dns dns_acmedns -d <FQDN> -d '*.<FQDN>'

シェルがアスタリスクを展開してしまうため、引用符で囲むのを忘れないでください。

検証用の TXT は2件同時に置かれます

ホスト名そのものとワイルドカードは別々に検証されるため、取得中は _acme-challenge.myhome.hizone.jp という同じ名前に、異なる TXT の値が2件並びます。これは正常な状態です。

「同じ名前 + 種別に置ける値は5件まで」という上限を設けているのは、この使い方を成立させるためです。取得が終われば、検証用の TXT は24時間で自動的に削除されます。

証明書と名前解決は別の設定です

証明書は「その名前を名乗ってよい」ことの証明、DNS のワイルドカードは「その名前がどの IPアドレスに解決するか」の設定です。リバースプロキシで複数のサービスを名前で振り分ける構成では、両方が必要になります。

DNS のワイルドカードを有効にしたときの注意点は、「ホスト名の下にサブドメイン（app.myhome... など）を作れますか？」をご覧ください。孫の名前の下に常設のレコードを置くと、その名前だけワイルドカードが効かなくなります。

上から順に確認してください。

1. トークンを取り違えていませんか

もっとも多い原因です。証明書の取得に使えるのは、ホスト詳細ページの証明書タブで発行したトークンだけです。接続設定タブの更新トークンでは認証を通りません。

ユーザー名にはFQDN（例: myhome.hizone.jp）を指定してください。

なお、認証に関する失敗は理由を問わずすべて同じ応答（401）を返します。実在するホスト名を外部から探り当てられないようにするための仕様のため、「ホスト名が違う」のか「トークンが違う」のかは応答から区別できません。両方を見直してください。

2. 短時間に試しすぎていませんか

また、同一IPアドレスからの認証失敗が10分間に10回を超えると、そのIPアドレスからのアクセスを10分間遮断します。設定を直したうえで、少し待ってから再度お試しください。

設定を詰めている最中は、認証局のステージング環境（Let's Encrypt なら --staging）を使うと、認証局側の発行回数制限も消費せずに済みます。

3. CAA レコードを登録していませんか

4. レコードの上限に達していませんか

1つのホストに置けるレコードは合計20件までです。上限に達していると、検証用の TXT を追加できず失敗します。DNSレコードタブで不要なレコードを整理してください。

_acme-challenge 配下に置けるのは TXT のみで、登録から24時間で自動的に削除されます。ここに常設のレコードを置くことはできないため、サイトの所有権確認などに使う TXT はホスト名そのものへ登録してください。

ダッシュボードの設定画面から「パスワードを変更」を開いてください。認証基盤の専用画面で変更できます。

ダッシュボードの設定画面から変更できます。新しいアドレスを入力して「確認メールを送る」を押してください。

変更は次の手順で確定します。

1. 新しいアドレス宛に確認メールが届きます（リンクの有効期限は30分、1回のみ使用できます）
2. メール内のリンクを開くと変更が確定します（確定にはダッシュボードへのログインが必要です）
3. 現在のアドレス宛にも、申請を受け付けた旨の通知をお送りします

リンクを開くまで登録内容は変更されません。有効期限が切れた場合は、あらためて申請してください。また、他の利用者がすでに使用しているメールアドレスへは変更できません。

ダッシュボードの設定画面から退会できます。

退会すると、登録済みのホスト名、DNSレコード、更新トークン、接続ログはすべて削除され、復旧できません。

なお、使用していたホスト名は7日間の経過後、他の利用者が登録できるようになります。

ログイン画面の「パスワードをお忘れですか？」から再設定できます。

登録しているメールアドレスを入力すると、再設定用のリンクをお送りします。リンクの有効期限は30分です。期限が切れた場合は、あらためて手続きをやり直してください。再設定が完了すると、そのままログインした状態になります。

メールが届かず、画面もエラーにならない場合

入力されたアドレスが登録済みかどうかを外部から判別できないようにするため、登録の有無にかかわらず同じ画面を表示しています。登録の無いアドレスを入力してもエラーは表示されず、メールも届きません。

登録に使った可能性のあるアドレスを順にお試しください。それでも解決しない場合は、利用規約末尾のお問い合わせ窓口までご連絡ください。

パスワードを何度も間違えた場合

パスワードの入力を続けて5回誤ると、そのログイン手続きは中断されます。アカウントが凍結されるわけではないので、ログイン画面を開き直して最初からやり直してください。

次の条件をすべて満たす必要があります。新規登録・パスワードの変更・パスワードの再設定のいずれでも共通です。

加えて、推測されやすい文字列は上の条件を満たしていても登録できません。よく使われるパスワード、キーボードの並び（qwerty など）、単純な繰り返し、名前やサービス名をそのまま使ったものなどが該当します。

記号を必須にしていないのは、覚えにくさから「末尾に記号を1つ足すだけ」のような、かえって弱いパターンを誘発しやすいためです。強度に効くのは長さです。関連のない単語をいくつかつなげるなど、長くて覚えやすいものをおすすめします。

条件を満たしているつもりでも登録できない場合は、推測されやすい文字列と判定されています。単語を1つ増やすか、まったく別の組み合わせに変えてお試しください。

利用規約またはプライバシーポリシーを改定し、あらためて同意をお願いしている状態です。内容をご確認のうえ同意していただくと、ダッシュボードへ進めます。

同意の対象は利用規約とプライバシーポリシーの2つです。改定のたびに毎回表示されるわけではなく、あらためて合意が必要な改定のときだけ表示します（誤字の修正のような変更では表示しません）。

また、改定した瞬間に全員へ表示することもしません。事前の周知期間を設けており、その期間が過ぎるまでは、以前の版に同意した状態のままご利用いただけます。

同意いただけない場合は、同意画面からそのまま退会していただけます。退会すると、登録したすべてのホスト、DNSレコード、トークン、接続ログが直ちに削除され、元に戻すことはできません。

次の順に確認してください。

1. ダッシュボードに現在のIPが表示されているか — 空欄の場合、まだ一度も更新が届いていません。まずは更新の設定を見直してください。
2. 反映を待つ — レコードのTTLは60秒に設定していますが、経路上のキャッシュDNSサーバーによっては反映まで数分かかることがあります。
3. dig や nslookup で確認する — 権威DNSに登録されていれば、ホスト名からIPアドレスが引けます。

ホスト名は引けるのに接続できない場合は、DNSではなくネットワーク側の問題です。まずは登録されているIPアドレスがグローバルIPになっているかを、「更新は成功するのに、外部から接続できません」でご確認ください。

「未接続」は、ホストを登録したあと一度も IP更新が届いていない状態です。この間、DNSレコードは作成されません。

更新用のコマンドを手元で1回実行し、good が返るか確認してみてください。badauth などが返る場合は、認証情報の指定を見直してください。

更新が1件でも成功すると、ステータスは「稼働中」に変わります。

IPアドレスの更新が60日間届かなかったホストは、自動的に停止し、DNSレコードが削除されます。使われていないホスト名を長く占有しないための措置です。

停止のおよそ7日前に、ご登録のメールアドレス宛へ予告のお知らせをお送りします。更新が再開されれば、停止されることはありません。

停止中のホストは、ダッシュボードのホスト詳細画面から再有効化できます。

ただし、停止からさらに30日が経過すると、トークンやログとともに完全に削除され、ホスト名も解放されます。この場合は復旧できません。

更新APIは DynDNS2 互換の応答を返します。主な応答は次のとおりです。

なお、同一IPアドレスからの認証失敗が10分間に10回を超えると、そのIPアドレスからのアクセスを一時的に遮断します。設定を見直したうえで、しばらく待ってから再度お試しください。

本サービスのメールは、用途によって2つのドメインから届きます。どちらも別のドメインなので、あらかじめ両方を受信できるように設定しておくことをおすすめします。

登録やパスワードに関するメールは、ダッシュボードとは別のログイン基盤からお送りするため、送信元のドメインが異なります。別サービスからのメールではありません。

届かない場合は、次の順にご確認ください。

1. 迷惑メールフォルダ — 自動送信のメールは振り分けられることがあります
2. 受信拒否・フィルタの設定 — 上記2つのドメインからのメールを受信できるように設定してください（携帯電話会社のメールをお使いの場合は、ドメイン指定受信の設定が必要なことがあります）
3. アドレスの入力誤り — 登録したアドレスに誤りがないかご確認ください

設定を見直しても届かない場合、そのアドレスへの送信が停止されていることがあります。

以前お送りしたメールが届けられなかったアドレスや、メールを迷惑メールとして報告されたアドレスへは、それ以降の送信を自動的に停止しています。

停止中はダッシュボードに警告を表示しています。設定画面から受け取れるメールアドレスへ変更し、新しいアドレスに届く確認メールのリンクを開くと、送信は自動的に再開されます。

更新APIが good を返し、ダッシュボードにも現在のIPアドレスが表示されている。それでも外部から接続できない場合は、登録されているIPアドレスそのものをご確認ください。

ホスト詳細ページに表示されているアドレスが次の範囲に入っている場合、そのアドレスはインターネットから到達できません。

更新APIが検証するのはアドレスの形式だけで、そこへ到達できるかどうかは判定していません。そのため、これらのアドレスを送っても更新は成功し、good が返ります。

プライベートアドレスが登録される場合

ルーターや常駐ソフトが、WAN側ではなくLAN側のアドレスを送っています。次のいずれかで直ります。

1. myip を指定しない — 省略すると、リクエストの送信元アドレス（＝グローバルIP）が自動的に登録されます。もっとも確実な方法です。
2. ddclient なら use=web にする — 「ルーターやddclientの設定方法を教えてください」の設定例のとおりに書いてください。use=if などでLAN側のインターフェースを見ていると、プライベートアドレスが送られます。
3. 二重ルーターになっていないか確認する — 内側のルーターのWAN側もプライベートアドレスになります。外側のルーターから更新するか、内側をブリッジモードにしてください。

いまのグローバルIPアドレスは https://zone.helloidea.io/nic/checkip で確認できます。認証は不要で、ブラウザで開くとアドレスが1行で返ります。ホスト詳細ページの「現在のIPで更新」ボタンからも、ブラウザのアクセス元アドレスで手動更新できます。

CGNAT の場合

100.64. から始まるアドレスが登録されている場合、プロバイダが**CGNAT（大規模NAT）**を採用しており、グローバルIPアドレスが他の契約者と共有されています。

次のいずれかをご検討ください。

• IPv6 で公開する — IPv6 は CGNAT を経由しないため、AAAAレコードなら到達できることがあります
• プロバイダにグローバルIPアドレスの割り当てを申し込む — 固定IPオプションなど
• 外部の中継を使う — VPN やトンネリングでグローバル側に出口を作る

アドレスが正しい場合

登録されているアドレスがグローバルIPで正しいなら、DNS ではなくネットワーク側の問題です。ルーターのポート開放（ポートフォワード）と、サーバー側のファイアウォールの設定をご確認ください。

更新履歴タブに記録されるのは、IPアドレスが実際に変わった更新とエラーだけです。

ddclient などから5分おきに更新している場合、IPアドレスが変わらない限り応答は nochg になります。したがって、履歴が増えないのは正常な状態です。

更新そのものが届いているかどうかは、ホスト詳細ページの最終確認日時でご確認ください。この日時は nochg のときも更新されるため、更新を送り続けている限り、非アクティブによる停止の対象にはなりません。

nochg を記録しないのは、変化の無い記録でログが埋まり、本当に見たい変更やエラーが埋もれてしまうためです。

保持期間

更新履歴は、記録から90日を過ぎたものから順に削除されます。これより古い記録は参照できません。