←back to thread

A New Future for Icanhazip

(major.io)
980 points nkcmr | 7 comments | 06 Jun 21 19:21 UTC | HN request time: 0.397s | source | bottom
Show context
andrewmcwatters ◴[06 Jun 21 22:11 UTC] No.27416836[source]▶
Reminds me of `echo $(dig @ns1.google.com o-o.myaddr.l.google.com TXT +short | tr -d \")`. I have no idea where this DNS query came from, because searching all of Google turns up nothing but https://github.com/GoogleCloudPlatform/cloud-self-test-kit/b..., which is never referenced by anyone. I had to track it down myself for a bootstrap.sh, but I don't like using undocumented sources for critical infrastructure.

My use case was needing to set the result of `hostname -f` in /etc/hosts in an automated fashion if a VPS provider didn't already add a line for the public Internet address in that file. You need to do this so that sendmail doesn't fail on `apt install` when it attempts to read your FQDN. So I couldn't use the NGINX example posted elsewhere here.

It seems like https://checkip.amazonaws.com/ is much more "reliable" in that it is publicly documented at https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/s....

To anyone who needs to read this: please don't use "services" like icanhazip for your provisioning. Even my examples above are bad.

It does strike me as weird that there is seemingly no POSIX-compliant way to get your public Internet address, from my readings.

Edit: Oh goodness... even Amazon's documentation recommends using Google's undocumented DNS query.[1]

[1]: https://aws.amazon.com/premiumsupport/knowledge-center/route...

replies(6): >>27417302 #>>27417564 #>>27418095 #>>27418333 #>>27418679 #>>27420016 #
quesera ◴[06 Jun 21 23:23 UTC] No.27417302[source]▶
> It does strike me as weird that there is seemingly no POSIX-compliant way to get your public Internet address, from my readings.

It is not possible to know your public IP address, except by fetching the information from a known entity on the public network.

And in some scenarios, your public IP will change frequently. There is no guarantee that it will be consistent across multiple requests.

replies(2): >>27417876 #>>27418014 #
1. andrewmcwatters ◴[07 Jun 21 01:00 UTC] No.27417876[source]▶
Yes it is? I'm not talking about a situation where you send a packet to a DHCP server with 0.0.0.0 in the headers, I'm talking about what happens after the fact.

Once you have been allocated an IP address, there should be a way to fetch said address. That's the whole mechanism behind forging UDP packets. If I didn't know what my source IP address was, it would be OK to send 0.0.0.0 out into the world all the time.

Practically speaking, today, it is, considering most, but not all, ISPs won't let you do this and they will rewrite UDP packets that attempt to forge their source.

Edit: OK, since I'm not being clear, let me be explicit: There should be a mechanism in DHCP which allows for the querying of your public Internet address when receiving a packet from a client in one of the Private-Use Networks as defined in RFC 6890. This query should be exposed as a feature of ifconfig or ip, lest a user be forced to manually write such a packet to receive the data.

replies(6): >>27417942 #>>27418317 #>>27418389 #>>27418717 #>>27418974 #>>27423089 #
2. cowsandmilk ◴[07 Jun 21 01:11 UTC] No.27417942[source]▶
> Once you have been allocated an IP address

Well, there’s assumption 1 that isn’t true, often, you aren’t allocated a public IP address…at least in IPv4 world

3. viraptor ◴[07 Jun 21 02:20 UTC] No.27418317[source]▶
> querying of your public Internet address

Upnp allows you to do that. But that relies on a lot of assumptions. Your address when connecting to X and Y could be different. It could be different depending on the port. It could be load-balanced and come randomly from a pool. It could vary depending on time of day. And many many other cases.

4. fierro ◴[07 Jun 21 02:31 UTC] No.27418389[source]▶
you could be behind NAT or reverse proxies or any number of virtual or physical network components. This service helps account for all of that.
5. lmm ◴[07 Jun 21 03:24 UTC] No.27418717[source]▶
Private-use networks connected to the public internet are an ugly hack. If you don't have a public address, you don't have a public address in any meaningful sense, so any effort to figure out "your" address is doomed from the start.

Particularly in these days of IPv6, just give everything a notionally publicly routable address and then every device can know its real address (of course this doesn't have to mean you actually route public traffic to every address if you don't want to).

6. numpad0 ◴[07 Jun 21 04:22 UTC] No.27418974[source]▶
I guess you can pick an empty or safe spot from here[1] and send patches to major DHCP server implementations, feels like option 81 "Client FQDN" is already close to that though.

Also do keep in mind that an OS instance can have multiple Ethernet interfaces, and that each interface can have multiple IPs, and that not all DHCP gives out private addresses(University Wi-Fi gave me 133.xx back in the days ... behind NAT!), and that double NAT exists.

1: https://www.iana.org/assignments/bootp-dhcp-parameters/bootp...

7. quesera ◴[07 Jun 21 14:34 UTC] No.27423089[source]▶
I'm not sure I follow your model of IP networking, but the problem boils down this:

In live networks, you don't always know which device presents your last-hop routable address to the public network, so it is not clear who can authoritatively answer the whatismyip question.

You can get an instantaneously-correct answer (i.e. correct in the instant, not necessarily quickly-answered) from an empirical test, but you need to choose an known (and trusted) entity on the public network to query. Querying multiple different entities might very well get you multiple different answers, depending on how your packets are routed and manipulated before they reach the public network.

And in all cases, there is no guarantee that your public address will be stable over time or location.