"Long-lived token" means API tokens for the management API (creating/
deleting zones, listing them, automating via Terraform-style flows),
not the TSIG keys for actual DNS updates. Every zone on every tier gets
its TSIG key — that's what powers the updates themselves. Free tier
manages zones via the dashboard; paid tiers add API tokens for
programmatic management.
Hi, just wanted to check in again to clarify this a bit. TSIG keys are used for both the api and the direct dns update, this is what authenticates the request and tied to a specific domain. the bearer (long and short) are for the account and is tied to you rather than a specific domain. https://dynip.dev/docs#api-register - you can also list current keys etc for the different domains.
You generate a short-lived token, update, then rotate it. For most home setups, a cron job every 5 minutes with a 10-minute token window is fine. The RFC 2136 path is the real reason to use this instead of the HTTP update protocols most DDNS services use.
"Long-lived token" means API tokens for the management API (creating/ deleting zones, listing them, automating via Terraform-style flows), not the TSIG keys for actual DNS updates. Every zone on every tier gets its TSIG key — that's what powers the updates themselves. Free tier manages zones via the dashboard; paid tiers add API tokens for programmatic management.
That really needs clarification, llms do get that wrong.
Hi, just wanted to check in again to clarify this a bit. TSIG keys are used for both the api and the direct dns update, this is what authenticates the request and tied to a specific domain. the bearer (long and short) are for the account and is tied to you rather than a specific domain. https://dynip.dev/docs#api-register - you can also list current keys etc for the different domains.
https://dynip.dev/docs#authentication
TSIG Keys: Used strictly for updating DNS records (/update). These are 44-character Base64 encoded strings generated per-zone.
JWT Bearer Tokens: Used for account management and programmatic zone registration (/register). Generated upon user login.
Hope this helps to clear it up, I might link the documentation from the pricing section so that at least there is clarification on it.
You generate a short-lived token, update, then rotate it. For most home setups, a cron job every 5 minutes with a 10-minute token window is fine. The RFC 2136 path is the real reason to use this instead of the HTTP update protocols most DDNS services use.