DynDNS-Probleme - oder tiefer liegender Fehler mit meiner Installation?

[Anderer]

Ich bin nochmals wie vor 2 Tagen vorgegangen - damals hatte es genau so funktioniert und erst später kamen Probleme:

#35

• ich habe OPNsense auf Werkseinstellungen zurückgesetzt und mit dem Assistant gestartet.
• Änderungen:
  - IP geändert in 192.168.50.1/24
  - IP range von 192.168.50.101 bis 102.169.50.241 (andere vergebe ich gerne manuell)
  => sonst habe ich alles auf Voreinstellung belassen - also auch keine Regeln erstellt oder geändert
• HAProxy strikt nach Tutorial installiert:
  https://forum.opnsense.org/index.php?topic=23339.0
• PING + DNS funktioniert für andere IP und Domains, aber dieses Mal nicht für SUBDOMAIN.dedyn.io
• Services: Dynamic DNS: Log File:
  Warning, ddclient, Account c55... [custom - SUBDOMAIN.dedyn.io] no global IP address detected, check config if warning persists
• lt. deSEC wurde Token nie verwendet (habe bereits 2 neue Token ausprobiert)
• SUBDOMAIN.dedyn.io hat zwar den CAA und CNAME Record, aber keine A und AAAA bekommen (wie werden die vergeben?)
• https://www.ssllabs.com/ssltest/analyze.html bringt "Unable to resolve domain name"
• https://dnschecker.org/all-tools.php zeigt CNAME, NS, SOA, CAA, DS, DNSKEY, aber KEIN A, AAAA, MX, PTR, SRV, TXT

Es scheint, als ob Services: Dynamic DNS gar nicht aktiv wird. Trotz Rücksetzen steht dort Updated: 2025-09-26T20:11:50+02:00

Und gerade finde ich auch noch folgende Fehler:

System: Log Files: Backend

Code Select Expand

025-10-08T01:52:55
Error
configd.py

 [41eda28c-fd48-479d-a428-a6d75652527d] Script action failed with
