[GH-ISSUE #450] Allow services updates without RFC2136 #326

New issue

Closed

opened 2026-02-26 10:30:53 +03:00 by kerem · 2 comments

kerem commented

2026-02-26 10:30:53 +03:00

Owner

Originally created by @lkraider on GitHub (Jan 7, 2020).
Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/450

So this is a question for the project: would it make sense to allow enabling only the dyndns2 service update functionality for hosts on domains that don't support the RFC2136?

I feel most of the infrastructure is there to support this, and I even started building a custom update service (I have some domain providers that don't support dyndns2 protocol nor RFC2136).

As the system is right now, the RFC method is first class citizen, and the dyndns2 service is ran just after the update worked and mostly has no feedback for the user.

But both methods could be abstracted into a general interface, with the same error treating and retry functionality.

So I am asking: Do you think this makes sense for this project?

Originally created by @lkraider on GitHub (Jan 7, 2020). Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/450 So this is a question for the project: would it make sense to allow enabling only the dyndns2 service update functionality for hosts on domains that don't support the RFC2136? I feel most of the infrastructure is there to support this, and I even started building a custom update service (I have some domain providers that don't support dyndns2 protocol nor RFC2136). As the system is right now, the RFC method is first class citizen, and the dyndns2 service is ran just after the update worked and mostly has no feedback for the user. But both methods could be abstracted into a general interface, with the same error treating and retry functionality. So I am asking: Do you think this makes sense for this project?

kerem closed this issue

2026-02-26 10:30:53 +03:00

kerem commented

2026-02-26 10:30:53 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Jan 7, 2020):

Well, currently it all revolves around the Host object (which represents some hostname.nsupdate.info host), so having that without actually updating the dns for that host would be strange.

But I get your idea. There could be a somehow unnamed / anon object for a host that has a list of updaters:

for one or more hostnames on rfc2136 nameservers
for one or more hostnames on dyndns services

That would be a more symmetric approach, but require a quite big internal restructuring + a DB migration procedure.

So while that would have been a nicer architecture to start from, I am not convinced that it is worth all the required work to migrate to that now.

@ThomasWaldmann commented on GitHub (Jan 7, 2020): Well, currently it all revolves around the `Host` object (which represents some `hostname.nsupdate.info` host), so having that without actually updating the dns for that host would be strange. But I get your idea. There could be a somehow unnamed / anon object for a host that has a list of updaters: - for one or more hostnames on rfc2136 nameservers - for one or more hostnames on dyndns services That would be a more symmetric approach, but require a quite big internal restructuring + a DB migration procedure. So while that would have been a nicer architecture to start from, I am not convinced that it is worth all the required work to migrate to that now.

kerem commented

2026-02-26 10:30:53 +03:00

Author

Owner

@lkraider commented on GitHub (Jan 7, 2020):

Thanks for the response! I'll close this issue for now.

@lkraider commented on GitHub (Jan 7, 2020): Thanks for the response! I'll close this issue for now.

kerem referenced this issue

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

[PR #326] [MERGED] Add missing closing div after dyndnsc sample configuration #461