Suddenly my DDNS Test is now failing it's unable to resolve the IPv4 address.
My IP address is public as the WAN Interface IP Address matches the value I see on "whatismyipaddress.com".
When I try to "ping *******.glddns.com" from my computer I get no response whatsoever..
Is anyone else having issues? is there a current outage ?
Please have a look into your logs if they tell something about this.
Currently I would say there is no outage.
Connecting to both OpenVPN and Wireguard VPN's using the IP address work as expected but the DDNS configurations no longer work.
The client configurations DDNS host match the server DDNS host.
HTTPS Remote Access and SSH Remote Access are both enabled from Security Settings.
My Router is not behind any NAT..
Pinging whilst on another network from the home Router (where DDNS is enabled) returns "Ping request could not find host ****.glddns.com"
Pinging whilst on home router network returns only the IPv6 address and not IPv4. Maybe that's the issue? IPv4 resolution isn't working anymore?
Which logs exactly? VPN or Router Logs? I couldn't see much of any help.
DDNS has nothing to do with ping. The DNS is a service for name resolving over UDP and TCP, while ping using ICMP and requesting the device/interface via defined routes.
If you want to check if DDNS is working use nslookup ******.glddns.com instead.
You can also define a specific DNS server via nslookup ******.glddns.com 8.8.8.8 for external or nslookup ******.glddns.com 192.168.8.1 for internal tests.
If you don't trust the network (corporate, ad blockers, compromised, ...) or are on mobile, there is always DNS Lookup Tool - DNS Tools - MxToolbox a valuable source.
Thanks for the correction!
So nslookup returns the DNS server I've configured (1.1.1.1) and only the IPv6 address for the ****.glddns.com host... no IPv4 from either variation of nslookup.
Using the mxtoolbox.com link there is no DNS record found for my ****.glddns.com host.
Looks as if IPv4 is unable to be resolved somehow ?
Do you have a IPv4 address?
Disable your GLDDNS service for a short time and reenable it.
Yes I do.
I think I have resolved the issue. Disabling GLDDNS and reenabling didn't work. But I tried disabling IPv6 and very weirdly now the DDNS test is showing an IPv4 address and also an IPv6 address (even though IPv6 is disabled now) and the test is passing.
I was having an issue previously where my PPPoE would only give me an internet connection with IPv6 enabled but that has also seemingly been fixed because with it disabled I still have internet access.
Any ideas? maybe just a bug to be aware of?
It is somewhat confusing, because a IPv4 is an A record and a IPv6 is an AAAA record.
As far as I know GL-iNet does not support IPv6 at their internet services (GoodCloud, DDOS, ...). So it should be ignored in the request not be any problem.
A nslookup -type A xxxx.glddns.com should be the isolation for IPv4. But in worst case the A and AAAA should be answered.
Is 1.1.1.1 the global DNS of your LAN? If it is the DNS of your provider, maybe your router asked the Internet (ISP DNS) and it only answered IPv6 and the DDNS client cant handle it, because no IPv6 support.
Just an idea what could happen.
they changed the way their DDNS works, I reinstalled 4.5.8 only with IPv4 active and it shows an error every time, nothing I do works again, but if I update to 4.6.0 snapshot the ddns works again.
In 4.5.8, if I delete everything related to ddns plugins and install luci-app-ddns and configure a custom ddns, it works normally.
I think there was some delay maybe after I resolved this as now the nslookup contains the IPv4 address too.
Yeah 1.1.1.1 is being set via AdGuard so all connections using the home router use that DNS.
I see, yeah I'm running 4.5.8 too. Maybe try enabling IPv6 and disabling? Mine is working now fine with just IPv4 active.
Hey folks, I am not sure if I am facing the exact same issue. I have only IPV4 enabled and when I enable the DDNS feature I see the follwoing messages in the log file.
Thu May 30 10:48:52 2024 user.notice ddns-scripts[5507]: glddns: PID '5507' started at 2024-05-30 10:48
Thu May 30 10:48:52 2024 user.err ddns-scripts[5507]: glddns: cURL Error: '7'
Thu May 30 10:48:52 2024 user.warn ddns-scripts[5507]: glddns: Transfer failed - retry 1/0 in 60 seconds
Anyone facing something similar?
It seems to be a different issue to me.
This message means the app curl cannot reach/connect its destination host/port. Is there any firewall or proxy blocking outgoing port 80 tragic?
Nope, in fact I have no firewall rules configured in the router.
In fact, on the router we can see vim /etc/init.d/gl_ddns, here is the main call
PROG=/usr/lib/gl_ddns/dynamic_dns_updater.sh
(Why is the variable not used later in the script?)
We go on with vim /usr/lib/gl_ddns/dynamic_dns_updater.sh.
The url could be in /usr/share/gl_ddns/custom or /usr/share/gl_ddns/default.
root@GL-xnnnn:~# cat /usr/share/gl_ddns/custom
cat: can't open '/usr/share/gl_ddns/custom': No such file or directory
I expected this on a fresh factory reset system.
root@GL-xnnnn:~# cat /usr/share/gl_ddns/default/glddns.com.json
{
"name": "glddns.com",
"ipv4": {
"url": "get_ddns_post_cmd.lua"
},
"ipv6": {
"url": "get_ddns_post_cmd.lua"
}
}
okay, it seems to contact glddns.com ... could you ping this address?
The file get_ddns_post_cmd.lua is binary ... So we should get enough information with strings /usr/lib/gl_ddns/get_ddns_post_cmd.lua | grep -i http. Only the URL are of interest, therefor the grep will filter the results.
Because the first URL is a 404, I think the second one is the one for the curl command. See:
┌──(lupus㉿rea)-[~]
└─$ curl https://ddns.glddns.com/nic/no-tls/update
404 page not found
┌──(lupus㉿rea)-[~]
└─$ curl https://ddns-tls.glddns.com/nic/tls/update
<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>openresty/1.25.3.1</center>
</body>
</html>
Even if it would be interesting to add the certificate and so in in the curl request, I think the issue is before that.
Just try curl https://ddns-tls.glddns.com/nic/tls/update on the router and/or on any system you have at hand with a curl client.
With curl https://ddns-tls.glddns.com/nic/tls/update --verbose we get more than an 'Error 7'. Interesting are any kind of SSL errors. In that case the expected/allowed cert is not matching the given server certificate. So any system within the network is trying to break the ssl.
See. Easy to debug 
Thank you very much for the detailed response.
Based on the information you provided, I did some further digging and found some useful insights.
By checking the /usr/lib/ddns/dynamic_dns_updater.sh script, I discovered two URLs it uses to detect the current WAN IP:
[ "$ip_source" = "web" -a -z "$ip_url" -a $use_ipv6 -eq 0 ] && ip_url="http://checkip.dyndns.com"
[ "$ip_source" = "web" -a -z "$ip_url" -a $use_ipv6 -eq 1 ] && ip_url="http://checkipv6.dyndns.com"
After running cURL targeting both of these URLs, I was able to reproduce the cURL Error 7. For an unknown reason, the router was not able to reach these URLs, even though I could access them via the browser. At this point, I decided to disable and enable AdGuard, which resolved the issue. The router was then able to reach the URLs, and the script updated glddns.com with the correct IP.
In our recent update, the server use the TCP peer public IP to update domain data instead of using http params in order to improve the security.
So there is a issue in the old firmware, IPv4 data was uploaded by IPv6 network. It mean that the IPv4 record would not be update any more in the both IPv4 and IPv6 network .
We decide to recover the original processing logic temporarily, but still consider close the logic when the most user update to the laste firmware in the future days.
I went back to 4.5.8 and ddns doesn't work, even activating ipv6 to synchronize and deactivating ddns again it doesn't synchronize
Wouldn't it be MUCH easier to put a manual ddns? How is it done in luci using the luci-app-ddns plugin? This way, the person who needs it configures it themselves... and is not dependent on the gl server.
It’s not supported use the old API again if the device ever used new API in 4.6.0. Just because we encourage user use the more secure way of DDNS feature. If you still want to use unsecured way, please PM your MAC address to me,We will handle it for you.