luci-app-ddns: improve ip_script field description
- [x] This PR is not from my main or master branch :poop:, but a separate branch :white_check_mark:
- [x] Each commit has a valid :black_nib:
Signed-off-by: <[email protected]>row (viagit commit --signoff) - [x] Each commit and PR title has a valid :memo:
<package name>: titlefirst line subject for packages - [x] Tested on: v7l, OpenWrt 23.05.5 r24106-10cc5fcd00 / LuCI openwrt-23.05 branch git-24.264.56413-c7a3562, Firefox 130.0)
- [ ] ( Optional ) Depends on: https://github.com/openwrt/packages/pull/25044
This reflects and demonstrates the proposed capability to add a statement/command directly to the ip_script field of the ddns-scripts
Hi @jenszo and thanks for your contributions.
Does the command dig, which pulls data from the DNS, tell you what your current system public IP is?
dig tells you, among other things, what IP is stored in DNS, which may no longer be current if you've just changed IP, unless for some reason you just happen to be querying a DNS server which returns a PTR which points to your IP. Is your suggestion one of those? I tested it and neither the -4 or -6 returns anything.
So the point of the field is for a script which contacts an external address which hopefully tells you what IP it sees traffic coming from, your current public IP.
Perhaps curl or wget examples would be better (wget requires no extra packages), since dig and DNS have established meaning and usage, and it's not obvious that a dig command would readily retrieve your currently assigned IP:
https://www.ipify.org/
e.g.
wget -q -O- http://ipecho.net/plain
or
wget -q -O- 'https://api.ipify.org'
or
wget -q -O- 'https://api64.ipify.org'
Hi @systemcrash,
this is indeed somewhat confusing at first as it is somewhat of a specific custom feature of the OpenDNS service itself:
Resolving myip.opendns.com using their own resolver (like resolver1.opendns.com) will always return the requester IP address - in case of a NAT, the outbound one.
Doesn't require dig, works with any DNS client, really. By this, it does not come with the latency/overhead penalty of HTTP (and initial DNS request) . It also does not require to permit outbound HTTP traffic if this is a concern.
Surely, I have gotten used to it personally. Though this example was purely to prove the point of being able to use a single statement for this purpose.
I love your additional examples though. Let me add them/swap them in my PR. Maybe it is worth compiling some more examples on a wiki page.
On that note, Google DNS seems to provide a similar functionality:
https://unix.stackexchange.com/questions/335371/how-does-dig-find-my-wan-ip-address-what-is-myip-opendns-com-doing