many services follow the dyndns2 protocol, so the question is whether one really needs one support module per service just for the sake of the different update url.
many routers (e.g. the fritzbox) offer generic support and you can just give the update url, so it'll work with any service compatible to the selected protocol (which i think is even hardcoded dyndns2 in the case of this router).
to make it even more flexible, you can give multiple update urls to e.g. update the v4 and the v6 address, e.g.:
as there is no querystring with placeholders given (for ip address and hostname), it just uses the url "as is" (and does the required http basic auth taken from username and password params).
in our case, this is all that is needed, as username == hostname for nsupdate.info service and the IP is just the remote address seen by the service.
btw, we intentionally did NOT use the service login username/password as many routers do http, so we did not want to risk disclosure of the more important login password. so we just have the hostname as "username" for updates and a separate, autogenerated random secret as "password".
ipv4.nsupdate.info is v4 only, ipv6.nsupdate.info is v6 only, so this just works as it will for sure see the right remote IP (assuming you want the router ip in dns).
fixes #2 (logs an automatic warning), #4 (service_url can now be
specified) and #8 (CLI help lists all protocols)