[GH-ISSUE #49] dns / database cleanup mechanism

kerem commented

2026-02-26 09:35:10 +03:00

Owner

Originally created by @ThomasWaldmann on GitHub (Oct 22, 2013).
Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/49

Originally assigned to: @ThomasWaldmann on GitHub.

if hostnames are orphaned (not updated any more, for a long time), have some means to remove them from dns and database.

same for users who did not use the service for a longer time (and didn't update hosts either).

Originally created by @ThomasWaldmann on GitHub (Oct 22, 2013). Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/49 Originally assigned to: @ThomasWaldmann on GitHub. if hostnames are orphaned (not updated any more, for a long time), have some means to remove them from dns and database. same for users who did not use the service for a longer time (and didn't update hosts either).

kerem

2026-02-26 09:35:10 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-26 09:35:11 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Nov 24, 2013):

problem:

if someone has a (more or less) static IP, his dyndns client maybe does not send updates. either never or not for a long time. so how can we know these hosts are in use still?

@ThomasWaldmann commented on GitHub (Nov 24, 2013): problem: if someone has a (more or less) static IP, his dyndns client maybe does not send updates. either never or not for a long time. so how can we know these hosts are in use still?

kerem commented

2026-02-26 09:35:11 +03:00

Author

Owner

@dklann commented on GitHub (Nov 24, 2013):

Maybe you have considered this, but is it worth the time to at least ping the address? It does not in any way guarantee that the pinged host is the one that submitted the original request, but it at least verifies that the host is up. I have dealt with this issue in the past, and I wish it were required to check in with the dns server on some regular basis. Some clients (e.g., OpenWrt) have a "force update" option to do this, others?

Maybe simply establish a policy that host that have not checked in for [x] {days,weeks,months} are purged?

@dklann commented on GitHub (Nov 24, 2013): Maybe you have considered this, but is it worth the time to at least ping the address? It does not in any way guarantee that the pinged host is the one that submitted the original request, but it at least verifies that the host is up. I have dealt with this issue in the past, and I wish it were _required_ to check in with the dns server on some regular basis. Some clients (e.g., OpenWrt) have a "force update" option to do this, others? Maybe simply establish a policy that host that have not checked in for [x] {days,weeks,months} are purged?

kerem commented

2026-02-26 09:35:11 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Nov 24, 2013):

I thought about pinging, but recognized it is useless.

There is no requirement for any host to answer pings. In fact, for many routers it can be disabled.

If a client does not send updates any more, a ping reply just means there is something at the old address. But it can be anything / anybody. DSL providers usually have a pool of addresses and you get a new address every day. So, your address of yesterday is somebody else's address of today, likely. (And if there is no reply, it also doesn't mean that the host doesn't exist any more, it could be just temporarily offline...)

OTOH, other providers (like cable) give you a (almost) static address - over weeks / months. So the update client does not need to update.

If a update client could be expected to update at least once a week or so (even if IP didn't change) that would help, but I even don't know if that can be assumed / that is assured.

The "you must do X every month" thing is spoiling the dyndns service of other dyndns providers (there, X == log in to our site), so I don't want to do that.

So, the only idea I currently have would be extremely long-term, like if there was no IP update for a year, maybe send an email with a manual update link. If no update happens, maybe send another email a while later. If still no update happens, disable the host (so it can be enabled again by the user via web interface). If there is still no reaction, remove the host.

@ThomasWaldmann commented on GitHub (Nov 24, 2013): I thought about pinging, but recognized it is useless. There is no requirement for any host to answer pings. In fact, for many routers it can be disabled. If a client does not send updates any more, a ping reply just means there is something at the old address. But it can be anything / anybody. DSL providers usually have a pool of addresses and you get a new address every day. So, your address of yesterday is somebody else's address of today, likely. (And if there is no reply, it also doesn't mean that the host doesn't exist any more, it could be just temporarily offline...) OTOH, other providers (like cable) give you a (almost) static address - over weeks / months. So the update client does not need to update. If a update client could be expected to update at least once a week or so (even if IP didn't change) that would help, but I even don't know if that can be assumed / that is assured. The "you must do X every month" thing is spoiling the dyndns service of other dyndns providers (there, X == log in to our site), so I don't want to do that. So, the only idea I currently have would be extremely long-term, like if there was no IP update for a year, maybe send an email with a manual update link. If no update happens, maybe send another email a while later. If still no update happens, disable the host (so it can be enabled again by the user via web interface). If there is still no reaction, remove the host.

kerem commented

2026-02-26 09:35:12 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Nov 24, 2013):

About the requirement to do periodic nochg updates in update clients (which would really help, I agree):

AFAIK avm fritzbox and ddclient have no setting for this.
No idea whether they have some hardcoded time interval for this or just don't do it.

