os-ddclient

[TheRealBeltet]

Has anyone had success setting up cloudflare with an api token? If so, what's the secret? I got it to work with email address and global api key but I'd rather lock it down to a token that just has dns edit permissions. I've seen some conflicting posts regarding DDClients supportability of cloudflare api tokens.

ddclient does not support this. not in the released version anyways.

https://github.com/ddclient/ddclient/issues/361

Oooooh my god!!!
I totally forgot about that!
I pulled my hair all night because of this! The logs made me believe that there is something wrong with getting the ip.
Thank you!

[thefunkygibbon]

who looks after this plugin from a dev point of view?

[thko]

Hello,

I had hoped that after the update to 22.1.1 this thread has become obsolete.
Especially because now there is the possibility to select "custom" in the settings.
About this I could configure deSEC with the plugin os-dyndns.

Unfortunately, this is probably not possible with the new plugin os-ddclient, because the field "Update URL" to be filled in is not present.

I find this very unfortunate, deSEC (desec.io) is a provider that deserves an entry because it is really, really good.

Thanks for your work anyway.

Greetings

Hi mueller, I got desec working with the following config:

- Services: Dynamic DNS: Settings: General Settings
Enabled [X]
Verbose [ ]
Allow Ipv6 [X]
Interval [300]

- Services: Dynamic DNS: Settings: Edit Account
Enabled [X]
Service [Custom]
Protocol  [DynDNS2]
Server [update6.dedyn.io]
Username [Your Domain]
Password [Your DeSec Token]
Hostname(s) [Your Domain]
Check ip method [Interface]
Force SSL [X]
Interface to monitor [Your WAN Interface]

Still have to wait and see how the automatic updates are working in the next days. But first tests look promising.

cheers
Thorsten

[Mr.Goodcat]

I can't seem to get this working with Hurricane Electric. It would be great if anyone who did could share their configuration :)

Also, it would be great if there were an indicator showing the currently cached IP, just like with the old dynDNS solution. Just so it's easy to check if IPs are being updated successfully.

[slackadelic]

Are you using HE or HE TunnelBroker ?  Really depends which service you're using and what you're using to check the IP to update to their DNS.

If using dns.he.net to manage DNS, the record must be in place and set as a 'dynamic' record.

What steps have you done so far?

[Sakata_T]

So, any updates to the various issues in ddclient?
FreeDNS still doesn't seem to work, though there may be something on my end that I must do.
On the FreeDNS config side, which of these should I be using?

All supported update styles
Randomized Update Token           Default option, simple, secure, my personal favorite.
Username and Password, inline   Username and password as URI arguments, rather then the HTTP authentication
Username and Password           Uses HTTP authentication, if you'd rather use a username/password, some routers like to implement this method or can be most easily adapted to this method
/nic/update                           Uses HTTP authentication, I've seen update attempts like these hitting the server.



Also worth noting that none of these are HTTPS. Not sure if that is or should be a concern?

[Mr.Goodcat]

Are you using HE or HE TunnelBroker ?  Really depends which service you're using and what you're using to check the IP to update to their DNS.

If using dns.he.net to manage DNS, the record must be in place and set as a 'dynamic' record.

What steps have you done so far?

I'm using HE's DynDNS service.

• Service: HE.net
• Username: HE Login Username
• Password: HE Login Password
• Hostname: myhostname.com
• Check ip method: Interface
• Force SSL: Yes
• Interface to monitor: WAN_Interface

The log says "Bad authorization (username or password)", regardless if I use the HE login password or the specific DDNS key.

[slackadelic]

That's exactly what I use and the exact setup.  I have my host.domain.tld and the associated password generated for that host and that's what I use for username and password, works for me.

Strange.

[Mr.Goodcat]

That's exactly what I use and the exact setup.  I have my host.domain.tld and the associated password generated for that host and that's what I use for username and password, works for me.

Ah, so you're using host.domain.tld for both host- and username. Now it works for me as well! Thanks! :D
Previously I set username to the username for logging into HE's DNS service.

Now I'm just stuck at adding Noip as a secondary service :o

[MTR]

So, any updates to the various issues in ddclient?
FreeDNS still doesn't seem to work, though there may be something on my end that I must do.
On the FreeDNS config side, which of these should I be using?

All supported update styles
Randomized Update Token           Default option, simple, secure, my personal favorite.
Username and Password, inline   Username and password as URI arguments, rather then the HTTP authentication
Username and Password           Uses HTTP authentication, if you'd rather use a username/password, some routers like to implement this method or can be most easily adapted to this method
/nic/update                           Uses HTTP authentication, I've seen update attempts like these hitting the server.



Also worth noting that none of these are HTTPS. Not sure if that is or should be a concern?

I tried some different things for FreeDNS and i got it to work using username/password instead of e-mailaddress/token.

