Comments (30)
FWIW I have IPv6 updates to Google working just fine with the following
-
QNAP
checkip-command = "ip -6 address show scope global dev eth0 |grep inet6"
-
macOS
checkip-command = "ifconfig en0 |grep inet6 |grep -v temporary"
from inadyn.
I've started to hack on this again last weekend. Can't give you any estimate, though, since my free time is quite limited currently.
Keep an eye on my fork mentioned above to see any progress :-)
from inadyn.
We can probably agree that IPv4 and IPv6 are all address types that are needed now. Let's not get confused with "address types" (or families as in socket-speak) and DNS "record types". Whatever record type, it can currently only hold either of those two meaningful dynamic address types.
However, I favor my third proposal which explicitly suggests source-ipv4
and source-ipv6
config entries and otherwise keeps the old option names backwards-compatible. If those are used, the semantics should be to auto-detect what type is needed. Only if you need both IPv4 and IPv6 is when the new syntax is definitely needed, and then adding a source-ipv8
type in 200 years will be almost a no-brainer ;-)
from inadyn.
bummer, i just thought i give inadyn a try as ddclient doesn't support ipv6.
it's a pity how few dyndns clients support ipv6.
btw, I develop https://nsupdate.info/ and it supports ipv6. it even has support for updating all your v6 IPs on your lan with a single dyndns2 update request. so, if you have questions about how dyndns2 protocol / services / clients can easily support ipv6, i can help. Can't help with C coding / C specific questions though.
btw, in python-dyndnsc, a nice socket-based method to find the right local ipv6 address was just implemented:
https://github.com/infothrill/python-dyndnsc/blob/develop/dyndnsc/common/detect_ip.py
from inadyn.
@acolomb Reading your DOC have a few comments:
- No reason to do anything with MX records. They can only target names. They will persist even if the name disappears and reappears later.
- Likewise aliases. A CNAME to a ddns name will persist and do the right thing. Not our problem.
- Determining the primary permanent IPv6 address on most posix nodes is fairly trivial with the
ip
command set, I think doing the obvious thing by default and allowing checkip override for customization is the way to go (e.g. don't overthink this) - If a node has an IPv6 address outside of
fe80/10
, we should be registering the IPv6 and ignoring the v4 unless instructed otherwise. Very few people have workable IPv4 addresses that can dynamically accept connections from the NAT firewall they are hiding behind.
And finally, dual updating both v6 and v4 isn't supported by any provider AFAIK and makes the job harder. I believe very strongly that you should aim for MVP of simply getting IPv6 working "out of the box" with every provider that supports it. Don't shoot for complexities that aren't required until the basic support is there.
from inadyn.
As a note: if anyone has a node where IPv6 isn't working and they are willing to share the output of ip
and ifconfig
commands along with credentials to test with, I'm happy to work on IPv6 implementations. Ping me directly.
from inadyn.
Hi!
Sorry, but IPv6 is currently only supported with https://tunnelbroker.net/ ... patches to fix this are most welcome! :)
from inadyn.
Good to know, thanks for the offer @ThomasWaldmann :-)
from inadyn.
Any movement on this, perhaps? It's starting to get pretty important now that TWC and Comcast have started handing out IPv6 subnets to home users and there's talk of some mobile networks going IPv6-only within a couple of years now that many countries have allocated their last IPv4 address. :(
from inadyn.
Nope.
Unfortunately I cannot get an IPv6 at home yet, so we're short out of luck until some friendly soul submits a pull request. 😞
from inadyn.
@troglobit you really need tunnelbroker (HE, hurricane electric), for multiple reasons. :)
They seem cool, even have IPv6 quizzes and stuff. And it's free.
BTW, nsupdate.info can trigger a tunnelbroker update if it receives a normal, single v4 dyndns update.
from inadyn.
@ThomasWaldmann heh, OK I'll give tunnelbroker a go first thing tomorrow! 😃
Good to know about your nsupdate.info capabilities as well. Issue #83 though mentions they have something similar ...
from inadyn.
So, as of 740abac Inadyn now supports using an external command to query the address, which also supports parsing IPv6 addresses. So far I've only tested it using the following script
checkip-command = "/sbin/ifconfig wlp3s0 | grep 'inet6 addr'"
Which finds the IPv6 address and then sends the update, as a string, to the DDNS provider. If anyone else could give it a whirl with the standard provider setup I'd be very happy! 😃
This latest set of commits brings the v2.0 release very close, so any feedback is greatly appreciated.
from inadyn.
likely that is not enough to find out the right ipv6 address for that purpose.
with privacy extensions, an interface has a bunch of ip addresses, but they are just temporary - while you want the permanent one to register it with a dyndns service.
python dyndnsc has some code to find the right one - have a look there.
from inadyn.
Sure, my point was simply that it is now possible to use IPv6 with Inadyn. The following script would likely work better :)
checkip-command = "ip address show scope global dev eth0 |grep inet6"
But you're right, the iface = eth0
detector doesn't handle IPv6 at all, and there is no provider {}
section with IPv6 support yet either.
from inadyn.
I finished another function, now the iface = eth0
setting can return IPv6 addresses as well. There is an IPv4 and IPv6 validator that filters out local/non-global addresses,
Only thing missing now is for someone to create a IPv6-provider :-)
from inadyn.
You still need to determine the permanent (non-privacy-enhanced) address as it does not make much sense to put the temporary ones into dns.
from inadyn.
Admittedly I'm by no means knowledgable about IPv6 but I've used the following standardized verifiers in is_address_valid():
IN6_IS_ADDR_UNSPECIFIED()
: Unspecified addressIN6_IS_ADDR_LOOPBACK()
: Loopback addressIN6_IS_ADDR_LINKLOCAL()
: Unicast link-local addressIN6_IS_ADDR_SITELOCAL()
: Unicast site-local address
From http://pubs.opengroup.org/onlinepubs/000095399/basedefs/netinet/in.h.html and I've tested with a few obvious ones. From the attached table.
Any help here would be greatly appreciated!
from inadyn.
Can't help you with the C stuff, but here is working python code:
IPV6_PUBLIC (not _TMP) is what you want.
from inadyn.
Due to the way I've chosen to implement the new "get interface address" code (portability reasons), I cannot use the same (Linux specific) socket API that the Python code does.
However, I now understand what needs to be done, and for future reference I'm posting a few links and thoughts for myself:
- https://www.ietf.org/rfc/rfc5014.txt
- https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/inet6_is_srcaddr.htm
The inet6_is_srcaddr()
API is missing in GLIBC on Linux, and also on the BSD's. It seems only IBM have implemented RFC 5014 as a separate function, as recommended. Linux only has this support as an extension to the socket API, which is useful but very limiting.
Implementing this function according to the RFC, possibly in libite so it can be reused by other applications as well, should be quite straight forward.
from inadyn.
I've been thinking about how to tackle the rest of IPv6 support in Inadyn. Before sharing my plans thus far, what do others think about this one specific question:
Should a single provider
section in the config handle both IPv6 and IPv4 addresses, or would it be acceptable to require two separate configuration sections?
I personally think the former way is superior. Only one HTTP update request, only one point to specify the user credentials, and it could be extended to support other record types in one go, e.g. setting the MX address. I'll also try to come up with a backward-compatible configuration syntax for these extensions.
from inadyn.
I started collecting some notes about what needs to be done to complete Inadyn's IPv6 support at https://github.com/acolomb/inadyn/blob/ipv6-planning/IDEAS-IPv6.md .
Requesting for comments, so we have a consensus before I start prototyping features.
Maybe this could be turned into a GitHub "project", but I haven't played with that feature enough yet. Splitting off this issue for several sub-aspects would be useful as well.
from inadyn.
Would be nice to get IPv6 support in a ddns client :). Any updates on progress?
from inadyn.
So I've read through @acolomb's writeup and here's my opinion:
- The vast majority of providers support DynDNS protocol, which is careless (literally) about which type of address you send it. You can send it either type or both comma-separated
So really the only thing we need to make inadyn truly dual-stack would be
- A selection mechanism for which protocol to send (@acolomb proposed
addrtype
) - Separation of
check-ip
commands for v4/v6 - A list of commands to check v6 IPs on different platforms, much like v4 today
I really think that achieving this point will be quite easy.
from inadyn.
@jorhett Sorry for not responding earlier, your questions slipped off my radar.
* No reason to do anything with MX records. They can only target names. They will persist even if the name disappears and reappears later. * Likewise aliases. A CNAME to a ddns name will persist and do the right thing. Not our problem.
Thanks for your opinion. I had crossed them off my mental list already, but who knows what other record types with a dynamic nature might come later, so having an extendible scheme would not hurt if it does not make things more complicated.
* Determining the primary permanent IPv6 address on most posix nodes is fairly trivial with the `ip` command set, I think doing the obvious thing by default and allowing checkip override for customization is the way to go (e.g. don't overthink this)
The main problem (unsolved and discussed way above in this issue) is the advertisement of temporary addresses that will soon be retired because of the IPv6 Privacy Extensions feature. Filtering for ip address show
output for global
is not enough, I think the temporary
flag needs to be avoided as well. The mngtmpaddr
flag seems to be a good indicator of having the correct address, if it exists.
* If a node has an IPv6 address outside of `fe80/10`, we should be registering the IPv6 and ignoring the v4 unless instructed otherwise. Very few people have workable IPv4 addresses that can dynamically accept connections from the NAT firewall they are hiding behind.
I don't know about the majority or other statistics, but there are definitely still many ISPs issuing real IPv4 addresses. On the other hand, I've seen technically up-to-date campus networks deployed without IPv6 routing enabled, which is clearly a bug but warrants not ignoring IPv4 completely if IPv6 seems to be working on our end ("server").
And finally, dual updating both v6 and v4 isn't supported by any provider AFAIK and makes the job harder. I believe very strongly that you should aim for MVP of simply getting IPv6 working "out of the box" with every provider that supports it. Don't shoot for complexities that aren't required until the basic support is there.
First of all, Dynu for example supports both IPv6 and IPv4 updates in one query, and I believe they are not alone. I understand your concern and I wish I had more time to move toward a better IPv6 solution overall. My goal in writing that design document was to envision a final feature set and its needed configuration syntax, so we won't have to change the configuration syntax again once the MVP grows toward the full-fledged flexible solution. One design requirement, rather important IMHO was to allow reusing checkip
sources and also allowing fallbacks. In the simplest case, two providers each have their own checkip servers, but each could fall back to the other's determined address when one is down.
Will reply to your PR shortly.
from inadyn.
Actually the "alias" stuff also comes from Dynu. It's their term for subentries in the zone, e.g. you can set example.dynu.net
to some IP and also create an A
or AAAA
record for www.example.dynu.net
. Updating that in a protocol request needs a combination of hostname=example.dynu.net&alias=www
IIRC.
from inadyn.
quick TL;DR--agreed on the aliases and dual update. Both are part of the DynDNS2 protocol (I misread the first time)
I don't agree on building a scheme capable of handling unknown protocol changes. It took 20 years for AAAA records to become standardized, I seriously doubt we're at risk of an overnight need for a different type of record. (I work on those committees and if you saw the political and social barriers to change you'd understand how unlikely it is). This is not a serious risk, whereas overdesign is ;-) Let's get an MVP in place.
But... the code is very single-threaded check-1, submit-1 today. The work to make it deal with an either/or/and scenario for v4/v6 is going to make it more modular, likely enough so that adding another type should be easy. So you may get what you want, it's just not going to be a priority focus (for me anyway)
from inadyn.
(I sincerely hope Inadyn will be dead in 200 years ... anything else is a really too scary to think about! Any other year that passes until then without IPv6 support are really lost years, if I speak on part of the project.)
from inadyn.
Greetings from the year 2021. I was trying to configure Dynamic DNS on my FreeNAS box and ended up here.
from inadyn.
I already use inadyn for a a long time with a ipv6 only host.
my conf looks like this:
verify-address = true
period = 300
forced-update = 86400
allow-ipv6 = true
iface = br0
custom mydom.info {
ssl = false
username = user
password = pass
ddns-server = mydom.info
ddns-path = "/dyn/?hostname=%h&myip6=%i&noip4"
hostname = myhost.mydom.info
checkip-command = "/usr/sbin/ip address show scope global dev br0 | grep inet6 | awk '{print $2}' | cut -d/ -f1 | grep -v ^fd | grep 200:200"
}
the important thing is, to set a IPv6 Token. The way to do this depends with your network setup "engine"... I use systemd-networkd with a config file /etc/systemd/network/br0.network like this:
[Match]
Name=br0
[Network]
DHCP=yes
IPv6PrivacyExtensions=yes
IPv6Token=::200:200:200:200
Or for legacy Debian/Ubuntu file /etc/network/interfaces:
iface br0 inet6 auto
pre-up /sbin/ip token set ::200:200:200:200 dev $IFACE
Or for netplan: canonical/netplan#161
Others may check there: https://serverfault.com/questions/968641/configure-ipv6-address-on-interface-with-static-iid
The only problem I have, that inadyn does not check "only" for ipv6.
Jun 10 07:50:44 myhost inadyn[714]: Failed resolving hostname myhost.mydom.info: No address associated with hostname
Jun 10 07:50:44 myhost inadyn[714]: Update forced for alias myhost.mydom.info, new IP# 2aXX:XXXc:XX:XXXX:200:200:200:200
we need a option to tell inadyn for a dyn host, that this host is ipv4 or ipv6 or ipv4+ipv6, so that it knows what to check.
from inadyn.
Related Issues (20)
- DNSExit.com present for updating DDNS no longer functions as of sometime after November 20th 2023. HOT 4
- Period not to find in logs HOT 3
- does not time out HOT 2
- [Feature request] Add logging level to logs
- inadyn stop period refresh after several fail HOT 1
- [Bug] `Error running 'INADYN_PROVIDER="[email protected]"` HOT 8
- FEATURE REQUEST: Add support to execute a bash script on IP address change (passing the new IP to the script) HOT 1
- never connects to APIs?
- Failure running Docker image? HOT 6
- Missing .conf file, and can not create a new one HOT 2
- ddns-server like username:[email protected] cant work HOT 2
- wrong ddns server for [email protected] HOT 2
- "Building from GIT" is broken? HOT 3
- Main process exited when get error response from DDNS server HOT 2
- pokbun API does not work, leaks secret key in debug logs HOT 2
- Caching issues (dual stack) and forced updates
- Variables for update of ipv6prefix and ipv6 on dynv6 HOT 12
- Compilation will fail with GCC-14 due -Wimplicit-function-declaration as error HOT 2
- API version used with dynu.com HOT 2
- inadyn[25670] <Error>: Zone 'my-domain.com' not found - Cloudflare HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from inadyn.