deSEC.io / dedyn.io DynDNS now supports avoiding overwriting entries with dual stack IP4/6

JeGr

Hi there,

I was testing the DynDNS and Acme integration with the nice folks from deSEC.io and happen to stumble upon a problem with their API.
While having IPv4 AND IPv6 configured as DynDNS services in pfSense, one entry overwrites the other. So if IPv4 gets reloaded, the IP4 entry for e.g. test.jlab.dedyn.io is there. After the IPv6 refresh from the dyndns page runs, the IP4 vanished from the name and only the IP6 AAAA entry is there. The same was the case when refreshing v4 - A is there, AAAA gets removed. That's as per their API documentation but as pfSense doesn't support (yet?) to update both it's IP4 and IP6 at the same time.

So I kindly asked them if there was a way to configure the way the API handles calls to the same host/domain entry with changes to A/AAAA behavior and they quickly added a new parameter called preserve to their API:

https://desec.readthedocs.io/en/latest/dyndns/update-api.html

It now states:

For IPv4, we check the query string parameters myip, myipv4, ip (in this order) for an IPv4 address to record in the database. When the special string preserve is provided instead of an IP address, the address on record (if any) will be kept as is. If none of the parameters is set, the connection’s client IP address will be used if it is an IPv4 connection; otherwise the IPv4 address will be deleted from the DNS. IP deletion can also be forced by providing an empty value (e.g. myipv4=).

For IPv6, the procedure is similar. We check the myipv6, ipv6, myip, ip query string parameters (in this order) and the IP that was used to connect to the API for IPv6 addresses and use the first one found. The preserve rule applies as above. If nothing is found or an empty value provided, the AAAA record will be deleted.

So two questions actually:

Could this option please be included into the DynDNS Module for deSEC.io so we can toggle the behavior as needed?
Would it be possible to include a IP4/IP6 Module that submits both values at the same time (as their API allows) so we don't have to add multiple "services" for the same address/job?
Could we add a generic Custom (v4/v6) Job so we get a custom one where we have access to both the interfaces IP4 AND IP6 address? Currently it's either or and the %IP% variable is filled accordingly but there are more and more services that support proper dual-stack handling and it reduces unnecessary multiple connects to the same service over and over again to update IP4 and IP6 entries of perhaps multiple domains/hostnames and thus reducing runtime of the background job.

Cheers
\jens

jmpalacios

Hi @JeGr,

Did this request ever see a resolution? Or did you happen to figure out a way around the limitation?

I'm facing this problem right now, trying to update deSEC domains via dynDNS on pfSense 2.7.2, and there are still no IPv4 & IPv6 bundle update nor preserve options, so configuring separate IPv4 and IPv6 update services runs into this problem of one IP update wiping out the previous one.

Thank you!

JeGr

@jmpalacios I'm not currently aware, if that change has made it into the official DynDNS config, but you can still add that as a custom v4 and custom v6 config without much problem. I've done so myself in the meantime an it's working great.

Just don't use the desec v4/v6 option but use "custom v4/v6" instead. Also you really should update to 2.8.1 :)

Cheers
\jens

jmpalacios

Hey @JeGr ! I was working towards a 2.8.1 upgrade, experiencing non-trivial problems with my VLANs setup, which didn't pass traffic among them after the upgrade for undetermined reasons, but I've finally managed to solve that after so much toiling setting up a test router and replicating my setup there, and now the 2.8.1 upgrade is finally complete and fully functional!

And now I'm ready to receive your wisdom on setting up dynDNS for simultaneous IPv4 & IPv6 updates against deSEC! ;)

jmpalacios

I'm working in creating a Custom (v6) dynDNS configuration, but I'm a bit stuck on how to configure it.

In the update URL field I'm working with a value of:

https://update6.dedyn.io/?hostname=$myDomain&myipv6=$ipv6Value&myipv4=preserve

But I don't know how to pass the IPv6 value that my pfSense router obtains dynamically from my WAN interface.

An alternative, if I'm reading correctly the deSEC docs, is to completely leave out the myipv6 parameter for deSEC to determine my IPv6 from the HTTP request, which I can only imagine would come from my WAN interface, and hence use its IPv6 address, but I'm not sure if this is a good approach…

Thanks for any insights!

jmpalacios

Got it!

https://update6.dedyn.io/?hostname=$theDomainName&myipv6=%IP%&myipv4=preserve

With the %IP% literal placeholder replaced by pfSense upon sending the request, as documented by pfSense itself. However, the trick of fully leaving out the myipv6 parameter for deSEC to obtain the IPv6 value from the HTTP request also worked!

Further, the result match (i.e. the HTTP response from the API call to deSEC) should be the literal value of good, per deSEC's documentation, as otherwise pfSense will fail to realize the IP has been updated successfully.

And, lastly, the username should be set to your deSEC email address and, needless to say, "Force IPv4 DNS resolution" should be disabled when using deSEC's update6.dedyn.io API, as that FQDN cannot be resolved via IPv4.

jmpalacios

The corresponding deSEC dynDNS update URL for IPv4, if for completeness' sake you also want to switch that dynDNS client to a custom script, so that the otherwise non-custom client doesn't fully wipe out your recently updated IPv6 information from your deSEC domain, would be:

https://update.dedyn.io/?hostname=$yourDomainName&myipv4=%IP%&myipv6=preserve

And everything else would be the same as for the IPv6 deSEC custom dynDNS client, i.e. username being your deSEC email address and "Result Match" being the literal keyword good. The only thing that'd be different is that, in this case, you might want to enable "Force IPv4 DNS Resolution".

JeGr

@jmpalacios As you got there yourself, there's not much for me to add. Congrats :)

For everyone else wondering, how to build that with Custom checks and DeSec, here's the short version:

Add both, a type "Custom" and "Custom v6" Dynamic DNS check with the following infos:

Service Type: Custom / Custom (v6)
Interface to monitor: <WAN> (your interface with the WAN address)
Interface to send update from: <WAN>
Check IP Mode: Automatic (if your public IP is NOT on the WAN interface but another router in front, choose "always" here)
Force IPv4 DNS Resolution: yes (only for the Custom check, not the v6 obviously)
Username: enter your Domain to update here, as it is used for HTTP-Auth user/pass
Password: enter DeSec Update Token here
Update URL (v4): https://update.dedyn.io/?hostname=<domain>&myipv4=%IP%&myipv6=preserve
Update URL (v6): https://update.dedyn.io/?hostname=<domain>&myipv6=%IP%&myipv4=preserve
Result Match: good
Max Cache Age: this depends on your ISP. If you have daily disconnects, you can use 1 here to force the dyndns agent to force an update after one day regardless of it witnessing a change in the IP or not

That's it. With 2 jobs separately updating the domain without one overwriting the other you are ready to go.

Cheers

jmpalacios

@JeGr Thank you!

Only note, though, is that the URL of your Custom V6 instructions is wrong, as you're using the IPv4 update.dedyn.io FQDN but you need to use the IPv6 update6.dedyn.io FQDN.

JeGr

@jmpalacios That's not entirely true but not wrong either ;)
update is dual-stacked with IP4 & IP6 configured records, so you can simply use that one for both. Alternatively you can use update6 for explicitly using an IP6 connection.
(Also mentioned in the first paragraph of the docs: here)

As we configure the custom checks to call the IP as GET parameter anyways, the connection path to desec isn't that relevant as if you'd leave out the myipvX parameter to resolve the IP "automagically". If you'd use auto-detect and want to ensure it's the IP6, then that's true. In our case you can use both or switch to update6 however you like, as we don't rely on the connection itself to detect our public IP. :)

Cheers :)