Hello,
The external address is recognized correctly by IPFire, but the address is not dynamically changed.
Where can I check logs or help to debug the issue?
Thank you,
Antonio
Go to the menu Logs - System Logs and then in the drop down box labelled Section: select Dynamic DNS.
Select a date and then press the Update button.
You should then see any error messages relating to a problem with the DDNS update process.
1 Like
IPFire needs your dyndns hostname for checkup. This should not be “all.ddnskey.com”
2 Likes
Thanks.
The issue was in my DNS system.
Once I solved that it worked. The only strange thing, is that I remember the hostname becoming green once the IP was updated. Which is not happening now anymore.
That is how the new DDNS Keys work in no-ip.com according to the documentation linked in my first post.
Looking at the page from no-ip.com then it does look like you are supposed to enter that generic DDNS Key Hostname into the Hostname field. It looks like with the DDNS Key approach that is a generic hostname that will apply to everyone and that noip figure out which hostname is actually meant by the use of the DDNS Key which is put into the password field.
If that is how it is supposed to work then you will always have your hostname showing as red.
IPFire takes the hostname that you have provided, ie all.ddnskey.com, and sends a request to noip (or any other DDNS provider) and asks to be given the IP for that hostname. IPFire then compares that IP with the one actually on your IPFire and if they match then the hostname entry is made green. If they do not match then the entry is made red.
In your case with the DDNS Key approach using a generic hostname will always show red as the IP for all.ddnskey.com will never match the one you have on your system.
It looks like the new method being used by noip will not work with the status approach used for all other DDNS Providers.
2 Likes
I understand!
Thank you for the feedback and support so far.
I have just done a search and it seems that the DDNS Keys approach is specific to noip alone and is not a general new standard that will be used by all DDNS Providers.
So not so easy to get the status for noip if DDNS Keys is being used. Your IP should get updated but you will have to check that yourself manually. It will not be shown via the hostname colour.
I think this is bad because IPFire try to update the IP again if the hostname not match.
Im not sure if no-ip is still working because our code
1502 class DDNSProviderNOIP(DDNSProtocolDynDNS2, DDNSProvider):
1503 handle = "no-ip.com"
1504 name = "NoIP"
1505 website = "http://www.noip.com/"
1506 protocols = ("ipv4",)
1507
1508 # Information about the format of the HTTP request is to be found
1509 # here: http://www.noip.com/integrate/request and
1510 # here: http://www.noip.com/integrate/response
1511
1512 url = "https://dynupdate.noip.com/nic/update"
1513
1514 def prepare_request_data(self, proto):
1515 assert proto == "ipv4"
1516
1517 data = {
1518 "hostname" : self.hostname,
1519 "address" : self.get_address(proto),
1520 }
1521
1522 return data
Not fully match with the doc here:
The parameter for the ip address is now myip and not address but maybe noip accept both.
3 Likes
Ah yes. I forgot that.
So you could be trying too often to get an update when it is not needed and then the IP gets blocked by no-ip
1 Like
So I just got a no-ip free DDNS hostname and set it up with the original username and password approach.
I then got a green status from the initial setup.
I then edited the IP in my no-ip account to be different from what I am actually using.
That caused the hostname to go red.
I then ran an instant update. From the IPFire logs that was shown to be successful.
After a while the IP in my no-ip account was updated to the one I am actually using. Then after a short period the hostname on the IPFire DDNS page went green.
So for the old style DDNS connection the no-ip system is still working so @arne_f is right with his hope that no-ip accept both myip and address in the request as my update communication worked without any issues.
I will try adding an entry for the DDNS Keys approach and see what happens.
1 Like
I have now set up another entry using the DDNS Keys approach and get the same result as @antonionardella experienced.
As the all.ddnskey.com entry is showing in red then every 5 minutes when the ddns update occurs in IPFire a repeat message is sent to no-ip.
I found the following statement in the no-ip support documentation
Note: Excessive requests to this service will be rate limited. To prevent being rate limited, do not check for an IP update more than once every 5 minutes. If you need more frequent checks please contact No-IP.
plus
Note: Excessive nochg responses may result in your client being blocked.
As the IPFire check frequency is every 5 minutes then it might still work okay without getting rate-limited or blocked. However that 5 min interval is related to the no-ip update API which IPFire doesn’t use.
The nochg responses section does not specify what excessive responses might be considered to be.
However the DDNS logs will get filled with the update attempts every 5 minutes.
1 Like
So I have had the DDNS Key version of no-ip running for around 18 hours now and had 223 log entries for updating the connection because the status does not get picked up with the generic hostname approach.
There has been no rate limiting that I have detected in that time period.
Based on the above I would think that you probably will not have a problem with rate limiting or blocking, although I can’t be certain that won’t change.
The only issue with your no-ip DDNS Key entry will be that the status stays red and never goes green.
A poor man’s work around is to actually use the DDNS key system ( so you dont expose your user / pass) but in IPfire actually put your real own dynamic host name ( Not the all.dnskey.com) , I noted in limited testing it will also update and will in turn keep IPFire happy and turn green in the current host section in ipfire… ill keep it running and see if it gives any errors
2 Likes