I realized that ddns-scripts go into an infinite loop if DNS does not resolve. It keeps looping
Get registered/public IP for 'blah.dy.fi' failed
Obviously it can never work if it does not try to update it at least once so it starts working.
I am curious how come nobody else had this problem? I made an issue ticket on github. Please comment if you have any suggestions on fix.
At least my DDNS service provider (HE) starts responding to DNS requests for my domain name after I add it on their web site (which I need to do before I can send any DDNS request). Maybe it's the same with most DDNS services.
The DDNS client is designed to work with already registered domain names. The simple fix to your 'issue' is to register the required domain name with your DDNS provider first.
Because you need DNS resoultion for DDNS.
You are describing a programmatic chicken-or the-egg paradox.
Am I missing something?
DDNS give your dynamic Public IP a "static" hostname. What issue are you trying to resolve?
I assume you meant:
Yes, but adding it to website does not automatically set the IP. I could be adding it from a different connection for example. Also, even after adding, if the IP was not refreshed it can be deleted. Maybe the DDNS provider had an issue and the setting got reset and it requires refresh of the IP.
See the following screenshot from dy.fi where one entry is unused(because it was not refreshed in certain time) and another will expire in little over 6 days. When an entry is released(become unused), it is removed from DNS, BUT it can still be refreshed by ddns-scripts and it is put into use again automatically.
This is not the problem. In my case, it is already registered but it was expired as it did not receive an update. The DDNS script was in infinite loop because DNS did not resolve. Please see the reply I wrote to @mikma
Registering to the site does not guarantee IP address assignment to domain. It only occurs if point/refresh links are used. Even so, it might expire due to various reasons and you end up DNS not resolving.
But even if it is not resolved, you can update it to make it start resolving. But the current DDNS scripts simply go to infinite loop of not resolving and never try to update it.
If DNS does not resolve, or if the DNS resolves to different IP. The script should try to update DNS to point to correct IP. Currently it does that only if the latter occurs.
It is not a chicken-egg issue. If the DDNS does not resolve, it can be updated. You might need a chicken to produce an egg. But if the DNS does not resolve. You can still update DDNS provider with correct IP. You do not really need it to be resolving before doing the update. Then it will start resolving.
I am saying that DDNS script should try to update the DNS if the IP is incorrect OR if the DNS does not currently resolve. Currently it does force update if the IP is different than what it should be (eg. incorrect). But not if the IP is nonexistent (which is in essence same as being different, isn't it?)
The issue I am trying to solve is that I was away from the site and all of a sudden I realized the DNS was not resolving. I had to take manual actions. Because restarting the DDNS scripts in OpenWRT did not help. As the DNS entries were expired, DDNS scripts were just looping at nslookup failure and never tried to update the IP. I had to manually update the IP before they started working. Is this kind of confusion and manual work really necessary? For what purpose the script should not refresh the IP if DNS currently does not resolve?
The fact is I would have understood if it tried to refresh the IP and site refused it, then it could throttle back perhaps. But just looping nonsensically at nslookup makes no sense whatsoever.
No. Do as the dy.fi website advises and set the DNS client to update if the IP changes or, if there are no changes, 5-6 days after the last update.
and if for some reason it was not updated after 5-6 days(I mean if 7 days is up), and DNS entry was moved to unused/released? then how will it get resolved? the ddns-scripts will get into an infinite loop and won't be able to recover, right?
I understood your statement to me, I didn't realize you were referring to the DDNS account/domain itself.
Then, your response to another poster confused me again:
Are you saying your domain was removed from your DDNS account, and hence doesn't exist?
Surely you understand there's no sensical reason the app should procees non existing accounts/domains?
If so, please clarify at what point you had an issue or explain where a problem arose with the OpenWrt.
It was not removed from DDNS account. The DDNS provider moves the domain to unused/released state after 7 days of non-update. (this means that it is suspended, and can be activated simply by sending an IP update request). DDNS provider says you should send force-updates every 5-6 days, on their website, to avoid this from happening.
So the domain can be released(become unused) accidentally. For example, if after 5 days you had OpenWRT device down, or network problems for 2 days for any reason.
For example in my case, OpenWRT was down because I was moving to another hardware. Then I assumed DDNS would continue working, but after leaving the site I found out that it was not.
There was no reason for it to loop in nslookup failed state. It could try to send refresh request to the DDNS provider and everything would be working again. This is a bug. It should have recovered from this state easily.
Yes, there can be other cases where people do not have the correct settings in DDNS provider, or wrong domain etc. (these are NOT same as my case) But, in those cases DDNS provider would error/reject the update with an error. So ddns-scripts can easily detect that and behave accordingly.
Is there a good reason for why it gets stuck in loop simply because nslookup failed? (instead of trying to refresh the IP?). If there is a reason, of course I would understand that maybe it is not so simple to fix this issue.
Is the issue more understandable now?
When your domain is 'suspended', what happens with the DNS resolution (i.e. from a client anywhere on the internet)? Does it just fail as domain not found?
I suspect that it was an intentional decision in the development of the ddns scripts to make sure that a domain exists before it attempts to update it. This does two things:
That said, you should be able to modify the script, or create a pre-cursor script that does a DNS probe and sends an update if there is a DNS failure.
Yes.
You'll need to configure your DDNS within this time frame, to update regularly in this 7-day period. What you describe seems normal with most DDNS company policies, although 7 days is short IMHO.
The rest of your description is merely semantics if the DDNS provider makes the domain/account unusable with a client after 7 days. How can the app update if your account is already suspended?
If you wanna share your configs from /etc/config/ddns - omitting identifiable information, accounts, etc., it would be helpful.
When it is suspended is not possible to resolve it anymore. So nslookup simply fails. I was quite upset to find that ddns-scripts failed like this, because I was at a remote location when I realized this. It was not so great surprise.
1- Sure, but a failed nslookup has little to do with correct settings in DDNS service. It just says that currently the DNS does not resolve. Possibly because IP was never set in DDNS service?. Incorrect settings can be detected using a failed update. Because update will obviously be rejected by the DDNS provider. Yes, it will require 1 request, but then the script can throttle back accordingly so it won't SPAM the DDNS provider. Even if nslookup works, the scripts should detect this and throttle back anyway. Because the user could have entered a wrong password etc.
2- This is true. The script checks if resolved IP is same as current IP, and it does not update it if they are same. But, logic says that if there is no resolved IP, then empty is not equal to current IP. Therefore it requires update.
Yes, I did modify the script now so if nslookup fails, it exits the nslookup loop and starts main loop and the DDNS gets updated. Obviously this is not a permanent solution if similar change is not accepted to the repository. Now I realize that it is quite hard to explain the problem to people... probably because people did not realize this rare bug as some unlikely elements should come together to cause it.
Is the reply NXDOMAIN - or something else?
i.e. are they deleting if from the Global DNS, changing it, etc.
Your logic is flawed here.
Empty and not resolved are 2 different states in DNS.
A domain must exist Globally - and you're not being clear on that point out of frustration of your DDNS Provider's 7-day policy..
I already told how this works. If the domain is suspended due to missing update period. It will be activated if the ddns-script sends the refresh IP request. Easy to understand how it works, right? 
I did NOT say that account was suspended. Only the domain entry which did not receive an update for 7 days gets released/unused. Then it won't resolve nslookup in this state.
I already explained this. I had the OpenWRT device down for a few days because I was changing hardware. When I turned it back on with new hardware, it could not update the DDNS entries. Because the 7 days was up and nslookup was failing.
Did you not read my response? Because I thought I already explained this very clearly.
OpenWRT ddns-scripts should have simply sent the IP refresh request to avoid this problem.
Too bad they don't just set some invalid IP (like an RFC1918 address or 0.0.0.0 or whatever).
That is really frustrating, I'm sure.
I don't disagree with this in principle, but I think that you might be hitting an edge case. I'm willing to guess that most providers have a much much longer window before they force expire/suspend the IP address. Often, upon creation, many services will offer to populate with the current IP (i.e. from your computer)... this way the record exists immediately (aside from dns propagation delays). So for most providers, it is probably not a bad assumption to say that the DNS record should return successfully if the account is even close to current.
The other thing that the dns lookup can do is to help ensure that you have functional network connectivity to the internet and working DNS, again before it goes further in the script where it might fail anyway.
All that said, the next suggestion won't solve the problem at a root-cause, but may prevent it from beng a practical issue for you: switch ddns providers. Unless there is a reason you want to use this particular one, you may find that others are better for your needs if there is a risk that this 7-day expiry could bite you unexpectedly in the future.
Finally, the script itself is running as written (and presumably working as intended by the authors). I don't think that there are any true bugs here, nor do I think that OpenWrt broadly has anything to do with this problem. However, it's not unreasonable to reach out to the maintainers of the ddns script to propose changes to the way it works.
When I mean domain, I mean the XXX.dy.fi the XXX part. The domain dy.fi exists globally. We are talking about the host part.
Yes I did, hence, I and other posters asked:
Lastly, I'm not understanding how you want the OpenWrt:
Please clarify how we un-suspend your account?
Then please answer to help solve lookup problem:
"Suspended" means nothing - We need to know what Global state the hostname is in when this occurs.