[vaygr]

Created an account just to second this:

I wanted to say, from my point of view the ddclient is way behind what is available in the dyndns plugin and I really don't understand who made the decision and why switch to ddclient only, "the world is using it" is, I believe, not a valid reason, especially given ddclient hasn"t seen a release in over a year and ther is definitely a lot less polish and integration into opnsense.

I just wanted to list some of my gripes with the ddclient :

• there is no widget for it on the dashboard
• it does not provide a way to check that the public DNS has the proper IP
• it doesn't play nice with multi-WAN and NAT
• there is no way to force an update
• settings are less granular (general verbosity vs per account, same for checkip provider)
• not all checkip providers that were supported are still provided

There are several threads on this already, but like many others I was surprised a working and really comprehensive solution is being deprecated soon-ish (I think 6 months is inappropriate amount of time for migration) in favor of something that doesn't provide even a half of the "old" functionality. A good comparison would be how OpenBSD handles cases like this: when they rewrite something or throw away old cruft, they make sure the new candidate is better, not worse or at least on par with what the previous tool provided. I'm obviously not active in the development process, but maybe someone could clarify the urge of throwing away current dynamic DNS client now. I fail to see (even from the code maintenance perspective) the priority it's given today.

I understand the desire for OPNsense devs to offload most of maintenance/work to another project, but I don't really see ddclient as a good alternative for current phpDynDNS and what it has to offer. Not in this state. And I'm a little confused about maintenance cycle for this choice then: if OPNsense decided to add missing providers or functionality to the list themselves, will the patches go upstream? Given low maintenance for ddclient (also this), if there's a strategic decision has to be made in the end and current DynDNS client to be deprecated for good, I think inadyn would be a better option (simply because it's Joachim Wiberg – many abandoned projects thrive under his umbrella).

As for me.. I'd be really happy to see Linode DNS support in ddclient with support for subdomains, new API, etc. But even without it: so many good modern providers are there – Route53, Azure DNS, all flavors of Cloudflare, custom, DO, Hetzner; some IPv6-ready. For now I'll likely stay with os-dyndns until it stops working entirely, in which case I'll either fallback to alternatives the community will have ready (like os-dyndns hosted somewhere else) or dig into fixing and maintaining phpDynDNS myself. Because it's too good to die.

[FBachofner]

I'm a new OpnSense user (about 3 days) and first time poster.

I thought I would post something helpful in this thread before pestering anyone with possible assistance requests elsewhere within these forums!  8)

NameCheap is previously acknowledged as working in this thread, but there seems to be no previous detailed instruction set for the "new" os-ddclient.

So, for assistance with getting dynamic DNS in a NameCheap account working with OpnSense, here's the exact "setup-fu"


Connecting OpnSense to NameCheap's "A+ Dynamic DNS Record" service

    Service: NameCheap
    Username: example.com  [ put your TLD in Username _ do NOT use the NC account Username ]
    Password: the "special" NameCheap Dynamic DNS password   [ NOT the NC account password ]
    Hostname: subdomain only [ or @ ... if you want all subdomains routed to this IP address ]
    Check ip method: Interface
    Force SSL: Yes
    Interface to monitor: WAN_Interface


It took me a while to figure out the Username issue as various other DynDNS update clientsI have used have treated this a bit differently!

Hopefully this will help future searchers with any challenges using OpnSense with NameCheap dynamic DNS services.

[Greelan]

Good on you for taking the time to provide constructive information.

What I think would be ideal is for contributors to help expand the official docs as the ddclient plugin is developed. Then all of this sort of information is in one place and easily accessible:

https://wiki.opnsense.org/manual/dynamic_dns.html

Updates can be submitted by PR here:

https://github.com/opnsense/docs/blob/master/source/manual/dynamic_dns.rst

[FBachofner]

Hi @Greenlan

Good on you for taking the time to provide constructive information.

You're welcome!  Paying it forward is great.  I think it is especially important in the open source arena where so many are volunteering in the first place.

I provide a ton of tech support to people who rarely reciprocate with other-kind help and often don't even pay the bills in the case that some are "clients," so I am particularly sensitive to this.

What I think would be ideal is for contributors to help expand the official docs as the ddclient plugin is developed. Then all of this sort of information is in one place and easily accessible:

Interesting.  I thought this sort of detail might be in the docs and actually looked there first, but found it entirely devoid of specific implementation details.

Do you really think that this fine granularity would be accepted?  [ A subsection would need to be added at minimum. ]

[Greelan]

Do you really think that this fine granularity would be accepted?  [ A subsection would need to be added at minimum. ]

I can't speak for the devs, but I can't see why not. I'd imagine it would be similar to the pfSense documentation: https://docs.netgate.com/pfsense/en/latest/services/dyndns/client.html#providers-with-extra-or-different-settings