Rotation SOP — Dyn (Oracle Dyn) API Key
Mode: operator-assisted Last validated: 2026-04-24 UTC Validation method: read-only-docs Average duration: 6m (variable — depends on Oracle Dyn portal availability) Required role: ops
Applies to: DYN_API_KEY (Dyn Managed DNS API user/customer/password triplet, or the API key issued via DynID for Standard DNS).
Service status caveat: Dyn was acquired by Oracle and many
help.dyn.compages now redirect to a deprecation notice. The login portal athttps://account.dyn.com/entrance/is still operational as of 2026-04-24. Long-term, Oracle is migrating customers to its OCI DNS product. Confirm with Oracle support whether Dyn is still our active DNS path before scheduling rotations. If we have already migrated off Dyn, retire this SOP.
When to run
- Scheduled rotation (cadence: every 180 days — fewer rotations because of platform deprecation uncertainty; do not over-invest)
- Operator-initiated (suspected compromise, off-cycle)
- After incident (employee offboarding)
- IMMEDIATELY after Oracle deprecates the customer's specific Dyn product
Prerequisites
- [ ] Dyn portal access at
https://account.dyn.com/entrance/ - [ ] Customer name + username + current password known (Dyn's auth model is
customer_name / username / passwordfor the Managed DNS REST API) - [ ] Existing credential in Infisical with history
- [ ] Downstream consumer list: anything that calls Dyn for DNS reads or updates
- [ ] Confirmation that we are still using Dyn (vs migrated to OCI DNS or a different DNS provider)
Steps
1. Pre-rotation checks
# Authenticate and get a session token (Managed DNS REST API)
SESSION=$(curl -sS -X POST -H "Content-Type: application/json" \
-d "{\"customer_name\":\"$DYN_CUSTOMER\",\"user_name\":\"$DYN_USER\",\"password\":\"$CURRENT_PASSWORD\"}" \
https://api.dynect.net/REST/Session/ | jq -r '.data.token')
echo "$SESSION" | head -c 16
# Expect: a token string. If the call returns an error, the credential is already invalid.
2. Generate the new credential
There is no programmatic rotation API for the Dyn user password. Portal only.
- Navigate to
https://account.dyn.com/entrance/. - Log in with the current credential.
- Navigate to the user/account management section (path varies by product: Managed DNS vs Standard DNS).
- Locate API User or API Credentials.
- Click Reset Password (or Generate New Key for Standard DNS / DynID API).
- Copy the new credential immediately.
For Standard DNS / DynID:
1. Log in to DynID at https://account.dyn.com/.
2. Navigate to the API Users section.
3. Generate or reset the API key.
3. Validate the new credential
NEW_PASSWORD="..."
SESSION=$(curl -sS -X POST -H "Content-Type: application/json" \
-d "{\"customer_name\":\"$DYN_CUSTOMER\",\"user_name\":\"$DYN_USER\",\"password\":\"$NEW_PASSWORD\"}" \
https://api.dynect.net/REST/Session/ | jq -r '.data.token')
[ -n "$SESSION" ] && [ "$SESSION" != "null" ] && echo "auth ok" || echo "auth FAILED"
# Expect: "auth ok"
# Logout to clean up:
curl -sS -X DELETE -H "Auth-Token: $SESSION" https://api.dynect.net/REST/Session/
4. Store in Infisical
infisical secrets set DYN_PASSWORD="$NEW_PASSWORD" \
--projectId="$INFISICAL_PROJECT_ID" --env=prod
# DYN_CUSTOMER and DYN_USER are stored separately and not rotated unless the user identity changes.
5. Propagate to downstream consumers
| Consumer | How |
|---|---|
| DNS automation app / cron | heroku config:set DYN_PASSWORD="$NEW_PASSWORD" -a <app> |
| Operator local | DM via Slack D0AJ7K184TV |
6. Verify downstream
# Run the consumer's DNS check (read-only) and verify it succeeds with new credentials
heroku run --app <app> python -m scripts.dyn_dns_check
# Expect: no auth errors.
7. Revoke the old credential
The portal's "Reset Password" action already invalidated the old password atomically — no separate revoke step. Confirm:
curl -sS -o /dev/null -w "%{http_code}\n" -X POST -H "Content-Type: application/json" \
-d "{\"customer_name\":\"$DYN_CUSTOMER\",\"user_name\":\"$DYN_USER\",\"password\":\"$OLD_PASSWORD\"}" \
https://api.dynect.net/REST/Session/
# Expect: 401 / 403
If using a separate API key (DynID), explicitly revoke the old key in the portal after verifying the new one works.
8. Audit log entry
action: secret.rotate.completed
actor: <admin_id>
context: {
"secret_name": "DYN_PASSWORD",
"customer": "<customer_name>",
"user": "<user_name>",
"method": "operator-assisted-portal"
}
Rollback
If the password reset replaced the old credential atomically, rollback is not possible — only roll forward by resetting again.
If the new credential is broken at the consumer: 1. Log back into the portal and reset the password again to a fresh value. 2. Repeat steps 4–6.
Vendor doc references
- DynID portal: https://account.dyn.com/
- DynID API users (deprecated page, may still load): https://help.dyn.com/create-api-users-and-keys/
- Managed DNS API (deprecated page): https://help.dyn.com/managed-dns-api-credentials/
- Deprecation notice: http://help.dyn.com/deprecation-notice.html
- Migration: contact Oracle Cloud Infrastructure DNS team
Known gotchas
- Documentation rot. Many
help.dyn.compages redirect to a deprecation notice. Vendor knowledge is degrading; capture screenshots when validating. - Customer name is part of auth. The triplet is
customer_name / user_name / password. All three must be in Infisical (onlypasswordrotates routinely). - Two products, two paths. Managed DNS (REST API at
api.dynect.net) and Standard DNS / DynID (different portal paths). Confirm which one we use before starting. - No grace period. Reset Password is atomic.
- Oracle migration risk. If Oracle deprecates the Dyn product we use, rotation becomes irrelevant and migration takes priority. Surface this in next operator review.
- Logout cleans up sessions. Validation script should DELETE the session token to avoid stale-token clutter.