’m running an OPNsense firewall in my home lab. The firmware 23.7.9-amd64 is currently installed. The firewall get a dynamic IPv4 address and a IPv6 subnet from my ISP.
First I installed the ddclient package and set it up using the documentation:
Below a screenshot of my settings:
The result is, that in the specified DNS zone a IPv4 and IPv6 record was created. After that i have a closer look into the logfile of the ddclient. Only the IPv4 address is transmitted there.
2023-12-05T14:50:01 Notice ddclient SUCCESS: updating test.domain.de: good: IPv4 address set to 184.108.40.206
2023-12-05T14:50:01 Notice ddclient RECEIVE: good
2023-12-05T14:50:01 Notice ddclient RECEIVE:
2023-12-05T14:50:01 Notice ddclient RECEIVE: strict-transport-security: max-age=31536000
2023-12-05T14:50:01 Notice ddclient RECEIVE: vary: origin
2023-12-05T14:50:01 Notice ddclient RECEIVE: allow: GET, HEAD, OPTIONS
2023-12-05T14:50:01 Notice ddclient RECEIVE: content-length: 4
2023-12-05T14:50:01 Notice ddclient RECEIVE: content-type: text/plain
2023-12-05T14:50:01 Notice ddclient RECEIVE: date: Tue, 05 Dec 2023 13:50:01 GMT
2023-12-05T14:50:01 Notice ddclient RECEIVE: server: nginx
2023-12-05T14:50:01 Notice ddclient RECEIVE: HTTP/2 200
2023-12-05T14:50:01 Notice ddclient SENDING: url="https://update.dedyn.io/nic/update?system=dyndns&hostname=test.domain.de&myip=220.127.116.11"
2023-12-05T14:50:01 Notice ddclient SENDING: user="test.domain.de:K2Yoxxxxxxxxxxxxxxxxxxxxx22w"
2023-12-05T14:50:01 Notice ddclient SENDING: request=GET
2023-12-05T14:50:01 Notice ddclient SENDING: max-time=120
2023-12-05T14:50:01 Notice ddclient SENDING: connect-timeout=120
2023-12-05T14:50:01 Notice ddclient SENDING: user-agent="ddclient/3.11.1"
2023-12-05T14:50:01 Notice ddclient SENDING: include
2023-12-05T14:50:01 Notice ddclient SENDING: silent
2023-12-05T14:50:01 Notice ddclient SENDING: Curl system cmd to https://update.dedyn.io
The value of the IPv6 entry in den deSEC UI is correct. It’s the same one as currently on the WAN interface.
Now I’m a bit surprised why the IPv6 address is sent to deSEC at all. Because
- The value of the parameter “Check ip method” on the ddclient should only return the IPv4 address.
- The logfile of the ddclient tells the same thing.
- I have already tried another entry for the parameter “Check ip method”. Still the same result.
At the moment I only want to have an A Record for the firewall. What did I miss during the configuration?
i’m not sure that I understood the documentation right. Initially there is no A and AAA entry for test.domain.de in the DNS zone.
For IPv4, we check the query string parameters
ip (in this order) for IPv4 addresses to record in the database.
That applies to my question. The ddclient uses the parameter myip. The only value is my IPv4 address. Another request that contains the IPv6 address of the WAN interface cannot be found in the log file.
For this reason, I changed the value of the “Check ip method” parameter in the ddclient to “nsupdate.info-ipv6”. Then deleted A and AAA entries in the deSEC UI and started another update process. With this configuration only a AAA entry is created - no A entry.
This is currently not logical and comprehensible to me. My expectation is that only the A entry will be created based on the log file.If it is really supposed to work as I have described it, I would be happy if you could explain to me an error in my thinking.
From the docs:
For IPv6, the procedure is similar. We check the
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. Both the multi-IP syntax and the
preserve rule apply as above. If nothing is found or an empty value provided, the
AAAA record will be deleted.
It seems like you’re making the update request via an IPv6 connection, which causes that address to be configured in an AAAA record. You can prevent that by adding an empty
myipv6= parameter to your update URL path.
Does that help?
hat’s right, it’s a DualStack. Is there anything else today?
I saw this notice. But at current version of ddclient or OPNsense UI there is no parameter to configured that. So the only way is to modify the ddclient configuration file directly over ssh?!
I don’t understand the logic yet. I have configured the ddclient so that only an A entry should be created/updated. The GET request executed by ddclient reflects this 1:1. In the end I still have a AAA entry in the DNS zone because the update to the API takes place via an IPv6 connection. What is the background to this type of implementation?
I’m asking because my two current providers for DynDNS behave differently. There I have a configuration in the ddclient for IPv4 and IPv6. This makes it possible to control granularly which FQDN names get IPv4 and/or IPv6 entries.
It allows the client to send an update request without having to look up its own public-facing IP address.
No, the description of the
Server field in your screenshot says that it accepts a URI. Try something like:
Is an argument. I’m not alone with the interpretation how it should work: Link
Of course I have already tested this. However, the implementation of “Custom GET” is flawed. I tried several URLs for the “Server” parameter and the call looks like this:
2023-12-06T11:15:52 Notice ddclient WARNING: file /usr/local/etc/ddclient.conf, line 10: Invalid Value for keyword 'protocol' = 'get'
2023-12-06T11:15:52 Notice ddclient SENDING: url="http://https://update.dedyn.io/nic/update?hostname=test.domaina.de&myipv6=&myip=__myip__&password=dummy/nic/update?system=dyndns&hostname=test.domaina.de&myip=18.104.22.168"
2023-12-06T11:35:34 Notice ddclient WARNING: file /usr/local/etc/ddclient.conf, line 10: Invalid Value for keyword 'protocol' = 'get'
2023-12-06T11:35:34 Notice ddclient SENDING: url="http://https://update.dedyn.io/nic/update/nic/update?system=dyndns&hostname=test.domaina.de&myip=22.214.171.124"
I looked at the article for HE on the OPNsense forum. It doesn’t look like you can define a variable. Only the URL to the update process. But i’m not sure, if the descrpiton of the parameter is old or function which built the uri string is faulty.
The way I see it, I would have to file a bug ticket with the OPNsense Project and hope that the developers fix the error in a timely manner.
I founded at the ddlient project an issue with the wish to add deSEC as serivce. Unfortunately this has been closed (no commit, no pull request). Do you happen to know more about it?
The solution for OPNsense is, that the for ddclient the backend must change from ddclient to native.
After that change it exists for deSEC service templates (desec-v4 & desec-v6).
So it is possible to control if an A or/and AAA record should be created.
Do not forget to enter a valid API Token into the parameter Password.
Long-term test is still pending…
Unfortunately, A and AAAA entries are still generated.
Basically, I find the whole thing misleading. If I select a service in which v4 can be read, I expect that only the A entry in the DNS is created/updated. The same for v6.
The behavior of update.desec.io may have been revised in the recent past without adapting the clients, in this case ddclient?!
Therefore a suggestion for improvement:
- Publish a new FQDN update4.dedyn.io to create/update only the A record in the dns zone. Regardless of whether the update takes place via an ipv6 connection.
- Revise the service “desec-v4” in the ddclient and replace the FQDN with “update4.dedyn.io”.
- Addin new service in the ddclient named “deSEC” which uses update.dedyn.io. To reflect previous behavior (Create/Update A entry and AAAA entry if is a ipv6 connection.
What do you think of it?
I agree. It seems like your router’s “desec-v4” service is implemented in a way that doesn’t make sense when using that name. However, we didn’t implement your router’s software. The fix should be done there.
No, our endpoints have been like this since 2015.
Regarding your suggestions for improvements in ddclient, this is the wrong forum. Please contact their or your router community’s forum.
I like to do. However, this assumes that deSEC provides the address “update4.dedyn.io” as described. Otherwise there is no point in investing time.
No. As explained above, the desired behavior is achieved by adding an empty
myipv6= query parameter to the update request.