DNS完全攻略：ネームサーバー、DDNS、nslookup実践ガイド — ドメイン登録からトラブルシューティングまで

ユーザー入力: www.example.com
     |
DNS Resolution（名前解決）
     |
IPアドレス: 93.184.216.34
     |
サーバーにHTTPリクエスト

          .  (Root)
         / \
      com   org   net   kr   jp  ...   (TLD - Top Level Domain)
       |
    example                             (SLD - Second Level Domain)
     / \
   www  mail  api                       (Subdomain)

[ユーザーPC] -- 再帰的クエリ --> [再帰リゾルバ (ISP/8.8.8.8)]
                                        |
                                  反復的クエリ開始
                                        |
                        +---------------+---------------+
                        v               v               v
                 [Root Server]   [TLD Server]   [Authoritative NS]
                 "comはここ"     "example.com     "IPは93.x.x.x"
                                  はここ"

[ブラウザキャッシュ] -> [OSキャッシュ] -> [再帰リゾルバキャッシュ] -> [各NSのTTL]

Chrome: chrome://net-internals/#dns で確認可能
Windows: ipconfig /displaydns
Linux: systemd-resolve --statistics
macOS: sudo dscacheutil -flushcache

example.com.    3600    IN    A    93.184.216.34
                 ^
              TTL = 3600秒（1時間）

[Primary NS] --ゾーン転送--> [Secondary NS]
  (読み書き)                   (読み取り専用)

  原本ゾーンファイル管理         Primary障害時のバックアップ
  レコード追加/変更/削除         負荷分散の役割

# AXFRテスト（セキュリティ上、外部からはブロックされるべき）
dig @ns1.example.com example.com AXFR

# SOAレコードのSerialで同期状態を確認
dig @ns1.example.com example.com SOA +short
# 2024032301 ns1.example.com. admin.example.com. ...

Q: example.comのIPは？
-> example.comのネームサーバーはns1.example.com
-> ns1.example.comのIPは？
-> example.comのネームサーバーに聞く必要があるが...
-> 循環参照発生！

;; .com TLDサーバーの委任レコード
example.com.    IN    NS    ns1.example.com.
example.com.    IN    NS    ns2.example.com.

;; グルーレコード（Additional Section）
ns1.example.com.    IN    A    203.0.113.1
ns2.example.com.    IN    A    203.0.113.2

# CoreDNS Corefile例
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}

# Podからサービスへのアクセス
my-service                          -> my-service.default.svc.cluster.local
my-service.other-ns                 -> my-service.other-ns.svc.cluster.local
my-service.other-ns.svc.cluster.local -> 完全なFQDN

# Podの/etc/resolv.conf
nameserver 10.96.0.10          # CoreDNS ClusterIP
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5                # ドット(.)5個未満ならsearchドメインを追加

# OK - サブドメインにCNAME
www.example.com.    IN    CNAME    example.com.

# NG - ルートドメイン（Apex）にCNAME使用不可！
# example.com.       IN    CNAME    other.com.    (RFC違反)

# 解決策: ALIAS/ANAME（非標準）またはCloudflareのCNAME Flattening

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100"

$TTL 3600
$ORIGIN example.com.

@       IN  SOA   ns1.example.com. admin.example.com. (
                  2026032301  ; Serial (YYYYMMDDNN)
                  3600        ; Refresh（1時間）
                  900         ; Retry（15分）
                  1209600     ; Expire（2週間）
                  86400       ; Minimum TTL（1日）
                  )

; ネームサーバー
@       IN  NS    ns1.example.com.
@       IN  NS    ns2.example.com.

; Aレコード
@       IN  A     203.0.113.10
www     IN  A     203.0.113.10
api     IN  A     203.0.113.20

; AAAAレコード
@       IN  AAAA  2001:db8::10

; CNAME
blog    IN  CNAME example.github.io.
docs    IN  CNAME readthedocs.io.

; MXレコード（数値が小さいほど優先度が高い）
@       IN  MX    10 mail.example.com.
@       IN  MX    20 mail2.example.com.
mail    IN  A     203.0.113.30

