This recipe refers to the existing regfish DynDNS product and not to the regfish DNS API. The service updates hostnames through regfish DynDNS endpoints, so you can use custom updaters, router integrations, or small homeserver scripts without direct DNS API access.

The core flow is always the same: you enable DynDNS for a domain in the Regfish domain management UI, receive a personal token, and then send updates through GET or POST requests to https://dyndns.regfish.de.

Prerequisites

• a domain at Regfish
• access to the Regfish domain management UI
• a hostname that should be maintained through DynDNS, for example home.example.com
• an updater, script, or device that can call the DynDNS URL
• a clear decision whether you want to update IPv4, IPv6, or both address families

Step 1: Enable DynDNS for the domain

Log in to the Regfish domain management UI, open the target domain, and enable Dynamic DNS in the nameserver settings. After that you receive your personal DynDNS token.

You can optionally enable email notifications for later DynDNS updates as well.

If you build your own updater or a small script, a minimal local configuration could look like this:

{
  "token": "YOUR_DYNDNS_TOKEN",
  "fqdn": "home.example.com",
  "ttl": 300
}

This is not a regfish API request. It is only one possible local configuration object from which your updater can derive the actual DynDNS URL parameters later.

Step 2: Define the update parameters

The legacy service accepts a fixed set of parameters. The most important ones are:

• token: your DynDNS token, required
• fqdn: the full hostname, required
• thisipv4=1: use the IPv4 address of the calling system
• thisipv6=1: use the IPv6 address of the calling system
• ipv4: set an explicit IPv4 address
• ipv6: set an explicit IPv6 address
• forcehost=1: allow creation of a new host entry
• ttl: TTL in seconds, default 300

If you are working with a generic DynDNS client or a script, the token is typically used like a username. You do not need a separate password for the plain URL call itself.

Step 3: Send the first update with the current IPv4

For many simple setups, a request to dyndns.regfish.de that uses the current IPv4 of the calling system is enough:

curl 'https://dyndns.regfish.de/?fqdn=home.example.com&token=YOUR_DYNDNS_TOKEN'

You can also send the same update via POST if your client prefers that.

Step 4: Set explicit IPv4 or IPv6 values

If your updater already knows the target address, you can send it explicitly. That is useful for custom scripts or special network setups.

{
  "ipv4": "203.0.113.42",
  "ipv6": "2001:db8::42"
}

curl 'https://dyndns.regfish.de/?fqdn=home.example.com&ipv4=203.0.113.42&token=YOUR_DYNDNS_TOKEN'

For IPv6 the flow is analogous. If the request itself should reliably run over IPv6, use https://dyndns6.regfish.de.

curl 'https://dyndns6.regfish.de/?fqdn=home.example.com&thisipv6=1&token=YOUR_DYNDNS_TOKEN'

Step 5: Create a missing host when needed

If the hostname does not exist yet, you can allow creation through forcehost=1:

curl 'https://dyndns.regfish.de/?fqdn=home.example.com&ipv4=203.0.113.42&forcehost=1&token=YOUR_DYNDNS_TOKEN'

Use forcehost=1 deliberately and only where your updater is really meant to own that hostname.

Step 6: Evaluate the returned status codes

The service works with simple status codes. The most relevant ones for operations are:

• 100: update successful
• 101: no update required
• 401 or 402: authentication failed
• 408 or 409: invalid IP address
• 412: invalid FQDN format
• 414: unknown error

A robust DynDNS job treats 100 and 101 as successful outcomes and only alerts on real error codes.

Practical notes for production DynDNS jobs

• treat this as a workflow for the regfish DynDNS product, not for the DNS API
• for IPv6, prefer direct calls through dyndns6.regfish.de when your client is definitely running in an IPv6 context
• keep the hostname stable per DynDNS job instead of switching constantly between different FQDNs
• use forcehost=1 mainly for the initial bootstrap and not blindly on every request
• if your DynDNS client expects username and password, use the token as the username; password handling depends on the client and is not required for the plain URL call

Result

This flow uses the existing regfish DynDNS product exactly the way legacy DynDNS clients, script updaters, and simple device integrations expect: hostname, token, and target IP are updated directly through the regfish DynDNS endpoints.