NEC IX / Route 53 DDNS

NEC IXの標準DDNSクライアントからHTTPSでIPアドレスを通知し、AWS LambdaでRoute 53のAまたはAAAAレコードを更新します。AWSアクセスキーをIXに保存する必要はありません。

NEC IX → Function URL または WAF + REST API → Lambda → Route 53
                                              ↕
                                       Secrets Manager（共有トークン）

1レコード（DNS名・種別）ごとに独立したスタック（Lambda・IAMロール・Secrets Manager）として安全に分離デプロイされます。単一レコードの運用でも、複数拠点・複数レコード（IPv4/IPv6併用など）の運用でも、構造化設定ファイル（sites.yaml）を**唯一の定義元（Single Source of Truth）**として一元管理します。

• AWS CLI v2と、対象AWSアカウントへの認証。
• Python 3.14、GNU Make、sh、cfn-guard 3.2.1。WindowsではMSYS2のMakeとshを利用できます。
• 同じAWSアカウントのRoute 53パブリックホストゾーンと、そのゾーンへのドメイン委任。
• IXのWAN接続・ルーティング・DNS名前解決。登録対象はインタフェースに付いたグローバルIPです。CGNAT・DS-Lite・MAP-Eなどの到達性は別途確認してください。

make initでPython仮想環境（.venv）の作成、依存ツールの導入、.envおよびsites.yamlの初期作成をまとめて行えます。

make init

手動で準備する場合は次のように実行します（PowerShellの例）。

python -m venv .venv
.venv/Scripts/python.exe -m pip install -r requirements-dev.txt
Copy-Item .env.example .env
Copy-Item sites.yaml.example sites.yaml

Linux/macOSでは.venv/bin/pythonを使います。cfn-guardは別途用意し、Makefileの既定パス以外に配置した場合はCFN_GUARDで指定してください。

DNSレコード・ホストゾーン・IXインタフェース・ASN制限等のインフラ定義は、すべて sites.yaml に記述します。

# 全サイト共通のデフォルト設定
defaults:
  hosted_zone_id: Z0123456789EXAMPLE
  region: ap-northeast-1
  aws_profile: ""
  record_ttl: 60
  asn_restriction_enabled: false

# サイト・レコードごとの設定一覧
sites:
  # 単一拠点のIPv4更新の例
  tokyo-v4:
    record_name: router.example.com
    record_type: A
    ix_wan_if: GigaEthernet0.1

  # IPv6も更新する場合は別サイトとして定義
  tokyo-v6:
    record_name: router.example.com
    record_type: AAAA
    ix_source_if: GigaEthernet0.1
    ix_notify_if: GigaEthernet1.0

ローカルのAWS実行環境（使用するAWS CLIプロファイルなど）は、必要に応じて .env に設定します。レコード定義を .env に重複して記述する必要はありません。

AWS_PROFILE=my-profile
REGION=ap-northeast-1

定義を検証するには make check または make list を実行します。

# 定義されているサイト一覧と状態を表示
make list

# 設定内容の検証
make check

# 全サイトを一括デプロイ
make deploy

# または特定サイトのみをデプロイ
make deploy SITE=tokyo-v4

設定・テスト・Ruff・CloudFormationスキーマ・安全性ルールの検証後にデプロイします。各サイトの stack_name（既定値: ixddns-<サイト名>）ごとに独立したCloudFormationスタックが作成・更新されます。初回の正常な通知でDNSレコードを作成し、既存レコードがある場合は値とTTLを置き換えます。更新対象はDDNS用の単純なA/AAAAレコードにしてください。

Lambdaの更新権限は、自スタックの指定ホストゾーン・DNS名・レコード種別のUPSERTに限定されています。

# 全サイトのコンフィグを一括生成
make ix-config

# または特定サイトのみ生成
make ix-config SITE=tokyo-v4

デプロイ済みスタックのURLと共有トークンを取得し、examples/nec-ix-ddns-<サイト名>.cfgを生成します。実行するAWS認証にはcloudformation:DescribeStacksと対象シークレットのsecretsmanager:GetSecretValueが必要です。

生成ファイルを確認し、Administrator権限のオペレーションモードからIXへ投入します。グローバルコンフィグモードから投入する場合は先頭のconfigureを省いてください。

