KyedNS supports the standard DynDNS2 protocol used by routers, ddclient, and other DynDNS clients.

Update IP Address

GET https://kyedns.com/api/v1/nic/update?hostname=HOSTNAME&myip=IP_ADDRESS

Parameter	Required	Description
hostname	Yes	Full hostname (e.g., myserver.dyndns.dk or api.example.com)
myip	No	IP address to set. Omit to use your current IP automatically.

Authentication

Use HTTP Basic Auth:

• Username: the full hostname
• Password: the update token set in the record settings

Response Codes

Response	Meaning
good 1.2.3.4	IP successfully updated
nochg 1.2.3.4	IP unchanged (already set)
badauth	Invalid credentials
nohost	Hostname not found
911	Server error, or the hostname is temporarily disabled on our side — retry later

curl

# Update with auto-detected IP
curl -u "myserver.dyndns.dk:YOUR_TOKEN" \
  "https://kyedns.com/api/v1/nic/update?hostname=myserver.dyndns.dk"

# Update with specific IP
curl -u "myserver.dyndns.dk:YOUR_TOKEN" \
  "https://kyedns.com/api/v1/nic/update?hostname=myserver.dyndns.dk&myip=203.0.113.50"

# Update IPv6
curl -u "myserver.dyndns.dk:YOUR_TOKEN" \
  "https://kyedns.com/api/v1/nic/update?hostname=myserver.dyndns.dk&myip=2001:db8::1"

ddclient

# /etc/ddclient.conf
protocol=dyndns2
use=web, web=https://kyedns.com/ip
ssl=yes
server=kyedns.com
login=myserver.dyndns.dk
password='YOUR_TOKEN'
myserver.dyndns.dk

PowerShell (Windows)

$cred = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("myserver.dyndns.dk:YOUR_TOKEN"))
Invoke-WebRequest -Uri "https://kyedns.com/api/v1/nic/update?hostname=myserver.dyndns.dk" `
  -Headers @{Authorization = "Basic $cred"}

Check your IP

GET https://kyedns.com/ip

Returns your public IP address as plain text. No authentication required.

Alternative update endpoints

These are equivalent to the primary endpoint above and exist for compatibility:

• /api/v1/update?hostname=...&token=...
• /api/v1/domain_update?hostname=...&token=...

Read your hostnames, your domains, and their DNS records as JSON. All endpoints use Bearer token authentication. Find your API token on your Account Settings page.

Authentication

Authorization: Bearer YOUR_API_TOKEN

Endpoints

Method	Path	Returns
GET	/api/v1/me	Account snapshot — user info, zones, and domains in one call
GET	/api/v1/zones	All your free zones with IPs, state, and last check-in time
GET	/api/v1/zones/:id	Single zone including MX and webjump fields
GET	/api/v1/domains	All your domains with serial and nameserver status
GET	/api/v1/domains/:id	Single domain with full nameserver detail
GET	/api/v1/domains/:id/records	DNS records for a domain (active records only)
GET	/api/v1/webhooks	Your webhooks with subscribed events and delivery status

Example

# List all your zones
curl -H "Authorization: Bearer YOUR_API_TOKEN" \
  https://kyedns.com/api/v1/zones

# Get DNS records for a domain (replace 42 with the domain id from /api/v1/domains)
curl -H "Authorization: Bearer YOUR_API_TOKEN" \
  https://kyedns.com/api/v1/domains/42/records

KyedNS speaks the Model Context Protocol, so AI assistants like Claude can manage your DNS for you: add, edit and deploy the records on your domains, check monitoring, and look after your hostnames. The endpoint uses the same Bearer token as the Read API. Every change made this way is marked as such in your activity log, and the Regenerate token button on Account Settings instantly cuts off any client using the old token.

Endpoint

POST https://kyedns.com/mcp  ·  Authorization: Bearer YOUR_API_TOKEN

Connect Claude Code

claude mcp add --transport http kyedns https://kyedns.com/mcp \
  --header "Authorization: Bearer YOUR_API_TOKEN"

Connect Claude Desktop

Claude Desktop connects to remote servers through the mcp-remote bridge (requires Node.js). Add this to claude_desktop_config.json:

{
  "mcpServers": {
    "kyedns": {
      "command": "npx",
      "args": ["mcp-remote", "https://kyedns.com/mcp",
               "--header", "Authorization: Bearer YOUR_API_TOKEN"]
    }
  }
}

Other MCP clients that speak HTTP directly can use the endpoint above with the same Authorization header.

Tools

Domains and records: list_domains, get_domain, list_domain_records, create_domain_record, update_domain_record, delete_domain_record, preview_domain_deploy, deploy_domain, list_dynamic_records.

Account and monitoring: get_account, get_activity, get_block_status, list_monitored_hosts, get_monitored_host, list_webhooks.

Hostnames: list_hostnames, get_hostname, create_hostname, update_hostname, update_hostname_ip, delete_hostname.

Resources: kyedns://domains, kyedns://hostnames, and kyedns://troubleshooting, a checklist the assistant reads when something does not resolve.

Record changes on your domains are staged, exactly as in the dashboard — the assistant runs deploy_domain to publish them. The endpoint serves API clients (CLI and desktop assistants); browser-based MCP clients are not supported yet.

Instead of polling the API, KyedNS can push events to you. Manage them on the Webhooks page: add an HTTPS URL and choose one or more events — ip_change, record_change, health_check_fail, sync_fail.

Delivery format

Each delivery is an HTTP POST with a JSON body:

POST /your/endpoint HTTP/1.1
Content-Type: application/json
X-Webhook-Event: ip_change
X-Webhook-Signature: sha256=<hex>    # only when a secret is set

{
  "event": "ip_change",
  "timestamp": "2026-07-14T12:34:56Z",
  "data": { ...event details... }
}

Verifying signatures

If you set a secret on the webhook, verify each delivery by computing HMAC-SHA256 over the raw request body and comparing it to the X-Webhook-Signature header:

# Ruby example
expected = "sha256=" + OpenSSL::HMAC.hexdigest("SHA256", secret, raw_body)
valid = Rack::Utils.secure_compare(expected, request.headers["X-Webhook-Signature"])

Rules & reliability

• URLs must be HTTPS and publicly reachable — private and internal IP ranges are rejected.
• Any response below HTTP 400 counts as delivered. Timeouts are retried up to 3 times.
• Deliveries time out after 5 seconds; respond fast and process asynchronously. Server errors (5xx) and timeouts are retried.
• After 3 consecutive failed deliveries the webhook is paused and retried with a growing cooldown; a successful delivery resets it.
• Use the Test button on the Webhooks page to send a sample delivery.