People are being told the terms provide “an explanation” about the purging of accounts in 6 months intervals.
Depending on what, in the days of Corona, actually counts as explanation, I read:
“Dynamic DNS domains that are not updated for six months or longer will be deleted after a warning with 4 weeks notice. Owners can prevent deletion by updating DNS information.”
Well, what does this explain? Is it about the inevitablity of allowing to free up resources for active deSEC
users?
The criterion for the purge is the “altering of DNS records”. Well, once an e-mail system is set up properly, there is no need to change any records, as many people will be aware of.
So that criterion seems a little far-fetched when it is supposed to prove “inactivity” of a user – since in fact it is what an active zone user would typically do, once all is working in his zone: just use the zone, but not change it.
It should be clear that under this policy, users will not necessarily consider dedyn.io a “rock-solid” provider, when they risk getting their zones trashed on grounds like these. But maybe it is going to save a whole lot of electricity thereby stopping global warming.
As I ran into the situation before, I can confirm it is not required to alter the zone or even to log in - when you get an inactivity warning email there is a link inside to confirm that you are in fact not inactive, and after clicking it, the domain will not get deleted.
Getting rid of “old accounts” like this is common practice for many free services I’m using (and I don’t know if they actually all write it in their TOS that they do so). And twice a year seems to be reasonable for me.
Not treating a “dyndns” domain inactive if there have been updates (which will likely happen within 6 months in case you use the domain for the “dyndns” purpose) is just a convenience for some users (and it also can be used for easy automation in a cron job to avoid the situation to even happen).
It might not save much electicity, but it may save them from having to buy new storage once their zone file is filled with millions of unused domains. (If you pay for a service, you will generally cancel that subscription when you don’t need it any more. Free services often just get forgotten.)
That being said, I’m just a user, and I cannot complain about the great service you are providing.
I have a question about the expiration of domains as well.
I’m planning to set-up a sub-domain on deSEC which will resolves to a static LAN IP address. The purpose is to enable TLS in my home network for a couple of internal apps using an ACME client.
Since the IP address is static and will not be updated for a long time, I will likely run into the 6 months expiration down the road.
I understand that I will receive an automatic email from deSEC four weeks before the domain gets deleted. But I was thinking if there is something I can do before to reset the six-month counter.
Would it be sufficient to occasionally log in to my desec.io account occasionally to reset the counter? Or do I have to change the A record to reset it?
The automatic expiration is not a huge headache and I think it’s a sensible policy. Nevertheless, I would be relying on the domain working as expected to access a number of services for home automation, and not everyone in my household is eager to learn about DNS and other technical topics, so I’m trying to make it as reliable as possible
Please remember that this applies only to domains under dedyn.io, and the name component dyn stands for Dynamic DNS. This is to allow residential users whose IPs keep changing to associate a constant name with their dynamic IP address.
This is explained already in the sign-up form:
dedyn.io is not a general-purpose domain registry. If your IP is not changing, then your usage is not coverage by the purpose, and we reserve the right to terminate service. You may consider these terms arbitrary, but that’s how it is with free services: terms are not up to the user.
For extra justification, consider that each registration leads to 7 records in the dedyn.io zone, so the zone currently has about 140,000 records. It would be much larger without this expiration policy.
Do you have experience with the operational challenges for such large zones? If yes, we’d like to invite you to submit a pull request to optimize the zone handling so that we can drop the expiration policy. If no, please refrain from premature conclusions. (You’re of course invited to ask questions.)
No.
You’ll have to change some record in your domain, not necessarily the A record.
Thank you for taking the time to reply to my question. I totally understand that you are working with limited resources and think that your policy is sensible.
I already have one dedyn.io subdomain that points to the public IP address of my DSL modem. Works very well, even though my modem (Fritz!Box, DSL) only reconnects very rarely. Last time I got a new IP was almost 80 days ago.
Maybe I’ll try to use the existing dedyn.io sub-domain then to get the TLS certificate, and not a separate one, as I planned earlier.
For the record, I have donated to your society in the past, and will do so in the future, when my budget allows. Thank you for providing this very useful service!
Indeed: if you perform domain validation via DNS ACME during certificate issuance every few months (Let’s Encrypt: at least every three months), that would also prevent your domain from expiring.
Indeed: if you perform domain validation via DNS ACME during certificate issuance every few months >(Let’s Encrypt: at least every three months), that would also prevent your domain from expiring.
Proven - no.
a) TXT Update: I have periodically ACME let’s encrypt Updates for with the TXT record method to get a new certificate. usually two times per week to deal with lets encrypt downtime / overload / other problems
b) subname Update: I have daily Updates from an FritzBox for a daily changing IP in a subname -
The updates (subname + TXT) did not prevent the deletion of my domain.
by the way: the TXT entry will be changed during the acme update and deleted after certificate renewal. and the IP address did only change for an subname. So i will try to add a “A” field into the domain itself. Probably this will help to prevent the deletion.
and yes: a did not add my pc as pcname.dedyn.io, but I added and domain and the a subname. I thought this is the best way to handle a dynamic IP together we lets encrypt TXT method. And I have the ability to handle a parallel 5G mobile access in the same domain, when 5G will every reach my region. good idea to handle it this way?
delete was familyname.dedyn.io
but
vdsl_pc_name.familyname.dedyn.io
was still existing!
So i guess that the subname updates don’t count as “activ” usage of the familyname.dedyn.io domain.
And the TXT records for lets encrypt don’t count, because the TXT “acme_” entry will be deleted after renewal of the cert.
When dessec check the content of familyname.dedyn.io domain in a batch job (compare yesterday/today) there are no changes, if the change of an IP address of a subnames count only for the subname domain and the create + deletion of TXT records are not included in the comparison.
I hope my additional type A entry in familyname.dedyn.io will solve this problem.
If you create one domain only in the the web interface, addition and removal of records with non-empty subname field does count as use of the domain.
However, when you create to different domains, then usage of one domain does not affect the other. This also applies when one domain is a subdomain of the other. Perhaps this is what happened to you?