@ThomasWaldmann commented on GitHub (Nov 24, 2013): About the requirement to do periodic nochg updates in update clients (which would really help, I agree): AFAIK avm fritzbox and ddclient have no setting for this. No idea whether they have some hardcoded time interval for this or just don't do it.

kerem commented

2026-02-26 09:35:12 +03:00

Author

Owner

@dklann commented on GitHub (Nov 25, 2013):

Yes, Thomas, I concur of the futility of pinging. I just tossed it out there partly by way of joining the conversation, and partly to stir the pot.

I think your concept of emailing after a year of inactivity is a reasonable one. My experience with Dyn (the organization) is that they've been pretty hands off with respect to cleanup (I use their paid service). So it seems as if doing something in a free service is reasonable!

Let's lobby the clients to add code for periodic nochg updates!

@dklann commented on GitHub (Nov 25, 2013): Yes, Thomas, I concur of the futility of pinging. I just tossed it out there partly by way of joining the conversation, and partly to stir the pot. I think your concept of emailing after a year of inactivity is a reasonable one. My experience with Dyn (the organization) is that they've been pretty hands off with respect to cleanup (I use their paid service). So it seems as if doing _something_ in a free service is reasonable! Let's lobby the clients to add code for periodic nochg updates!

kerem commented

2026-02-26 09:35:12 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Nov 25, 2013):

of course, if you are paying, they won't wake you up and tell you "you don't use this any more". :)

@ThomasWaldmann commented on GitHub (Nov 25, 2013): of course, if you are paying, they won't wake you up and tell you "you don't use this any more". :)

kerem commented

2026-02-26 09:35:12 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Nov 18, 2014):

last_update_ipv4 and last_update_ipv6 have the datetime when the IPs were last updated (check if both good and nochg set the update timestamp).

add a staleness counter and a staleness_notification_timestamp to the host record and regularly run a management script:

T_ip = 330d
T_react = 8d
S_unavailable = 2
S_delete = 4

if has seen ip updates recently (<= T_ip):
    staleness = 0 (default)
elif has last notification happened recently (<= T_react):
    pass  # since we notified, not enough time has passed for owner to react
else:
    staleness++
    if staleness >= S_delete:
        msg = "host was deleted due to inactivity and owner not reacting to notifications."
        delete host
    elif staleness >= S_unavailable:
        msg = "host was made unavailable due to inactivity and owner not reacting to notifications. make it available again by ..."
        host.available = False
        remove host from dns also
    else:
        msg = "host has not seen IP updates since a long time, update its IP by ... or it will be ..."
send notification msg to owner

If user visits the host record on the web ui and staleness is > 0, it should show a warning and tell the owner that he needs to update the IP right now.

It should also show a warning label on the overview.

@ThomasWaldmann commented on GitHub (Nov 18, 2014): last_update_ipv4 and last_update_ipv6 have the datetime when the IPs were last updated (check if both good and nochg set the update timestamp). add a staleness counter and a staleness_notification_timestamp to the host record and regularly run a management script: ``` T_ip = 330d T_react = 8d S_unavailable = 2 S_delete = 4 if has seen ip updates recently (<= T_ip): staleness = 0 (default) elif has last notification happened recently (<= T_react): pass # since we notified, not enough time has passed for owner to react else: staleness++ if staleness >= S_delete: msg = "host was deleted due to inactivity and owner not reacting to notifications." delete host elif staleness >= S_unavailable: msg = "host was made unavailable due to inactivity and owner not reacting to notifications. make it available again by ..." host.available = False remove host from dns also else: msg = "host has not seen IP updates since a long time, update its IP by ... or it will be ..." send notification msg to owner ``` If user visits the host record on the web ui and staleness is > 0, it should show a warning and tell the owner that he needs to update the IP right now. It should also show a warning label on the overview.

kerem commented

2026-02-26 09:35:12 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Nov 21, 2014):

implemented by 13cf70baf6

i also did a first run of "manage hosts --check-stale --notify-user" today:

over 400 notifications sent (quite a lot static or stale IPs!)
a handful bounces (invalid / expired email addresses - please give us a valid and permanent email address, it will only be used for this service! otherwise we have no way to communicate with users in case of problems.)

@ThomasWaldmann commented on GitHub (Nov 21, 2014): implemented by 13cf70baf6909eb99c4805077cfcbc094bc67e9a i also did a first run of "manage hosts --check-stale --notify-user" today: - over 400 notifications sent (quite a lot static or stale IPs!) - a handful bounces (invalid / expired email addresses - please give us a valid and permanent email address, it will only be used for this service! otherwise we have no way to communicate with users in case of problems.)

kerem referenced this issue

2026-02-26 09:36:31 +03:00

[GH-ISSUE #240] Meta issue: change accounts stuff #204

Rows
Columns

[GH-ISSUE #49] dns / database cleanup mechanism #47