• 生成ファイルには平文の共有トークンが含まれます。既定の保存先（examples/*.cfg）はGit除外対象です。ix_config_outputで変更する場合も除外対象のパスを使ってください。再生成時は上書きします。
• サンプルのservice ssl-protocolは他のHTTPSクライアント機能にも影響します。service password-encryptionで暗号化したパスワードは平文表示へ戻せません。
• <IP4>・<IP6>・<PW>はIXが置換するマクロなので、そのまま残してください。

サンプルはIX2000/IX3000のVer.10.11-1.1のマニュアルに基づきます。実機への投入・接続試験は未実施です。IPv4サンプル、IPv6サンプルも参照してください。

生成コンフィグのddns updateで初回通知を行い、show ddns、AWS側のログ、実際のDNSレコードを確認します。確認後、グローバルコンフィグモードでwrite memoryを実行して保存してください。

Resolve-DnsName router.example.com -Type A

IXはサーバから応答があれば成功と判断するため、show ddnsだけではDNS更新の成否を確認できません。 HTTP 200 / acceptedもRoute 53の受理を示すもので、DNSへの反映完了を示しません。DNSキャッシュはTTLまで残る場合があります。

通知は監視対象インタフェースのIP変更から約10秒後、変更がなくてもサンプル設定では1時間ごとに実行します。ddns updateなら即時通知できます。IPが変わらないリンク復旧時の即時通知は、参照資料では確認できません。

# スタック出力（URLやリソースARN等）の確認
make outputs SITE=tokyo-v4

# 共有トークン（半角英数字）のみの取得・表示
make token SITE=tokyo-v4

複数拠点で異なる契約回線（ISP/プロバイダ）を使う場合、拠点ごとに接続元ASNが変わります。 sites.yaml では、サイトごとに allowed_asns を指定することで、「東京拠点は東京の回線ASNからのみ許可、大阪拠点は大阪の回線ASNからのみ許可」 という拠点ごとの厳格なアクセス制御が可能です。

defaults:
  hosted_zone_id: Z0123456789EXAMPLE
  asn_restriction_enabled: true
  asn_restriction_method: static

sites:
  tokyo:
    record_name: tokyo.example.com
    ix_wan_if: GigaEthernet0.1
    allowed_asns: [64496] # 東京拠点のISPのASN

  osaka:
    record_name: osaka.example.com
    ix_wan_if: GigaEthernet0.1
    allowed_asns: [64500, 64501] # 大阪拠点の主回線・予備回線のASN

• allowed_asns はリスト形式 [64496, 64500]、単一値 64496、文字列 "64496,64500" のいずれも指定可能です。
• static 方式での一括デプロイ時（make deploy）、複数拠点で同一のASNが使われていてもビルドキャッシュによりRIPEstatへの重複アクセスを自動抑止します。

手元の設定は sites.yaml 1ファイルで管理しつつ、AWS側はサイトごとに独立したスタック（Lambda・IAMロール・Secrets Manager）として展開されます。 各LambdaのIAMロールは自サイトのレコード名に対する更新権限しか持たないため、万一ある拠点のルータ設定や共有トークンが漏洩しても、他拠点のレコードやドメイン内の別レコードを改ざんされるリスクはありません。

共有トークン認証は全方式で必要です。送信元制限を追加する場合は sites.yaml で次のように設定します。

defaults:
  asn_restriction_enabled: true
  asn_restriction_method: static
  allowed_asns: [64496, 64500]

ASNは例示用です。実際のHTTPS送信回線のASNに置き換えてください。AS接頭辞を付けず、重複や0を含まない1〜100個の整数を指定します。

全方式でLambda・Secrets Manager・CloudWatch Logs・Route 53等の利用料金が発生します。AWS料金、WAF料金、API Gateway料金を確認してください。

ビルド時にRIPEstatから起点CIDRを取得し、Lambdaへ埋め込みます。一覧は.build/asn-prefixes-<サイト名>.jsonにも保存します。取得失敗、空・不正・欠落した経路、48時間より古い観測、テンプレートの容量超過ではビルドを停止し、古い一覧へ自動フォールバックしません。

CIDR一覧は次のデプロイまで更新されません。 経路変更に追従するため定期的にmake deployを実行してください。48時間の検査はビルド時だけで、稼働中のLambdaを停止する期限ではありません。通常はasn_prefixes_fileを空欄にして新しく取得します。取得済みJSONを指定する場合も、ASNの一致と取得・観測から48時間以内であることを検証します。

判定には通信の送信元IPを使い、転送ヘッダーや登録対象のipは使いません。RIPEstatの観測経路はASNの全保有アドレスやWAFの判定との一致を保証せず、広いCIDRに含まれる別ASNの経路や同じASNの他の利用者も許可範囲に入ります。

waf方式はAWS管理のASN判定を使い、CIDR一覧の更新は不要です。送信元IPごとのレート制限も適用します。Function URL方式は予約済み同時実行数（既定1）で流量を抑えますが、送信元ごとの制限や課金上限ではなく、拒否したリクエストにもLambda実行料金がかかります。予約可能な同時実行枠がAWSアカウントに必要です。

waf方式との切り替え、または旧HTTP API構成からFunction URLへの移行では更新URLが変わります。 make deploy後にmake ix-configを再実行してIXへ投入し、更新を確認してください。制限なしとstatic間の切り替えでは同じURLを使います。共有トークンは移行で変更しません。

方式指定がなかった従来のASN制限付き設定は、未指定のままではstaticになります。WAFを維持する場合はasn_restriction_method: wafを明示してください。旧HTTP APIのアクセスログは移行後も残り、不要なら個別に削除します。

窓口はGET /updateで、ipとtokenを各1つ受け付けます。不正なトークン、レコード種別に合わないIP、非グローバルIP、余分なパラメータは拒否します。

Lambdaログのddns_update_accepted、ddns_update_failed、ddns_source_rejectedで確認します。WAFの遮断理由はmake outputsのWafLogGroupを参照してください。APIアクセスログは作成せず、Lambdaログ・メトリクスとWAFログを使います。トークンやクエリ全体はログに記録しません。