; TXTレコード
@       IN  TXT   "v=spf1 include:_spf.google.com -all"
_dmarc  IN  TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

; SRVレコード
_sip._tcp  IN  SRV  10 60 5060 sip.example.com.

; CAAレコード
@       IN  CAA   0 issue "letsencrypt.org"
@       IN  CAA   0 issuewild "letsencrypt.org"

[ICANN] --管理--> [レジストリ] --委任--> [レジストラ] --販売--> [リセラー]
                  (Verisignなど)        (お名前.com等)          (ホスティング業者等)

レジストリ（Registry）: TLD全体を管理（例：.comはVerisign）
レジストラ（Registrar）: ICANNの認定を受けてドメイン登録を代行
リセラー（Reseller）: レジストラの再販パートナー

1. 現在のレジストラでTransfer Lock（ドメインロック）を解除
2. Auth Code（認証コード / EPPコード）を取得
3. 新しいレジストラでTransfer申請 + Auth Code入力
4. 旧レジストラからの承認メール確認（5～7日待機）
5. 移管完了後、DNS設定を確認

注意事項：
- 登録/移管後60日間は再移管不可（ICANN 60-Day Lock）
- 有効期限15日以内のドメインは移管不可
- .jpドメインはJPRS規定による別途手続き

# Whois検索
whois example.com

# RDAP（Whois後継、JSONベース）
curl -s "https://rdap.verisign.com/com/v1/domain/example.com" | jq .

問題：
  自宅サーバーIP: 211.xxx.xxx.100（昨日）
  自宅サーバーIP: 211.xxx.xxx.200（今日） <- IP変更！

  DNS: myserver.example.com -> 211.xxx.xxx.100（昨日登録）
  -> 接続不可！

解決（DDNS）：
  IP変更検知 -> 自動的にDNSレコード更新
  myserver.example.com -> 211.xxx.xxx.200（自動更新）

# インストール
sudo apt install ddclient

# /etc/ddclient.conf設定（Cloudflare例）
protocol=cloudflare
use=web, web=https://api.ipify.org
zone=example.com
login=your-email@example.com
password=your-cloudflare-api-token
myserver.example.com

# サービス開始
sudo systemctl enable ddclient
sudo systemctl start ddclient

# 状態確認
sudo systemctl status ddclient
sudo ddclient -query

#!/bin/bash
# cloudflare-ddns.sh

# 設定
CF_API_TOKEN="your-api-token-here"
CF_ZONE_ID="your-zone-id-here"
CF_RECORD_NAME="myserver.example.com"
CF_RECORD_ID="your-record-id-here"

