Frequently asked questions on DynDNS, health checks, CDN64 and Cloud Router
Short answers to the questions asked most often: about IPv64.net in general, DynDNS domains and updates, health checks, CDN64 and the blocklists, the Cloud Router with VPN and your account. Detailed guides are on the linked pages.
About IPv64.net
What is IPv64.net?
IPv64.net is a DynDNS and DNS service with full IPv4 and IPv6 support. Your account also includes:
- DynDNS with 19 domain suffixes and your own domains,
- health checks online from several locations or locally with Node64, with notifications via e-mail, SMS, app, Telegram, Discord, Slack, Teams, Matrix, ntfy, Gotify, Pushover or webhook,
- DNS failover, which switches a record to a backup target automatically,
- CDN64, which publishes services via edge servers in Germany without port forwarding – with a port mapper for TCP and UDP,
- Cloud Router as a WireGuard VPN gateway.
What does IPv64.net cost?
Using it is free. For technical reasons, free accounts have limits, for example on the number of domains and DynDNS updates per day. With normal use you usually won't reach them.
If you need more or want to support the project, choose a bigger account class: Home / Supporter (€40 / year), Business (€100 / year) or Company (€200 / year), each incl. VAT as a one-off payment for 365 days, not a subscription. All limits are compared on Pricing, explanations under Account & limits.
Where can I see my current limits?
In the Account Status card shown on the right of most pages. It lists your account class, the number of your domains, the DynDNS updates of the last 24 hours, health checks, API calls and SMS. A green badge means there is room left. A red badge means the limit is reached. More under Account & limits.
My question isn't listed. Where can I get help?
Ask the community in the v64.tech forum or on the community Discord server. For individual routers and devices there is the DynDNS Helper with ready-made update URLs and the guides under Routers & devices.
DynDNS domains and DNS records
Which domain suffixes are available for DynDNS?
You can create your subdomain under 19 domains: ipv64.net, ipv64.de, any64.de, api64.de, dns64.de, dyndns64.de, dynipv6.de, eth64.de, home64.de, iot64.de, lan64.de, nas64.de, root64.de, route64.de, srv64.de, tcp64.de, udp64.de, vpn64.de and wan64.de.
How do I create a DynDNS domain?
After signing up, create your domain in the DynDNS menu. It is activated immediately and resolvable on the internet. Then enter the domain's update URL in your router or device. Step by step: DynDNS domains and Routers & devices.
Can I use my own domain?
Yes. Add the domain as your own domain in the DynDNS menu and enter the IPv64.net name servers at your domain provider:
ns1.ipv64.netns2.ipv64.net
Afterwards you manage all records of the domain at IPv64.net and update them via DynDNS just like an IPv64 subdomain. How many own domains you can add depends on your account class (Account & limits).
Which DNS records can I create?
Supported are A, AAAA, CNAME, MX, TXT, NS, SRV, TLSA and CAA.
- A CNAME cannot share a prefix with other records. If a prefix has a CNAME, a DynDNS update for this prefix is rejected.
- SRV and TLSA need a prefix and four values separated by spaces, e.g.
10 5 5060 sip.example.com. - CAA consists of three values, e.g.
0 issue letsencrypt.org. - For MX, priority 10 is set if you don't specify one.
More under DynDNS domains.
Can I set up my own prefixes (subdomains)?
Yes, you can add any prefixes as DNS records, e.g. nas.yourdomain.ipv64.net. Allowed are lowercase letters, digits, dot, hyphen and underscore; uppercase letters are converted to lowercase automatically. Multi-level prefixes like a.b and entries like _acme-challenge for Let's Encrypt certificates work too.
What does the Wildcard option mean?
The Wildcard option is enabled by default for new domains. A matching wildcard entry is then set automatically for every A, AAAA and CNAME record, so that all names below it resolve as well.
Example: With wildcard enabled, not only yourdomain.ipv64.net but also anything.yourdomain.ipv64.net points to your IP address. Without the option, only yourdomain.ipv64.net is reachable.
For DynDNS addresses this is usually right. If you don't need it, switch the option off in the domain settings and set individual * records by hand if required. A change applies immediately to all existing records.
How quickly is a new IP visible everywhere?
Every record has a TTL (time to live). DNS resolvers may cache an answer for that long before asking again. So after an update it can take up to the length of the TTL until everyone sees the new IP. The TTL of your records depends on your account class (row “DynDNS TTL” on Pricing). Check the current state with the DNS Lookup.
DynDNS update and routers
How do I update my IP automatically on Linux?
Add this line to your crontab (command crontab -e) and replace key and domain with your values:
0 */2 * * * curl -sSL "https://ipv64.net/nic/update?key=YOUR_DOMAIN_KEY&domain=yourdomain.ipv64.net"
Without further parameters, the address the request comes from is used. Every call counts towards your daily update limit, even if the IP hasn't changed. An interval of a few minutes to hours is perfectly sufficient. More under Update URL & protocol and Routers & devices.
Which parameters does the update URL understand?
The updater is available at https://ipv64.net/nic/update and https://ipv64.net/update.php and speaks the common DynDNS2 protocol. The most important parameters:
| Parameter | Meaning | Also recognised as |
|---|---|---|
key | Update token | token, user, username, pass, pwd, password |
domain | Domain, several separated by commas | domains, host, hostname, zone |
ip | IPv4 address | ipv4, ip4, myip, myipv4 |
ip6 | IPv6 address | ipv6, myip6, myipv6 |
praefix | Update only this prefix | |
ipv6prefix | IPv6 prefix of your line, also auto | ip6lanprefix, ip6prefix, prefix |
output | min for a short answer, none for no output | |
healthcheck | Token of a push check that is pinged with every update | healthtoken |
You can also send the key via HTTP basic auth or as a bearer token in the header. In myip, IPv4 and IPv6 may be given together separated by a comma, in any order – the Telekom Speedport routers need this, for example. Private addresses like 192.168.x.x are not accepted. All details: Update URL & protocol.
Account update token, domain token, prefix token: which is for what?
There are three update tokens with different scopes. The smaller the scope, the less can happen if a token falls into the wrong hands.
- Account update token: valid for all domains in your account, whether IPv64 domain or own domain.
- Domain update token: valid for exactly one domain with all its prefixes. The
domainparameter can be omitted. - Prefix / record update token: valid for a single prefix only and changes only its A and AAAA entry – handy if someone else may change only this one entry.
Recommendation: use the domain or prefix token in routers and devices instead of the account token.
What do the updater's responses and error codes mean?
| Response | HTTP | Meaning |
|---|---|---|
good | 200 | The IP address was updated. |
nochg | 200 | The IP address is unchanged, nothing was changed. |
badauth | 401 | The key is wrong, doesn't match the domain, or the domain is disabled. |
| No correct IP transmitted | 400 | No valid public IP address was submitted. |
| CNAME is set. | 409 | The prefix has a CNAME, so no A or AAAA record can be set. |
| Updateintervall overcommited | 429 | The daily update limit of your account class is reached. |
| Update Cooldown - 10sec | 429 | Too many updates within 10 seconds. Wait a moment and increase the interval. |
By default the updater responds with JSON. With &output=min only the single word is returned; for errors other than badauth it is fail.
My router reports an error on the DynDNS update. What can I do?
Manufacturers' updaters expect different responses: one wants a detailed answer, the next just a single word. Try in this order:
- Minimise output:
https://ipv64.net/nic/update?key=…&domain=…&output=min - Force IPv4:
https://ipv4.ipv64.net/nic/update?key=…&domain=… - Force IPv6:
https://ipv6.ipv64.net/nic/update?key=…&domain=… - Use the domain token instead of the account token, in special cases the prefix token.
- Check the logs: under Logs you see what arrived at IPv64.net.
Ready-made URLs for many devices are in the DynDNS Helper and under Routers & devices.
I have DS-Lite or CGNAT. What do I need to consider?
With DS-Lite and CGNAT you don't have your own public IPv4 address. You share it with other customers of your provider and can't be reached through it from outside.
To keep this shared IPv4 from being entered at all, set the option Ignore IPv4 / A Records in the domain settings. The updater then only sets the AAAA record. Conversely there is Ignore IPv6 / AAAA Records. If you still need reachability via IPv4, the Cloud Router or CDN64 with Node64 help – without any port forwarding.
How do I reach individual devices via IPv6 when my prefix changes?
With IPv6, every device has its own address made of your line's prefix and a fixed device part. If the provider changes the prefix, all addresses change.
For this, store the IPv6 prefix at the domain and create one AAAA record per device that contains only the device part and starts with ::. Instead of the device part you can also enter the MAC address; it is converted automatically.
Your router then reports the new prefix via the ipv6prefix parameter, e.g. &ipv6prefix=2001:db8:1234:5600::/64 or – via ipv6.ipv64.net – &ipv6prefix=auto. All device records are then adjusted automatically. With &onlyprefix only the prefix is updated, no A or AAAA record of the domain:
https://ipv6.ipv64.net/nic/update?key=YOUR_DOMAIN_KEY&ipv6prefix=auto&onlyprefix
More example URLs under Update URL & protocol, a worked example under DynDNS domains.
Can I combine DynDNS update and health check?
Yes. Create a push check under Health checks and append its token with &healthcheck=TOKEN to your update URL. With every DynDNS update the push check is pinged as well. This way you notice when your router stops sending updates. Where the message goes is set under Notifications.
What does DNS failover do?
DNS failover links a health check (online, local or hybrid) to a DNS record. If the health check reports an outage, the record is switched to a backup target automatically; once the original target is reachable again, it switches back. While a failover is active, the monitors and rules of the policy cannot be changed. Guide: DNS failover.
Health checks
What can the IPv64.net health checks do?
They monitor websites, APIs, servers, ports, certificates, DNS records, domains (WHOIS/RDAP) and cron jobs. Measurements run online from the locations Nuremberg and Falkenstein, locally in your home network with Node64, or both together. If something fails, you get a message – by e-mail, SMS, app, chat service or webhook. All check types are listed under Health checks.
What is the difference between online, local and hybrid?
Online means IPv64.net measures from outside – the way your visitors see the service. Local means a Node64 in your network measures, including targets that are only reachable internally. Hybrid does both; the detail page then shows whether a problem lies inside, outside or with the service itself. More under Execution.
Can I monitor devices with a private IP address?
Not online: IPv64.net cannot reach your home network from outside and rejects private targets such as 192.168.x.x, localhost or .local names for online checks. With a linked Node64 you measure such targets locally – without port forwarding, and local measurements do not count against your limits.
How do I monitor a cron job or a backup?
With a push check: set the expected period (e.g. 86400 seconds for a daily backup) and call the push URL https://ipv64.net/health.php?token=YOUR_PUSH_TOKEN at the end of the job. If the call does not come, IPv64.net reports an outage; with &status=down you report a failure yourself. Examples under Push checks.
What counts against my health check limits?
Only online measurements. Every location of an online or hybrid check occupies a measuring point; in addition there is a daily quota of online measurements and pushes. When it is reached, the online checks pause until midnight and show “quota used up”; local measurements continue. The form calculates the usage in advance. Details under Limits.
My check shows “not monitored”. What does that mean?
For three intervals (at least 5 minutes) no measuring point has delivered fresh data – usually the only measuring node is offline. IPv64.net then does not know whether the service is reachable. Check the node in the node overview or add an IPv64 location (hybrid).
I don't get any notification. What can I check?
- Is there an enabled channel at all? Without a channel no messages are sent.
- Has the check selected its own channels? Otherwise only the default channels apply.
- Is an e-mail or SMS channel still “not confirmed”?
- Are “on outage” and “on recovery” switched on at the check and at the channel?
- Are quiet hours or a maintenance window active, or does the check depend on a check that is down?
- What does the delivery log say? A test with the paper plane button shows whether the channel works.
More under Notifications.
How do I avoid too many messages?
Set retries before alert so that a single glitch does not alert, and dependencies so that only your router reports when it fails. IPv64.net combines many simultaneous outages into one grouped alert, and during quiet hours everything arrives grouped afterwards – except for critical checks. See Quiet hours and grouped alerts.
CDN64
What is CDN64 and do I need port forwarding for it?
CDN64 publishes your website or service via four IPv64.net edge servers in Nuremberg and Falkenstein. Visitors connect to these servers, not to your internet connection. With Node64 (modes 1 and 2) you need no port forwarding: Node64 opens the tunnel from the inside out. Only mode 3 connects directly to a publicly reachable target. More under CDN64.
Does CDN64 work with DS-Lite and CGNAT?
Yes, with Node64 in mode 1 or 2. The tunnel is an outgoing connection (UDP or TCP on port 7844 or 443) that also works behind DS-Lite, CGNAT and on IPv6-only connections. The edge servers are reachable over IPv4 and IPv6 – so visitors reach your service over IPv4 too.
Which mode should I choose?
Mode 1 only passes encrypted connections through; TLS ends in your node (end-to-end). This is the default. Mode 2 terminates TLS on the edge servers and can filter there. Mode 3 needs no Node64 and goes directly to your publicly reachable server, optionally with cache. A comparison is under The three modes.
Do I have to add a CNAME or other DNS records?
No. When you switch a name on, IPv64.net changes it itself: it gets A and AAAA records of the edge servers with TTL 10 seconds, your own records are dormant and come back when you switch off. The name must belong to a domain of your IPv64.net account and must have no CNAME and no active DNS failover. Details: DNS and certificates.
Does my DynDNS update keep working while a name is in CDN64?
Yes. The updater keeps updating your own dormant records, while public DNS points to the edge servers. In mode 3 with the target „A/AAAA records of the name“, the servers therefore always use your current IP. If the updater answers "cdn" for an address family, the name only has an edge server record for it (see responses).
How many names and how much traffic do I get?
That depends on your account class: Free has 1 CDN domain and 10 GB traffic per month, Home / Supporter 5 and 100 GB, Business 10 and 20 TB, Company 25 and 20 TB. When the traffic is used up, IPv64.net blocks your names until the new month or an upgrade. All values are under quota and traffic.
How do I protect my service during an attack?
With pause at ipv64.net/cdn64, in Node64 or via the API, the edge servers immediately stop accepting anything for the name and close open connections. DNS stays on the servers, so your own IP address stays hidden. For permanent restrictions use the name's access list, and in Node64 also country blocking and blocklists (see protection).
I deleted Node64 without switching CDN64 off. What happens?
The tunnel stays orphaned at IPv64.net. After 48 hours without connection, ipv64.net/cdn64 shows a notice with a date. After 14 days IPv64.net removes the tunnel and its names automatically; DNS then points to your original records again. To avoid this, start Node64 again or switch the names off yourself at ipv64.net/cdn64. More under orphaned tunnels.
IP blocklists
Do the blocklists cost anything?
No. All lists on ipv64.net/v64_blocklists are free and can be fetched without login, including the daily state of the v64 Blocklist. Only the live state of the v64 Blocklist (every 30 minutes) requires a list token and is available to contributors with a Honeypot64 sensor and all account classes except Free; in Node64, PROXY64 fetches the token automatically with your API key. Respect the licences of the source projects, e.g. CC BY-NC-SA for DShield. More under Blocklists.
Which list should I use?
To start with, Spamhaus DROP (spamhaus_drop) or FireHOL Level 1 (firehole_l1) – both have very few false positives. For servers on the Internet, all_notor (all attacker lists without Tor) plus the v64 Blocklist is a good choice. A table by use case is under Which list for whom?.
What is the difference between all and all_notor?
Both combine Spamhaus DROP, FireHOL Level 1, DShield, blocklist.de, ET Compromised and Feodo Tracker. all also contains the Tor lists and therefore blocks all Tor users; all_notor leaves Tor out. The v64 Blocklist, CINS, IPsum and the DoH, cloud and AI lists are in neither of them.
How often are the lists updated, and how often may I fetch them?
The lists from public sources are regenerated several times a day, the country lists daily, the v64 Blocklist once a day as daily state and every 30 minutes as live state. Please fetch the lists at most every 30 minutes; every 1 to 6 hours is enough. Details under Updates and fair use.
What is the v64 Blocklist?
IPv64.net's own list. It is built from the reports of the community's Honeypot64 sensors: an address is only listed once sensors of several independent accounts have reported it, and it drops off again after 14 days without new attacks. It is one list (v64), without sub-lists; IPv64 Secure shows the daily state and the live state. You can run your own sensor with Node64. More under v64 Blocklist.
My IP is on a list. What can I do?
For the v64 Blocklist, the IP lookup shows why the address is listed; you can also request a release there. If the address then does not touch any sensor for 24 hours, it is released automatically and protected for 30 days. For the other lists, contact the respective source project (e.g. Spamhaus or blocklist.de); with the next update the entry also disappears at IPv64.net. Often an infected device in your own network or a shared address (mobile network, CGNAT, VPN) is the cause.
How do I add a list to my firewall?
Almost every firewall accepts a URL with one address or network per line, e.g. https://ipv64.net/blocklists/ipv64_blocklist_firehole_l1.txt. Step-by-step guides for nftables, iptables/ipset, pfSense, OPNsense, MikroTik, Palo Alto, FortiGate, Sophos, nginx, CrowdSec and Node64 are under Use blocklists.
Should I also use the lists for outbound traffic?
Only some of them: Spamhaus DROP and Feodo Tracker also outbound (destination = list), so infected devices cannot reach their control servers; the DoH server list outbound only, so devices cannot bypass your own DNS filter. The other lists are meant to block inbound connections by source.
Cloud Router and VPN
What is the Cloud Router?
A virtual router in German data centres with its own routing table and firewall. Your devices connect to a VPN gateway in it via WireGuard. This lets you make services behind DS-Lite or CGNAT reachable from outside, connect locations or use it like a normal VPN provider. More under Cloud Router.
Does the Cloud Router cost extra?
No, it is part of every account class, including the free one. The number of routers, gateways and peers, bandwidth and monthly traffic depend on the account class (Pricing). In the free account, internet access via the gateway is limited. Only an own public IPv4 (€6.99 / month) and the Managed Cloud Router cost extra.
Do I get my own public IPv4?
By default your Cloud Router uses the IPv4 and IPv6 of its VPN server, shared by several customers. Port forwarding then uses randomly assigned ports. You can create one own public IPv6 per Cloud Router yourself for free; an own IPv4 costs €6.99 / month (incl. VAT) and is booked by e-mail to info@ipv64.net. Details: Public IPv4 and IPv6.
How do I forward a port?
With the port mapper at the gateway (Gateway Options → Portmapping): enter the destination IP in the tunnel, port and protocol (TCP or UDP). IPv64.net assigns a random public port. The port mapper only connects IPv4 to IPv4 and IPv6 to IPv6 and is still in test operation. Guide: Port forwarding with the port mapper.
Can I use the Cloud Router as a normal VPN?
Yes. A client connects to the gateway and goes out to the internet through it – just like with a normal VPN provider. For this the configuration contains AllowedIPs = 0.0.0.0/0, ::/0. See VPN gateway.
My peer doesn't connect. What can I check?
- If the peer list shows a spinner, the change is still being applied – wait a moment.
- Red network icon: no recent handshake. Check that the tunnel is active on the device, that outgoing UDP to the gateway port is allowed and that you use the current configuration (after a key change).
- Behind NAT or CGNAT, set a keepalive, e.g.
00:00:25. - Warning triangle “IP missmatch Subnet”: the tunnel address is not in the gateway's network.
More under Troubleshooting.
Does IPv64.net store my connection data?
Yes. IPv64.net deliberately has no “no-log policy” and complies with the legal requirements: connection-relevant data is stored in an immutable form, and traffic can be recorded in case of suspicion. Illegal services are forbidden. You can see who is connected to your gateway yourself under Show Connections.
What is the difference to the Managed Cloud Router?
The Managed Cloud Router can do the same but runs dedicated just for you – without shared CPU and bandwidth, with own IPv4 and IPv6 addresses including PTR records and without limits. It is available as a cloud variant for €49 and as a hardware variant for €149 per month. See Managed Cloud Router.
Account and security
Can I protect my account with a second factor?
Yes. Under Settings, section 2FA, you add an authenticator app (TOTP, e.g. Google Authenticator) or a YubiKey. On login, the second factor is then requested in addition to the password. See Account & limits.
Can my IT service provider co-manage my account?
Yes, without you handing over your password. You both need your own IPv64.net account.
- Under Settings, enter the e-mail address of the other account in the Share my Account card.
- The other account confirms the request in its settings under Managed Accounts.
- From there it can then log into your account with one click and switch back to its own.
Access works without your password and without your 2FA – so only grant it to people you trust. You are logged out yourself during the access. In your settings you see when the share was last used and can remove it at any time.
Is there an API?
Yes. You find the API key under API. Among other things, the API lets you manage domains and DNS records, e.g. for the Let's Encrypt DNS challenge. How many API calls per day are possible depends on your account class. All calls are described on the API page.
Found a mistake or missing something? Tell us in the v64.tech forum. · Updated: 2026-11-04