ddclient
ipv4 and ipv6 at the same time?
Greetings.
Maybe it's my setup, but I can't update ipv4 and ipv6 at the same time.
Right now, I'm using if=eth1 for my IPv4 interface and if=sit1 for my IPv6 interface. I can't figure out how to configure a single ddclient.conf file to use different interfaces for different versions.
The problem with this is ... when you update DynDNS's ipv4 address, it clears the ipv6 address. So I'm hoping that if a single ddclient command can manage both, then I won't have that problem.
Thanks.
Great question. We'll need to look at the api docs to see if this is possible. Shame that DynDNS doesn't have any test accounts to play with.
We'll take a look at it.
https://help.dyn.com/rest-resources/
I recommend that you take a look at this version of ddclient which we forked some time ago specifically to add better support for ipv6... https://github.com/astlinux-project/ddclient-curl This adds the capability to set both ipv4 and ipv6 for a single domain in the conf file.
Just a followup to my previous - I tried the fork - it works fine but the concurrent update problem for me is actually a limitation of the Google API (after inspecting the code and the info Google has on the API available). It might be useful to add a bit of commentary to the different protocol verbiage perhaps? Thanks for maintaining the tool.
Maybe we should try upstreaming those changes.
Yes I would like that. But requires adopting cURL for all network rather than perl's built in functions. As noted elsewhere, we (@abelbeck and I) determined that this was the cleanest approach to numerous problems with mixing IPv4 and IPv6. David
Personally, I think not making system calls to curl is nicer.
I’ve been thinking about it. Is there an ip lookup service that only response in ipv6, such as myipv6.com, or whatever? We wouldn’t need curl’s -6 flag if the service you access is only ipv6.
On Oct 21, 2019, at 6:36 AM, Sandro [email protected] wrote:
It's there anything against adopting curl over time?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.
I personally use this but it has several downsides: you need to know your main interface and have ip installed which could be a problem on older systems.
ip addr show dev eno1 | sed -e's/^.*inet6 \([^ ]*\)\/.*$/\1/;t;d' | head -1
or this could help https://ifconfig.io/
This would only work if your machine was assigned the ipv6 address directly, not using any NAT. For server, it's probably the case. I don't have ipv6 at home yet, so I don't now if people are using NAT with ipv6? Any ideas?
On 10/21/19 9:54 AM, Sandro wrote:
I personally use this but it has several downsides: you need to know your main interface and have ip installed which could be a problem on older systems.
|ip addr show dev eno1 | sed -e's/^.inet6 ([^ ])/.*$/\1/;t;d' | head -1 |
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ddclient/ddclient/issues/75?email_source=notifications&email_token=AFRFCWXNZDGPYJYDQ4GMGGLQPW7AVA5CNFSM4IVJHH32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB2TMQA#issuecomment-544552512, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFRFCWR3AGOEQ7CKDKIA4YLQPW7AVANCNFSM4IVJHH3Q.
I am using NAT with IPv4 and 6 and this works if your router the correct IPv6 prefix set.
@DaveSophoServices : A common use of IPv6-NAT is NPTv6 (Network Prefix Translation), as such local devices can have static Unique Local Address (ULA, fd00::/48) addresses and each address gets translated to GUA (Global Unicast Address) at the edge.
The advantage of using local ULA's is the ISP assigned global prefix can change or WAN failover will use a different global prefix, the edge NPTv6 will adapt and map whatever the current global prefix is to the static, local ULA addresses.
That said, using residential networking equipment, it is very common for DHCPv6-PD to assign GUA prefixes to local subnets without any NAT for IPv6.
Personally, I think not making system calls to curl is nicer. I’ve been thinking about it. Is there an ip lookup service that only response in ipv6, such as myipv6.com, or whatever? We wouldn’t need curl’s -6 flag if the service you access is only ipv6. … On Oct 21, 2019, at 6:36 AM, Sandro @.***> wrote: It's there anything against adopting curl over time?
@DaveSophoServices as maintainer of the code its entirely up to you. My view is that best practice is to leverage available system services. ddclient needs to focus on the required protocols and APIs that the various dyndns services require. I don't think it is useful for ddclient to embed IP network layer functions when it can all be handled by curl. It is common to find curl on a system while it is not common to find the perl IPv6 functions (I'm thinking of embedded systems, not general purpose linux distributions). @abelbeck and I spent considerable time trying to get IPv6 working with ddclient. We gave up on using the Perl IPv6 network functions as we ran into too many issues.
Hello, I do not have trouble with IPv6 or am I missing something. The Router "sets" the fixed IPv6 suffix for the Server and when using below configuration with the IPv6 part the address is correctly updated. So the configuration works individually and assigns the proper IP address but both in one config file does not work. Is there a solution?
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf
cache=/var/cache/ddclient/ddclient.cache
pid=/var/run/ddclient/ddclient.pid
syslog=yes
ssl=yes
protocol=dyndns2
# IPv4 part
use=web
server=<server>
login='<user>'
password='<pw>'
my.domain.org
# IPv6 part
usev6=if, if=enp2s0
server=<server>
login='<user>'
password='<pw>'
my.domain.org
@twinkybot two comments... first your config file doesn't look right... the server, login, password and domain name should appear once not twice, so your config would look like this..
# /etc/ddclient.conf
cache=/var/cache/ddclient/ddclient.cache
pid=/var/run/ddclient/ddclient.pid
syslog=yes
ssl=yes
protocol=dyndns2
use=web
usev6=if
if=enp2s0
server=<server>
login='<user>'
password='<pw>'
my.domain.org
Second... if you still have problems, can you try with the version at https://github.com/astlinux-project/ddclient-curl and see if it works.
The dyndns2 protocol can't update IPv6 AAAA records AFAIK.
Using ddclient-curl IPv6-capabable protocols are: cloudflare, he, freedns, duckdns
@twinkybot two comments... first your config file doesn't look right... the server, login, password and domain name should appear once not twice, so your config would look like this..
After incorporating your suggestion I am getting an update still for either or :/
If I have
use=web
usev6=if
it updates IPv6 only or at least the debug output suggests this:
sudo ddclient --verbose
INFO: forcing updating my.domain.org because no cached entry exists.
INFO: setting IP address to <IPv6> for my.domain.org
UPDATE: updating my.domain.org
CONNECT: <server>
CONNECTED: using SSL
SENDING: GET /nic/update?system=dyndns&hostname=my.domain.org&myip=<IPv6> HTTP/1.0
SENDING: Host: <server>
SENDING: Authorization: Basic aGV1cmVrYS50d2lua3lib3Qub3JnOnA3a25fUTdicXNCaw==
SENDING: User-Agent: ddclient/3.8.3
SENDING: Connection: close
SENDING:
RECEIVE: HTTP/1.1 200 OK
RECEIVE: Date: Tue, 05 Nov 2019 08:03:42 GMT
RECEIVE: Server: Apache
RECEIVE: Upgrade: h2
RECEIVE: Connection: Upgrade, close
RECEIVE: Content-Security-Policy: default-src 'none'; script-src 'self' 'unsafe-inline' https://address https://www.google.com https://www.gstatic.com 'unsafe-eval'; object-src 'self'; style-src 'self' https://address 'unsafe-inline'; img-src 'self' data: https://address; media-src 'self'; frame-src 'self' https://www.google.com https://address; font-src 'self' https://address; connect-src 'self';
RECEIVE: X-Frame-Options: DENY
RECEIVE: X-XSS-Protection: 1; mode=block
RECEIVE: X-Content-Type-Options: nosniff
RECEIVE: Strict-Transport-Security: max-age=31536000
RECEIVE: Referrer-Policy: no-referrer, same-origin
RECEIVE: Content-Type: text/html; charset=UTF-8
RECEIVE:
RECEIVE: nochg
WARNING: updating my.domain.org: nochg: No update required; unnecessary attempts to change to the current address are considered abusive
The DynDNS2 API allows to update both IPv4 and IPv6 address at the same time, you just pass a comma separated list of IPs to myip, eg. myip=1.1.1.1,2606:4700:4700::1111.
At least with the hosters I tried (INWX) this did not work. It just updates one record and ignored the other. IIRC something similar happened with cloudflare but afaik it does not use dyndns2 api.
It works with dynv6.com, probably depends on how faithfully the provider implements the DynDNS API.
Hi folks! I'm a long time perl guy who may be able to patch up the google domains driver. It looks like 5.14 is the version that IO::Socket::IP entered core, so it should be fine for embedded systems and others that haven't been updated since 2011. I'll look for the source code repo and see if I can submit a patch.
Looks like there's a single socket because of the if ... elsif section around line 2090. We should create a list of $sd objects and iterate over them instead. let me put together a patch
alright, I'm going to do my patch against the debian package using quilt. I'll see if I can get it in here:
https://anonscm.debian.org/cgit/collab-maint/ddclient.git
If I'm able to get them in there, I'll see if I can convince the devs to sync their patches to master
@wimpunk @DaveSophoServices @rhansen @SuperSandro2000 Please do not merge in any IPv6 changes/support piecemeal. Take a step back and think it through. ddclient has become a monster with many heads and current IPv6 support is a mess. As you will have seen in recent comments I have withdrawn pull request #40 because it will no longer merge with current master. I am working on a new PR.
Do you care? If not then I will stop wasting my time.
If you do care then please lets all get on the same page. We need a pause on changes to the core ddclient while IPv6 support I implemented is properly reviewed by anyone that feels the desire and then merged in.
It will take time. My new PR is not ready for review yet.
I personally care a lot about ipv6 cause I currently use a modified version of your pull request in production.
I don't think we need to pause anything if it does not touch to many lines. Git is quiet good handling merge conflicts especially if the changes only touch a couple of lines.