Just a heads up that services like these won't work behind security-aware DNS recursive resolvers (like OpenDNS) or routers (like Google Wifi) that block DNS rebinding attacks.
Are you sure? I think these dns names are deterministic, they never change, for example www.10.0.0.1.xip.io will always resolve to 10.0.0.1 - and I don't think there is a mode where a name could resolve to different ipv4 addresses at different times.
EDIT: I experimentally confirmed that opendns and google dns, which claim to block dns rebinding attacks, do not block xip.io or subdomains thereof
We've used this before, and it seems to be catastrophically unreliable.We had development projects on a internal development reverse proxy that we wanted to specify with a name, and found that it quite often broke down. It could be their DNS relay, or some other network event, but at least once a week, it would simply timeout.
I would kill to be able to specify wildcards in /etc/hosts file. That seems to be the sweet-spot.
I've used ngrok in the past for exposing local projects but didn't like being time limited and then having someone try to sell me something. The setup I went with is I forward my local http servers port over an ssh tunnel to a local port listening on a gcompute VPS running apache with a virtualhost configured using mod_proxy to listen on a subdomain managed my cloudflare, cloudflare then takes care of the https/ssl certificates and your good to go!
This setup has been working better than ngrok for me, The only thing I miss is ngroks logging, but I haven't come accross anything I couldn't debug between apaches access.log and my local development console.
For anyone doing this more than once a day I really reccomend investing in building your own infastructure, even if you don't learn a thing or two at least your brushing up on a topic.
We ended up using ngrok for our development builds and while it's certainly a lot more setup (and it costs us money) I am pretty happy with the results and as a customer for that use case.
We sell a SaaS e2e testing product for large enterprises (clients like Microsoft/Wix/JPM etc) and this use case (serving the dev environment to the CI or between computers) was so common that we baked it into our CLI.
Personally I just set up (dev machine is always running some Debian or derivatives) Traefik as a reverse proxy and set up local dev websites/app with *.localhost. I don't bother adding localhost self-signed certs to FF though (never really could make it work anyway). Easier to click "yes, trust that certificate for that localhost subdomain).
I generally didn’t use xip.io in the browser bar, the use cases are more commonly putting the address in web forms for things that return a wildcard address but need to be a well-formed domain name. I’ve used xip.io for AWS security rules, CORS rules, Google API redirects, mobile app testing against a local server, stuff like that...
I know my corporate firewalls do not allow connections to bare ip addresses. This allows me to bypass that check for things I haven't assigned names to already.
Interestingly enough, Plex is running something very similar to this to support SSL for all of their users. a-b-c-d.guid.plex.direct will resolve to a.b.c.d. (Where guid is replaced with a guid, without dashes.)
Quick PSA: You can do this yourself on cloudflare. I've got a sub-domain of my web site, "localhost.my.site". That resolves to localhost. I also added a wildcard, "*.localhost.my.site", which also resolves to localhost. It's pretty easy to do, and a handy trick. I figure some one probably turned this into a blog post, but this way you don't have to rely on some one else's stuff going down. I also use it for my local domain, cause I don't want to bother running a local DNS server.
xip.io runs a custom DNS server on the public Internet."
Is there a way to provide wildcard DNS without sending internal LAN IP addresses to a closed source "custom DNS server" over the public Internet?
Yes. If you are a djbdns^1 user, and you wanted all subdomains of xip.io to resolve to 10.0.0.1:
# Assuming _dnscache and _tinydns are the configuration folders and tinydns listens on 127.0.0.1
cat << eof > _tinydns/root/data
.xip.io.
&*.xip.io:127.0.0.1
=*.xip.io.:10.0.0.1
eof
cd _tinydns/root
make
cd -
echo 127.0.0.1 > _dnscache/root/servers/xip.io
If you are an unbound user, you can put dnscache in front of unbound:
[+] [-] mike_d|6 years ago|reply
https://en.wikipedia.org/wiki/DNS_rebinding
https://support.google.com/wifi/answer/9144137?hl=en
[+] [-] ploxiln|6 years ago|reply
EDIT: I experimentally confirmed that opendns and google dns, which claim to block dns rebinding attacks, do not block xip.io or subdomains thereof
[+] [-] garymoon|6 years ago|reply
[+] [-] jchw|6 years ago|reply
[+] [-] InTheArena|6 years ago|reply
I would kill to be able to specify wildcards in /etc/hosts file. That seems to be the sweet-spot.
[+] [-] onesmallcoin|6 years ago|reply
[+] [-] qiqitori|6 years ago|reply
(It's possible that you'll sometimes run into applications that do their own /etc/host parsing.)
[+] [-] inglor|6 years ago|reply
We sell a SaaS e2e testing product for large enterprises (clients like Microsoft/Wix/JPM etc) and this use case (serving the dev environment to the CI or between computers) was so common that we baked it into our CLI.
[+] [-] jiveturkey|6 years ago|reply
[+] [-] jbverschoor|6 years ago|reply
[+] [-] jdofaz|6 years ago|reply
[+] [-] johnchristopher|6 years ago|reply
Personally I just set up (dev machine is always running some Debian or derivatives) Traefik as a reverse proxy and set up local dev websites/app with *.localhost. I don't bother adding localhost self-signed certs to FF though (never really could make it work anyway). Easier to click "yes, trust that certificate for that localhost subdomain).
[+] [-] chaz6|6 years ago|reply
dig 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.xip.io. in aaaa
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[+] [-] loganv|6 years ago|reply
Examples:
7f000001.ip.continuous.pw has address 127.0.0.1
fc00.ip6.continuous.pw has IPv6 address fc00::
fc0014c0000001abcde.ip6.continuous.pw has IPv6 address fc00:14c0:0:1ab:cde0::
Sources available at https://github.com/continuouspw/continuous-dns/tree/master/p...
[+] [-] icholy|6 years ago|reply
[+] [-] yegle|6 years ago|reply
See https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
[+] [-] vince14|6 years ago|reply
[+] [-] BozeWolf|6 years ago|reply
[+] [-] buildzr|6 years ago|reply
[+] [-] dahart|6 years ago|reply
[+] [-] sleepybrett|6 years ago|reply
[+] [-] iwalton3|6 years ago|reply
[+] [-] yegle|6 years ago|reply
[+] [-] mises|6 years ago|reply
[+] [-] sleepybrett|6 years ago|reply
Also allows you to set up vhosts if your quickie server is stood up behind something like nginx.
[+] [-] 3xblah|6 years ago|reply
xip.io runs a custom DNS server on the public Internet."
Is there a way to provide wildcard DNS without sending internal LAN IP addresses to a closed source "custom DNS server" over the public Internet?
Yes. If you are a djbdns^1 user, and you wanted all subdomains of xip.io to resolve to 10.0.0.1:
If you are an unbound user, you can put dnscache in front of unbound: 1 http://cr.yp.to/djbdns.html[+] [-] ezekg|6 years ago|reply
[+] [-] ohnoesjmr|6 years ago|reply
Are there security implications to this?
[+] [-] linuxdude314|6 years ago|reply
If you already have a cloud provider, why would you leverage this instead of just creating real DNS records w/ reasonable TTLs?
[+] [-] SkyLinx|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] koolba|6 years ago|reply
[+] [-] mike_d|6 years ago|reply
https://github.com/basecamp/xip-pdns/blob/master/bin/xip-pdn...
[+] [-] kenforthewin|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] yy77|6 years ago|reply
[+] [-] tacticaldev|6 years ago|reply
[+] [-] dragonwriter|6 years ago|reply
HTTP 1xx codes are informational, not error, codes, and 105 doesn't exist.
[+] [-] ndidi|6 years ago|reply
[+] [-] Batman8675309|6 years ago|reply
[+] [-] cwt137|6 years ago|reply