no good way yet to detect IPv6 addresses when using privacy extensions (which is probably the default) about python-dyndnsc HOT 13 CLOSED

oh, complicated :| wasn't aware of these issues, but glad that you found a working solution.

maybe this could be documented for dyndnsc until there is a better solution?

from python-dyndnsc.

i may have a fix/workaround for this in nsupdate.info 0.9 - see nsupdate-info/nsupdate.info#167 (it is deployed now on nsupdate.info).

with that, it is sufficient if the updater sends the ip with the correct prefix (== the same prefix as your non-temporary global IPs)

from python-dyndnsc.

i tried this --detector hack and it works for detecting the correct ipv6 from the interface.

but: as dyndnsc queries the currently present address from dns (to detect whether an update is needed) and it uses a service that returns the ipv4 address, it always thinks the ip has changed:

DEBUG IPDetector_DNS.set_current_value(109.192.29.63)
DEBUG IPDetector_Command.set_current_value(2002:6dc0:2c3e:0:29c:2ff:fea2:ffff)
INFO Current dns IP '109.192.29.63' does not match detected IP '2002:6dc0:2c3e:0:29c:2ff:fea2:ffff', updating
DEBUG Updating 'x.nsupdate.info' to '2002:6dc0:2c3e:0:29c:2ff:fea2:ffff' at service 'https://nsupdate.info/nic/update'
2014-10-02 02:09:36,125 DEBUG status 200, nochg 2002:6dc0:2c3e:0:29c:2ff:fea2:ffff

this is all a bit of a mess. i think there could be a cleaner solution if the webcheck service url would be configurable per service (so there could be 2 different services for doing v4 and v6 stuff without mixing stuff up).

from python-dyndnsc.

I'm not fully sure I follow the details (mostly since I am not using privacy extensions myself and I don't really know how they work), so let me re-phrase the issue as I understand it from the last comment: the dns query (IPDetector_DNS) returns an IPv4 address, even though we are updating an AAAA record? This could be caused by local DNS resolution (behind the NAT router) working differently than the global one. If this is the root problem, then specifying the DNS server to "test" the actual DNS value might be best. This would require implementing some custom DNS resolution code, which is perfectly doable. Or do I misread this entire issue?

Also, I am eager to see further updates to the upstream 'netifaces' package for detecting interface flags. I would gladly implement options for this.

from python-dyndnsc.

dns resolution for hosts with v4 and v6 addresses returns multiple addresses. guess it just picks the wrong one...

from python-dyndnsc.

Here is a recipe to get public/temporary address in IPv6: https://github.com/vincentbernat/puppet-workstation/blob/master/modules/system/templates/network/ddns-updater.erb#L237-L266

Using UDP allow to query the routing table without emitting a single packet. This also works for IPv4. For IPv6, the kernel can be hinted for which kind of address we prefer.

from python-dyndnsc.

Nice!

from python-dyndnsc.

So, if it does not send a packet, could some other IP address be used than google's?

from python-dyndnsc.

Yes, in fact, we could use special IP like documentation ones. For example, you could use 192.0.2.1 for IPv4 and 2001:db8::1 for IPv6. The only requirement is for them to be routed to "outside".

from python-dyndnsc.

as long as desktop computers won't add routing information for this group of special well known ip addresses I think always the default route will apply and give us the right address, even if the ip is not routable.

from python-dyndnsc.

http://paste.thinkmo.de/Grd9uMnD code now under ISC license (licensed by original author)

from python-dyndnsc.

I took the code in the previous comment and made PR #27 from it.

I tested it on Ubuntu 14.04 and it successfully detected the public static IPv6 of my system and updated it on nsupdate.info. \o/

from python-dyndnsc.

is merged and works for me - close?

from python-dyndnsc.