# 現在のグローバルIPを確認
CURRENT_IP=$(curl -s https://api.ipify.org)

# DNSに登録されているIPを確認
DNS_IP=$(dig +short "$CF_RECORD_NAME" @1.1.1.1)

# IPが変更されていれば更新
if [ "$CURRENT_IP" != "$DNS_IP" ]; then
    echo "IP changed: $DNS_IP -> $CURRENT_IP"

    curl -s -X PUT \
        "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/dns_records/$CF_RECORD_ID" \
        -H "Authorization: Bearer $CF_API_TOKEN" \
        -H "Content-Type: application/json" \
        --data "{\"type\":\"A\",\"name\":\"$CF_RECORD_NAME\",\"content\":\"$CURRENT_IP\",\"ttl\":60,\"proxied\":false}"

    echo "DNS updated successfully"
else
    echo "IP unchanged: $CURRENT_IP"
fi

# crontabに登録（5分ごとに実行）
crontab -e
# */5 * * * * /home/user/cloudflare-ddns.sh >> /var/log/ddns.log 2>&1

# docker-compose.yml
version: '3'
services:
  cloudflare-ddns:
    image: oznu/cloudflare-ddns:latest
    restart: always
    environment:
      - API_KEY=your-cloudflare-api-token
      - ZONE=example.com
      - SUBDOMAIN=myserver
      - PROXIED=false
      - RRTYPE=A
      - DELETE_ON_STOP=false
      - DNS_SERVER=1.1.1.1

docker-compose up -d

[インターネット] -> [ルーターポートフォワーディング] -> [Nginx Proxy Manager] -> [サービス]
                                                            |
                                                      Let's Encrypt
                                                      自動SSL発行

# docker-compose.yml - 自宅サーバースタック
version: '3'
services:
  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81' # 管理パネル
    volumes:
      - ./npm-data:/data
      - ./npm-letsencrypt:/etc/letsencrypt

  cloudflare-ddns:
    image: oznu/cloudflare-ddns:latest
    restart: always
    environment:
      - API_KEY=your-cf-token
      - ZONE=example.com
      - SUBDOMAIN=home

ルーター設定：
  外部 80 -> 内部 192.168.1.100:80
  外部 443 -> 内部 192.168.1.100:443

Linux ファイアウォール（UFW）：
  sudo ufw allow 80/tcp
  sudo ufw allow 443/tcp
  sudo ufw enable

# 基本検索
nslookup example.com
# Server:  8.8.8.8
# Address: 8.8.8.8#53
#
# Non-authoritative answer:
# Name:    example.com
# Address: 93.184.216.34

# 特定のDNSサーバーで検索
nslookup example.com 1.1.1.1

# MXレコード（メールサーバー）
nslookup -type=mx gmail.com
# gmail.com  mail exchanger = 5 gmail-smtp-in.l.google.com.
# gmail.com  mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.

# AAAAレコード（IPv6）
nslookup -type=aaaa google.com

# TXTレコード（SPF, DKIMなど）
nslookup -type=txt example.com

# NSレコード（ネームサーバー）
nslookup -type=ns example.com

# SOAレコード（ゾーン情報）
nslookup -type=soa example.com

# CAAレコード（証明書発行権限）
nslookup -type=caa example.com

# SRVレコード（サービスの場所）
nslookup -type=srv _sip._tcp.example.com

# ANY（すべてのレコード - 一部サーバーはブロック）
nslookup -type=any example.com

nslookup
> server 8.8.8.8          # DNSサーバー変更
> set type=mx              # レコードタイプ設定
> gmail.com                # 検索
> set type=txt
> example.com
> set debug                # デバッグモードON
> example.com              # 詳細情報出力
> set d2                   # さらに詳細なデバッグ
> exit

# IP -> ドメイン検索
nslookup 8.8.8.8
# 8.8.8.8.in-addr.arpa  name = dns.google.

nslookup 1.1.1.1
# 1.1.1.1.in-addr.arpa  name = one.one.one.one.

# 1. ドメインのネームサーバーを確認
nslookup -type=ns example.com

# 2. メールサーバーを確認（メール問題のデバッグ）
nslookup -type=mx company.com

# 3. SPFレコードを確認（メールスパム問題）
nslookup -type=txt example.com

# 4. Google DNS vs Cloudflare DNS比較
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

# 5. IPv6アドレスを確認
nslookup -type=aaaa facebook.com

# 6. ワイルドカードサブドメインをテスト
nslookup nonexistent-sub.example.com

# 7. CAAレコードを確認（SSL証明書発行前）
nslookup -type=caa example.com

# 8. 逆引きDNS確認（IP所有者の特定）
nslookup 203.0.113.1

# 9. CNAMEチェーンを追跡
nslookup -type=cname www.example.com

# 10. SOAレコードでDNS管理者を確認
nslookup -type=soa example.com

# 基本検索
dig example.com

# 出力構造：
# ;; QUESTION SECTION:    <- 質問
# ;example.com.           IN  A
#
# ;; ANSWER SECTION:      <- 回答
# example.com.      3600  IN  A  93.184.216.34
#
# ;; AUTHORITY SECTION:   <- 権威ネームサーバー
# example.com.      3600  IN  NS  a.iana-servers.net.
#
# ;; ADDITIONAL SECTION:  <- 追加情報
# a.iana-servers.net. 3600 IN  A  199.43.135.53
#
# ;; Query time: 23 msec
# ;; SERVER: 8.8.8.8#53(8.8.8.8)

# 短い出力（IPのみ）
dig +short example.com
# 93.184.216.34

# 特定のレコードタイプ
dig example.com MX
dig example.com AAAA
dig example.com TXT
dig example.com NS
dig example.com SOA
dig example.com CAA

# DNSサーバーを指定
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# 応答時間のみ確認
dig example.com | grep "Query time"
# ;; Query time: 23 msec

# Rootから全DNS解決プロセスをトレース
dig +trace example.com

# 出力（要約）：
# .                   518400  IN  NS  a.root-servers.net.  <- Root
# com.                172800  IN  NS  a.gtld-servers.net.  <- TLD
# example.com.         86400  IN  NS  a.iana-servers.net.  <- Authoritative
# example.com.          3600  IN  A   93.184.216.34        <- 最終回答

# DNSSEC署名情報を確認
dig +dnssec example.com

# DNSSEC有効性の検証
dig +sigchase +trusted-key=/etc/trusted-key.key example.com

# DNSSEC関連レコードを直接検索
dig example.com DNSKEY
dig example.com DS
dig example.com RRSIG
dig example.com NSEC

# ファイルのすべてのドメインを一括検索
cat domains.txt
# example.com
# google.com
# github.com

dig -f domains.txt +short

# 特定レコードタイプでバッチ検索
dig -f domains.txt MX +short

# TCPモードで検索（UDP代わり）
dig +tcp example.com

# 特定セクションのみ出力
dig +noall +answer example.com    # 回答のみ
dig +noall +authority example.com  # 権限セクションのみ
dig +noall +stats example.com     # 統計のみ

# TTL付き省略出力
dig +nocmd +noall +answer +ttlid example.com

# 逆引き検索
dig -x 8.8.8.8
# 8.8.8.8.in-addr.arpa.  IN  PTR  dns.google.

# CHAOSクラスでDNSサーバーバージョンを確認
dig @ns1.example.com version.bind CHAOS TXT

# EDNS Client Subnetテスト
dig +subnet=203.0.113.0/24 example.com @8.8.8.8

# 1. 特定ネームサーバーから権威ある応答を確認
dig @ns1.example.com example.com +norecurse

# 2. DNS伝播確認（複数DNSサーバーを比較）
for dns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo "=== $dns ==="
  dig @$dns example.com +short
done

# 3. CNAMEチェーン全体をトレース
dig +trace +nodnssec www.example.com CNAME

# 4. MXレコードの優先順位を確認
dig example.com MX +short | sort -n

# 5. SPFレコードを確認
dig example.com TXT +short | grep spf

# 6. DKIMレコードを確認
dig selector1._domainkey.example.com TXT +short

# 7. DMARCポリシーを確認
dig _dmarc.example.com TXT +short

# 8. CAAレコードを確認（SSL発行前）
dig example.com CAA +short

# 9. SOAのシリアル番号を確認（ゾーン転送の同期）
dig example.com SOA +short

# 10. 応答時間を比較（DNSパフォーマンステスト）
for i in $(seq 1 10); do
  dig example.com @8.8.8.8 | grep "Query time"
done

# 11. IPv6レコードを確認
dig example.com AAAA +short

# 12. ワイルドカードDNSを確認
dig random-subdomain.example.com +short

# 13. NSEC/NSEC3でDNSSEC認証された不存在証明
dig nonexistent.example.com NSEC

# 14. DNS応答サイズを確認（DDoS増幅テスト）
dig example.com ANY +bufsize=4096

# 15. 全ゾーンエクスポートを試行（セキュリティ監査）
dig @ns1.example.com example.com AXFR

正常: リゾルバ -> Authoritative NS -> 正確なIP
攻撃: 攻撃者が偽の応答をリゾルバキャッシュに注入
結果: ユーザーがフィッシングサイトに誘導される

防御: DNSSEC、ランダムソースポート、0x20エンコーディング

攻撃方式：
1. 攻撃者がソースIPを被害者のIPに偽装（IP Spoofing）
2. オープンリゾルバに大きな応答を生成するクエリを送信（ANYタイプ）
3. 小さなクエリ -> 大きな応答 = 増幅効果（50～70倍）
4. すべての応答が被害者に集中

防御: BCP38（ソースアドレス検証）、RRL（Response Rate Limiting）

方法1: ルーター/ISPレベルでDNS応答を改ざん
方法2: レジストラアカウントを乗っ取り -> ネームサーバー変更
方法3: マルウェアがシステムDNS設定を変更

防御: DNSSEC、レジストラアカウント2FA、DNS監視

目的: DNSプロトコルを悪用してデータ漏洩/リモート制御
方式: DNSクエリ/応答にエンコードされたデータを隠す

例: malicious-data.encoded.evil.com にTXTクエリ
-> ファイアウォールは正常なDNSトラフィックと認識

防御: DNSクエリ長/頻度の監視、DNSファイアウォール

信頼の連鎖（Chain of Trust）：
  Root (.) -> .com -> example.com

  各レベルで：
  1. DNSKEY: ゾーンの公開鍵
  2. RRSIG: 各レコードの電子署名
  3. DS: 子ゾーンの公開鍵ハッシュ（親ゾーンに保存）
  4. NSEC/NSEC3: 「この名前は存在しない」の証明

# DNSSEC検証を確認
dig +dnssec example.com

# 応答に'ad'フラグがあればDNSSEC検証成功
# flags: qr rd ra ad; QUERY: 1, ANSWER: 2

# DNSKEYを検索
dig example.com DNSKEY +short

# DSレコードを検索（親ゾーンから）
dig example.com DS +short

# DoHでDNS検索（curl）
curl -s -H "accept: application/dns-json" \
  "https://1.1.1.1/dns-query?name=example.com&type=A" | jq .

# DoHサービス
# Cloudflare: https://1.1.1.1/dns-query
# Google: https://dns.google/dns-query
# Quad9: https://dns.quad9.net/dns-query

# DoTテスト（kdig使用）
kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com

[デバイス] -> [DNSフィルター] -> [許可されたクエリのみ通過] -> [インターネット]
                 |
           広告/悪意あるドメインをブロック
           トラッカーをブロック
           成人コンテンツフィルタリング

RPZ（Response Policy Zone）：
  DNSファイアウォールで特定ドメインの応答を上書きする技術

例（BIND RPZ）：
; rpz.db
evil-domain.com        CNAME  .           ; NXDOMAIN応答
malware-c2.com         CNAME  .           ; ブロック
phishing-site.com      A      10.0.0.1    ; 警告ページにリダイレクト

# 診断
# 1. 権威ネームサーバーから直接確認（これが成功すれば設定は正常）
dig @ns1.your-dns-provider.com yourdomain.com A +short

# 2. 複数のパブリックDNSで伝播状態を確認
dig @8.8.8.8 yourdomain.com +short
dig @1.1.1.1 yourdomain.com +short
dig @9.9.9.9 yourdomain.com +short

# 3. オンラインツールで全世界の伝播を確認
# https://www.whatsmydns.net/

# 診断: CAAレコードを確認
dig yourdomain.com CAA +short
# 0 issue "digicert.com"   <- Let's Encryptが許可リストにない！

# 解決: CAAレコードを追加または修正
# yourdomain.com. IN CAA 0 issue "letsencrypt.org"
# yourdomain.com. IN CAA 0 issuewild "letsencrypt.org"

# CAAレコードがなければすべてのCAが発行可能（デフォルト）
dig yourdomain.com CAA +short
# （空の応答 = 制限なし）

# 診断1: SPFレコードを確認
dig yourdomain.com TXT +short | grep spf
# "v=spf1 include:_spf.google.com -all"

# 診断2: DKIMレコードを確認（selectorはメールヘッダーで確認）
dig google._domainkey.yourdomain.com TXT +short

# 診断3: DMARCポリシーを確認
dig _dmarc.yourdomain.com TXT +short
# "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

# 解決チェックリスト：
# 1. SPFにメール送信サーバーのIP/ドメインが含まれているか確認
# 2. DKIM署名キーの登録を確認
# 3. DMARCポリシーを設定（最初はp=noneで監視）
# 4. DMARCレポートを分析後、p=quarantine -> p=reject の順で強化

# 診断: サブドメインのレコードが存在するか確認
dig staging.example.com A +short
# （空の応答 = レコードなし）

dig api.example.com A +short
# 203.0.113.20（正常）

# ワイルドカードレコードを確認
dig *.example.com A +short

# 診断: 各DNSサーバーのキャッシュ状態を確認
dig @8.8.8.8 example.com +short    # Google DNS
dig @1.1.1.1 example.com +short    # Cloudflare DNS
dig @9.9.9.9 example.com +short    # Quad9

# TTLを確認
dig example.com | grep -A1 "ANSWER SECTION"
# example.com.  1800  IN  A  203.0.113.10
#                ^ 残りTTLがまだ高い

# 診断1: hostsファイルを確認
cat /etc/hosts          # Linux/macOS
type C:\Windows\System32\drivers\etc\hosts  # Windows

# 診断2: ブラウザDNSキャッシュを確認
# Chrome: chrome://net-internals/#dns -> Clear host cache

# 診断3: HSTS問題を確認
# Chrome: chrome://net-internals/#hsts
# ドメインを削除して再試行

# 診断4: プロキシ/VPN設定を確認
# ブラウザのプロキシ設定がDNSをバイパスする可能性

# 診断5: DNS over HTTPS設定を確認
# Chrome設定 -> プライバシーとセキュリティ -> セキュアDNSを使用

# 診断: 現在のネームサーバーを確認
dig example.com NS +short
# 旧レジストラのネームサーバーが見えれば、まだ更新されていない

# 解決手順：
# 1. 新しいレジストラでDNSレコードを先に設定
# 2. 移管前にすべてのレコードを新しい場所に複製
# 3. ネームサーバーを変更
# 4. 旧ネームサーバーは最低48時間維持

# 診断1: Pod内からDNS解決をテスト
kubectl exec -it debug-pod -- nslookup api.external.com

# 診断2: resolv.confを確認
kubectl exec -it debug-pod -- cat /etc/resolv.conf
# nameserver 10.96.0.10
# search default.svc.cluster.local svc.cluster.local cluster.local
# options ndots:5

# 診断3: CoreDNSログを確認
kubectl logs -n kube-system -l k8s-app=kube-dns

# 問題: ndots:5のため、api.external.com（ドット2個）は
# api.external.com.default.svc.cluster.local等を先に試行

# 方法1: FQDNを使用（末尾にドットを追加）
# コードで api.external.com. と呼び出す

# 方法2: PodのdnsConfigを設定
apiVersion: v1
kind: Pod
spec:
  dnsConfig:
    options:
      - name: ndots
        value: '2'

# 診断: プロキシされていないレコードを確認
# Cloudflareダッシュボードでオレンジ色の雲（プロキシ有効）ではなく
# 灰色の雲（DNS Only）のレコードがないか確認

# サブドメインスキャンで漏洩を確認
dig direct.example.com +short     # オリジンIP漏洩？
dig mail.example.com +short       # MX用AレコードにオリジンIP？
dig ftp.example.com +short        # FTPサブドメインにオリジンIP？

# 診断1: 現在のグローバルIPを確認
curl -s https://api.ipify.org

# 診断2: DNSに登録されているIPを確認
dig myserver.example.com +short

# 診断3: DDNSクライアントのログを確認
sudo journalctl -u ddclient -n 50

# 診断4: APIトークンの有効性を確認
curl -s -X GET "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  -H "Authorization: Bearer YOUR_TOKEN" | jq .

# 一般的な原因：
# 1. APIトークンの期限切れまたは権限不足
# 2. Zone IDまたはRecord IDの誤り
# 3. ファイアウォールがDDNSクライアントの外部通信をブロック
# 4. cronジョブが無効化されている
# 5. IP確認サービス（ipifyなど）にアクセスできない