Command '/usr/local/opnsense/scripts/interfaces/ping.py --job
'dde980bb-90b4-4f5b-9346-2e43798c19a6' remove' returned non-zero exit
status 1. at Traceback (most recent call last):   File
"/usr/local/opnsense/service/modules/actions/script_output.py", line 89,
 in execute     subprocess.run(script_command,
env=self.config_environment, shell=True,   File
"/usr/local/lib/python3.11/subprocess.py", line 571, in run     raise
CalledProcessError(retcode, process.args, subprocess.CalledProcessError:
 Command '/usr/local/opnsense/scripts/interfaces/ping.py --job
'dde980bb-90b4-4f5b-9346-2e43798c19a6' remove' returned non-zero exit
status 1.


2025-10-08T00:53:10
Error
configd.py
 Configd disconnected while executing : dnsmasq list dhcp_options


2025-10-08T00:50:03
Error
configd.py

 [2b5bb0c8-575b-4373-943d-bda2972558dd] Script action failed with
Command '/usr/local/opnsense/scripts/interfaces/ping.py --job
'33de3b91-5dee-4c8a-b650-6238e6710317' remove' returned non-zero exit
status 1. at Traceback (most recent call last):   File
"/usr/local/opnsense/service/modules/actions/script_output.py", line 89,
 in execute     subprocess.run(script_command,
env=self.config_environment, shell=True,   File
"/usr/local/lib/python3.11/subprocess.py", line 571, in run     raise
CalledProcessError(retcode, process.args, subprocess.CalledProcessError:
 Command '/usr/local/opnsense/scripts/interfaces/ping.py --job
'33de3b91-5dee-4c8a-b650-6238e6710317' remove' returned non-zero exit
status 1.


2025-10-08T00:39:24
Error
configd.py

 [1194f58d-6b49-4215-9ea7-026972129b42] Script action stderr returned
"b'pkg: https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/latest/meta.txz:
No address record\npkg:
https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/latest/packagesite.pkg:
No address record\npkg:
https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/latest/packagesite.txz'"
System: Log Files: General

Code Select Expand

2025-10-08T00:47:22
Warning
opnsense
 /usr/local/etc/rc.bootup: radvd_configure_do(auto) found no suitable IPv6 address on lan(igc0)


2025-10-08T00:47:22
Error
dhcp6c
 transmit failed: Can't assign requested address


2025-10-08T00:40:08
Error
opnsense

 /usr/local/etc/rc.newwanip: The command '/bin/kill -'TERM'
'68112''(pid:/var/run/unbound.pid)  returned exit code '1', the output
was 'kill: 68112: No such process'

• Ist die ganze OPNsense korrupt?
• Kann das repariert werden oder müsste ich nochmals mit einem Stick ganz neu booten?
• Kann der Fehler nochmals an einem Interface LAN/WAN oder an einer Route liegen?
• Andere Ideen?

Ich weiß nicht, wo ich noch suchen soll, da ich jetzt nochmals alles neu und aufmerksam eingegeben habe, aber dynDNS (Tutorial Part 2 Nr. 1-9) nicht funktioniert. Deshalb möchte ich dort gar nicht weitermachen.
Falls es keine Hinweise gibt, plane ich, OPNsense nochmals komplett platt zu machen und mit einem USB-Stick neu zu installieren.

[Patrick M. Hausen]

Mach doch bitte einen extra Thread zum Thema DynDNS auf - den lesen Leute, die sich damit auskennen, eher.

Ich kann dir da leider nicht helfen, ich benutze das grundsätzlich nicht. Ich würde eher einen Tunnel zu einem VPC bei Hetzner oder etwas ähnliches benutzen statt DynDNS. Aber ich habe eben überall Business-Tarife, auch zuhause.

[Anderer]

Mach doch bitte einen extra Thread zum Thema DynDNS auf

OK, mache ich. Danke

• Kann #11 in einen neuen Thread kopieren und soll das hier gelöscht oder geschlossen werden?

Vielleicht haben die Fehler auch gar nichts mit DynDNS zu tun und das System wurde beschädigt. Irgendwie läuft es nicht, wie es wohl sollte. Andernfalls mache ich die Kiste heute Abend nochmals mit einem USB-Stick platt. Bzgl. OPNsense habe ich zwischenzeitlich  dazugelernt - es lief am Sonntagabend ja genau, wie beschrieben, sonst hätte ich dort aufgegeben.

[Patrick M. Hausen]

Ich verschieb das - kein Problem.

[Anderer]

Ich habe nochmals ALLES komplett CLEAN installiert und trotzdem: Dynamic DNS geht offensichtlich gar nicht raus:

• SSD des Firewall Mini-PCs mit USB-Stick "platt gemacht" und OPNsense 25.7 (VGA) neu installiert.
  WICHTIG: mit "installer" statt "root" anmelden, um die SSD überschreiben zu können.
• Anschließend Wizzard durchlaufen, neugestartet und mit CMD: ipconfig /release, ipconfig /renew
• IP auf 192.168.50.1/24 mit Range 192.168.50.101 bis 192.168.50.241 umgestellt, Port 55443 vergeben
• Update auf OPNsense 25.7.5, Test von Ping und DNS erfolgreich
• WICHTIG: KEINE Regel hinzugefügt, gelöscht oder geändert. System läuft seit gestern problemlos.
• Snapshot und Backup Konfiguration mit "...CLEAN-IP-DHCP-PORT", obwohl Rollback zuvor erfolglos war.
• Nochmals Schritt-für-Schritt und strikt nach Tutorial: https://forum.opnsense.org/index.php?topic=23339
• Part 1: OPNsense updated, plugins: os-acme-client, os-ddclient, os-haproxy installiert
• Part 2 (1.-6.): SUBDOMAIN.dedyn.io und CAA sowie CNAME mit Wildcard kontrolliert
• Part 2 (7.-8.): Services: Dynamic DNS: General settings: enabled und folgender Eintrag unter Accounts:
  - Service: custom
  - Protocol: DynDNS 2
  - Server: update.dedyn.io
  - Username: SUBDOMAIN.dedyn.io (zum Verständnis: Ist das der Name des TOKENs?)
  - Password: TOKEN
  - Wildcard: No
  - Hostname(s): SUBDOMAIN.dedyn.io
  - Check ip method: Interface IPv4
  - Interface to monitor: WAN
  - Check ip timeout: 10
  - Force SSL: Yes
  vgl. auch Printscreen im Anhang
• Part 2 (9.): Interfaces: Diagnostics: Ping funktioniert mit anderer Domain oder IP, aber nicht mit SUBDOMAIN.dedyn.io
  - deSEC zeigt, TOKEN: Last used: never
  - SUBDOMAIN.dedyn.io hat CAA und CNAME*, aber kein A und AAAA Record (wie beim letzten Mal, als es funktionierte).
  - externe Tests wie ssllabs.com oder dnschecker.or funktionierten analog ebenfalls nicht
  - Interfaces: Diagnostics: Ping: Fehler: cannot resolve anderer.dedyn.io: No address associated with name

Eigentlich musste ich keine weitere Regel anlegen oder Einstellung vornehmen, sondern nur strikt nach Tutorial vorgehen und damit funktionierte es am Sonntagabend. Ich konnte *.SUBDOMAIN.dedyn.io von extern und von intern aufrufen und bekam ein A+ Zertifikat.

Bevor ich nun wieder etwas zerschieße, bitte ich um Hilfe bei der Suche nach dem Fehler. Ich würde gerne sehen, wo etwas blockiert bzw. nicht weitergegeben wird.

• Fehlt mir evtl. noch eine Route o. ä.?

Ich habe noch Folgendes getestet:

• Interfaces: Diagnostics: Ping: 9.9.9.9 zeigt folgenden Eintrag:
   Firewall: Log Files: Live View: WAN out 2025-10-09T14:24:32 192.168.178.5 9.9.9.9 icmp let out anything from firewall host itself (force gw)
  
• Interfaces: Diagnostics: Ping: SUBDOMAIN.dedyn.io zeigt KEINEN Eintrag
  es gibt zwischen den beiden PING mit 9.9.9.9 und 1.1.1.1 KEINEN weiteren ICM Eintrag, also geht Dynamic DNS überhaupt nicht raus.
  
• Interfaces: Diagnostics: Ping: 1.1.1.1 zeigt folgenden Eintrag:
  Firewall: Log Files: Live View: WAN out 2025-10-09T14:24:47 192.168.178.5 1.1.1.1 icmp let out anything from firewall host itself (force gw)

Ergänzung: Ich habe noch folgende Fehler / Hinweise gefunden:

• Services: Dynamic DNS: Log File: 
  - 2025-10-09T14:10:32 Warning ddclient Account 025... [custom - SUBDOMAIN.dedyn.io] no global IP address detected, check config if warning persists
  
• Google: DNS-Auflösung:Stellen Sie sicher, dass OPNsense selbst DNS-Anfragen korrekt auflösen kann. Wenn OPNsense den DDNS-Anbieter-Server nicht auflösen kann, kommt die Anfrage nicht an.
  
• Services: Unbound DNS: Log: 2025-10-09T00:38:50 Error unbound [38502:7] error: recvfrom 67 failed: Protocol not available

Wer kann mir bitte helfen oder hat einen Ratschlag oder eine Idee? Dankeschön

[Anderer]

OK, ich bin einen Schritt weiter.

Services: Dynamic DNS: Settings: General settings: advanced mode

• Enable: Yes
• Verbose: No
• Allow IPv6: Yes, Allow IPv6 for updates
• Interval: 300 (testweise auf 30 reduziert)
• Backend: ddclient (statt bisher "native"), andernfalls mit "native":
  => Services: Dynamic DNS: Log File: no global IP address detected, check config if warning persists

Das sehe ich nicht im Tutorial und erinnere mich auch nicht, das zuvor schon mal umgestellt zu haben.

"Allow IPv6" brauche ich vermutlich deshalb, weil die IPv4 Adresse FALSCH auf 192.168.178.5 (OPNsense im FritzBox LAN) gesetzt wird. Richtig wäre, hier die öffentliche IPv4 zu setzen. Das hatte am Sonntagabend auch geklappt.

• Hat jemand einen Tipp, woher die falsche IPv4 Adresse statt der öffentlichen IPv4 kommen könnte?
• Und wie kann ich bitte ddclient gezielt triggern? Selbst "Restart Service" hilft nicht. ddclient startet scheinbar willkürlich.

Services: Dynamic DNS: Log File

Code Select Expand

2025-10-09T15:50:39 Notice ddclient INFO: setting IPv4 address to 192.168.178.5 for SUBDOMAIN.dedyn.io
2025-10-09T15:50:39 Notice ddclient INFO: setting IPv6 address to 2005:cb:5v14:3n88:4sdr:sfg4:fsfg:f44g for SUBDOMAIN.dedyn.io
2025-10-09T15:50:39 Notice ddclient RECEIVE:
2025-10-09T15:50:39 Notice ddclient RECEIVE: allow: GET, HEAD, OPTIONS
2025-10-09T15:50:39 Notice ddclient RECEIVE: content-length: 4
2025-10-09T15:50:39 Notice ddclient RECEIVE: content-type: text/plain
2025-10-09T15:50:39 Notice ddclient RECEIVE: date: Thu, 09 Oct 2025 13:50:39 GMT
2025-10-09T15:50:39 Notice ddclient RECEIVE: good
2025-10-09T15:50:39 Notice ddclient RECEIVE: HTTP/2 200
2025-10-09T15:50:39 Notice ddclient RECEIVE: server: nginx
2025-10-09T15:50:39 Notice ddclient RECEIVE: strict-transport-security: max-age=31536000
2025-10-09T15:50:39 Notice ddclient RECEIVE: vary: origin
2025-10-09T15:50:39 Notice ddclient SENDING: connect-timeout=120
2025-10-09T15:50:39 Notice ddclient SENDING: Curl system cmd to https://update.dedyn.io
2025-10-09T15:50:39 Notice ddclient SENDING: include
2025-10-09T15:50:39 Notice ddclient SENDING: max-time=120
2025-10-09T15:50:39 Notice ddclient SENDING: request=GET
2025-10-09T15:50:39 Notice ddclient SENDING: silent
2025-10-09T15:50:39 Notice ddclient SENDING: url="https://update.dedyn.io/nic/update?system=dyndns&hostname=SUBDOMAIN.dedyn.io&myip=192.168.178.5,2005:cb:5v14:3n88:4sdr:sfg4:fsfg:f44g"
2025-10-09T15:50:39 Notice ddclient SENDING: user="SUBDOMAIN.dedyn.io:mPcnNLadfereadafvgraDRddssQJ"
2025-10-09T15:50:39 Notice ddclient SENDING: user-agent="ddclient/3.11.2"
2025-10-09T15:50:39 Notice ddclient SUCCESS: updating SUBDOMAIN.dedyn.io: good: IPv4 address set to 192.168.178.5
2025-10-09T15:50:39 Notice ddclient SUCCESS: updating SUBDOMAIN.dedyn.io: good: IPv6 address set to 2005:cb:5v14:3n88:4sdr:sfg4:fsfg:f44g
2025-10-09T15:50:39 Notice ddclient UPDATE: updating SUBDOMAIN.dedyn.io
2025-10-09T15:50:39 Notice ddclient WARNING: 'if-skip' is deprecated and does nothing for IPv4
2025-10-09T15:50:39 Notice ddclient WARNING: 'if-skip' is deprecated and does nothing for IPv6
2025-10-09T15:50:41 Notice ddclient SUCCESS: SUBDOMAIN.dedyn.io: skipped: IPv4 address was already set to 192.168.178.5.
2025-10-09T15:50:41 Notice ddclient SUCCESS: SUBDOMAIN.dedyn.io: skipped: IPv6 address was already set to 2005:cb:5v14:3n88:4sdr:sfg4:fsfg:f44g.
2025-10-09T15:50:41 Notice ddclient WARNING: 'if-skip' is deprecated and does nothing for IPv4
2025-10-09T15:50:41 Notice ddclient WARNING: 'if-skip' is deprecated and does nothing for IPv6

[viragomann]

Hat jemand einen Tipp, woher die falsche IPv4 Adresse statt der öffentlichen IPv4 kommen könnte?

Vermutlich hiervon:

- Check ip method: Interface IPv4
- Interface to monitor: WAN

Du stellst den Client so ein dass er die WAN IP überwacht. Diese übermittelt er dann an den Server.
Für mich macht der alles richtig.

Ich bin jetzt mit dieser Art dynamischem DNS nicht vertraut. Aber was für alternative Check Methoden werden noch angeboten?

Nachdem die OPNsense ein private WAN IP hat (lässt sich das wirklich nicht ändern?), kann sie deine tatsächliche öffentliche IP (des vorgeschalteten Routers) nur durch einen Lookup ins Internet ermitteln. Aber das musst du entsprechend einstellen.

Dir muss auch klar sein, dass der Dyn-DNS Client die Prüfung "auf Verdacht" machen muss, also zeitgesteuert. Ich weiß jetzt nicht, ob der Cron Job dafür automatisch eingerichtet wird. In jedem Fall dauert nach der IP-Änderung es bis zur nächsten Ausführung, bis das Update gemacht werden kann.
Um sich diesen schwammigen Workaround zu ersparen, sollte der Dyn-DNS Client besser am externen Router laufen.

[meyergru]

Na klar, das ist nur eins der vielen Probleme, die bei einem Router-behind-Router Szenario entstehen (weshalb ich immer nahelege, das zu vermeiden, siehe auch: https://forum.opnsense.org/index.php?topic=42985.0, Punkt 4):

Deine OpnSense "kennt" nicht die wirkliche WAN-IP, denn ihr WAN hat eine RFC1918-IP (eben genau 192.168.178.5). Je nachdem, wie Du den DynDNS-Client die IP bestimmen lässt, stimmt diese eben nicht. Du kannst per Web-Abfrage die IP herausbekommen, z.B. mit der checkip-Methode "Akamai".

Der DynDNS-Client wird getriggert, wenn das WAN eine neue IP bekommt (was es natürlich bei Router-behind-Router nie tut, die WAN-IP-Änderung sieht ja zunächst nur Deine Fritzbox), man muss deshalb eine geringe TTL einstellen, damit aktiv nachgefragt wird.

Alles nicht ideal, viragomann hat Recht. Wenn Du kannst, nutze die Fritzbox nur als Telefonie-Gateway (siehe https://forum.opnsense.org/index.php?topic=39556).

[Anderer]

Aber was für alternative Check Methoden werden noch angeboten?

Check ip method:

•     akamai
•     akamai-ipv4
•     akamai-ipv6
•     cloudflare
•     cloudflare-ipv4
•     cloudflare-ipv6
•     dynu-ipv4
•     dynu-ipv6
•     freedns
•     he
•     icanhazip
•     ipify-ipv4
•     ipify-ipv6
•     loopia
•     myonlineportal
•     noip-ipv4
•     noip-ipv6
•     nsupdate.info-ipv4
•     nsupdate.info-ipv6
•     zoneedit
•     Interface

Interface to monitor:

• None
• LAN
• WAN

Leider kann ich hier nicht ohne Weiteres die Topologie ändern. Dazu müsste ich einen neuen DSL-Anschluss beauftragen und einiges an Kabel verlegen, wo ich wiederum nicht ohne Weiteres die Wände, Decken oder Böden aufklopfen kann. Mit der aktuellen Topologie habe ich kaum Verluste und werde den FritzRepeater 1750E gelegentlich durch die neuen Wifi-7 Repeater ersetzen, was aufgrund der Internetgewschwindigkeit, aber nachrangig sein sollte.

OPNsense ist als "Exposed Host" eingetragen und checkt alle 300ms die IP. Das könnte ich ggf. herabsetzen. Für das LE Zertifikat wird es einen Cronjob geben, aber soweit komme ich aktuell noch gar nicht, denn Ping sollte sofort funktionieren und es muss wohl mit der IPv4 zusammenhängen.

Am Sonntagabend funktionierte es mit diesem Setup - bis ich mit der Installation von Nextcloud begann und/oder sich die öffentliche IP geändert hat. Da damals die öffentliche IP korrekt eingetragen wurde, muss ich aktuell irgendwo einen Fehler haben oder es gab noch eine unbewusste Einstellung.

[viragomann]

"akamai" ("akamai-ipv4") als Checkmethode hat @meyergru schon vorgeschlagen. Vormutlich würden auch andere funktionieren. "Interface" scheint mir die schlechteste Wahl aus dem Sortimen für dein Setupt zu sein. Denn diese liefert die Interface-IP, wie beschrieben, und die kannst du in dein DynDNS nicht eintragen, weil RFC 1918. Wenn auch, würde es auch nix bringen.

[Anderer]

Probleme, die bei einem Router-behind-Router Szenario entstehen (weshalb ich immer nahelege, das zu vermeiden

Ja, das hatte ich bereits zur Kenntnis genommen und ich bin grds. vollkommen einverstanden, aber hier wäre der Aufwand unverhältnismäßig hoch bzw. aktuell gar nicht machbar - insbesondere, da am Sonntagabend alles bereits funktioniert hatte.

checkip-Methode "Akamai

Bingo! mit "Akamai" funktioniert es. DANKESCHÖN

"Interface" scheint mir die schlechteste Wahl aus dem Sortimen für dein Setupt zu sein.

Danke! Ich werde noch einen Kommentar unter dem Tutorial ergänzen, falls andere auch dieses Problem bekommen sollten. OPNsense als "Exposed Host" hinter FritzBox ist vermutlich keine völlig extreme Ausnahme, wenn auch nicht "empfohlen". Akamai ist zudem bereits voreingestellt. Merci :-)


Bevor ich weitermache, darf ich bitte noch um Rat zu folgenden Einstellungen bitten?

• System: Routes: Configuration: 0.0.0.0/0, WAN_DHCP - 192.168.178.1, Standardroute
  => Muss ich diese Standardroute eintragen, obwohl aktuell das Meiste mit Voreinstellungen funktioniert?
  
• System: Settings: General: Networking: DNS Server
  => sollte ich hier DNS Server eintragen oder NUR dann, wenn ich eine andere Reihenfolge wünsche?
  
• Services: Dynamic DNS: Settings: General settings: Allow IPV6: Yes, for updates
  => Soll ich das wieder auf Voreinstellung = "No" zurückstellen, oder kann IPv6 eine Verbesserung sein?

[viragomann]

System: Routes: Configuration: 0.0.0.0/0, WAN_DHCP - 192.168.178.1, Standardroute
=> Muss ich diese Standardroute eintragen, obwohl aktuell das Meiste mit Voreinstellungen funktioniert?

Nein. Das macht die FritzBox per DHCP. Da wird die Route auch gesetzt.

System: Settings: General: Networking: DNS Server
=> sollte ich hier DNS Server eintragen oder NUR dann, wenn ich eine andere Reihenfolge wünsche?

Auch das macht die FB via DHCP. Die trägt vermutlich ihre eigen IP als DNS ein.
Du kannst manuell aber einen anderen Server setzen, wenn gewünscht.
Ob dieser auch für die Hosts hinter der OPNsense verwendet wird, hängt von deiner DNS Bereitstellung ab (Dnsmasq, Unbound).

Services: Dynamic DNS: Settings: General settings: Allow IPV6: Yes, for updates
=> Soll ich das wieder auf Voreinstellung = "No" zurückstellen, oder kann IPv6 eine Verbesserung sein?

Wenn du IPv6 verwendest, ist es nützlich. Wenn nicht, ist es überflüssig. Wenn auf den Clients, aber am WAN nicht, führt es zu Fehlern.
Also ja, zurückstellen.

[meyergru]

Mit IPv6 gibt es dann die nächsten Probleme bei diesem Setup. Danach geht es weiter mit Wireguard Site2Site.

Ich finde es immer wieder lustig, wie mit der Begründung "das ist mir jetzt zu aufwendig" die Leidensgeschichte beginnt... ;-)

[Anderer]

das ist mir jetzt zu aufwendig

Also das sind nun gerade nicht meine Worte - im Gegenteil. Nachdem 2x Zurücksetzen und mehrfach Rollback nicht funktionierten, habe ich sogar die ganze SSD nochmals überschrieben, damit OPNsense wirklich CLEAN ist, was beim Rücksetzen über Webgui nicht der Fall ist.

Ich hänge jetzt auch schon 2 Wochen mit der Grundinstallation von OPNsense und HAProxy fest, weil ich das korrekt machen möchte, aber eigentlich brauche ich DRINGEND Nextcloud.

Deshalb auch nochmals meine Frage:

• Kann mit meiner öffentlichen IPv4 noch etwas anderes gestört sein?

Wenn ich die selbst eingetragene Standardroute sowie Verbose und Allow IPv6 jeweils deaktiviere, kommt wieder dieser Fehler:
Services: Dynamic DNS: Log File

Code Select Expand

2025-10-09T18:19:54 Notice ddclient WARNING: Could not determine an IP for SUBDOMAIN.dedyn.io
2025-10-09T18:19:54 Notice ddclient WARNING: SUBDOMAIN.dedyn.io: unable to determine IP address with strategy use=cmd
2025-10-09T18:19:54 Notice ddclient WARNING: found neither IPv4 nor IPv6 address
Sobald ich die Standardroute sowie Verbose und Allow IPv6 jeweils aktiviere, funktioniert es wieder:

Code Select Expand

2025-10-09T18:20:46 Notice ddclient SUCCESS:  SUBDOMAIN.dedyn.io: skipped: IP address was already set to 93.214.62.185.
Ich frage deshalb nochmals nach, damit am Ende nicht die ganze Installation auf wackligen Beinen steht, weil IPv4 o. a. eigentlich nicht korrekt funktioniert.

Am Sonntag war zwar auch diese Standardroute eingetragen, aber sicher nicht Verbose und IPv6 - und es funktionierte.

[meyergru]

Ich kenne den DynDNS-Provider nicht. Die Meldung ist an sich nur eine Warnung, die ausgelöst wird, wenn der eingetragene Name, der darauf getestet wird, ob er bereits mit der gewünschten IP übereinstimmt, nicht aufgelöst werden kann. Im Zweifel würde dann der Update durchgeführt. Manche DDNS-Provider mögen es nicht, wenn überflüssige Updates passieren (zu oft).

Ich weiß nicht, wieso der Name da gerade nicht aufgelöst werden kann (also, was dem vorausging) oder warum das mit IPv6 zusammenhängt.