top | item 20928536

Xip.io: Wildcard DNS for Everyone

174 points| lelf | 6 years ago |xip.io

49 comments

order
[+] mike_d|6 years ago|reply
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.

https://en.wikipedia.org/wiki/DNS_rebinding

https://support.google.com/wifi/answer/9144137?hl=en

[+] ploxiln|6 years ago|reply
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

[+] garymoon|6 years ago|reply
It was the first thing that came to my mind when I read about xip.io!
[+] jchw|6 years ago|reply
It should work for external IP addresses regardless.
[+] InTheArena|6 years ago|reply
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.

[+] onesmallcoin|6 years ago|reply
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.
[+] inglor|6 years ago|reply
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.

[+] jiveturkey|6 years ago|reply
This is so absolutely trivial to implement, why would anyone use their service in the first place?
[+] jbverschoor|6 years ago|reply
Still not sure why that is not available
[+] johnchristopher|6 years ago|reply
Oh, I remember that one !

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
Nice idea, shame it does not work with IPv6.

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
I've been running a similar service for the past few years on continuous.pw, which supports both ipv4 and ipv6.

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
What's the advantage over just typing the IP into the browser bar?
[+] vince14|6 years ago|reply
I'm using it in order to talk to different backends without touching the nginx config.

  server_name ~^(?<sub>\w+)\.127\.0\.0\.1\.xip\.io$;
  root sites/$sub;
[+] buildzr|6 years ago|reply
Seems to be targeted at allow multiple vhosts and SSL certs on the same IP.
[+] dahart|6 years ago|reply
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...
[+] sleepybrett|6 years ago|reply
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.
[+] mises|6 years ago|reply
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.
[+] sleepybrett|6 years ago|reply
that only resolves to localhost though..

Also allows you to set up vhosts if your quickie server is stood up behind something like nginx.

[+] 3xblah|6 years ago|reply
"How does it work?

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:

   # Assuming unbound listens on 10.0.0.2
 
   echo > _dnscache/env/FORWARDONLY
   echo 10.0.0.2 > _dnscache/root/servers/@
1 http://cr.yp.to/djbdns.html
[+] ezekg|6 years ago|reply
I used this and lvh.me a lot in the past to share WIP work or test webhooks but nowadays that has all since been replaced by ngrok.
[+] ohnoesjmr|6 years ago|reply
Next up, TLS certs for the random hostnames?

Are there security implications to this?

[+] linuxdude314|6 years ago|reply
Unlike ngrok his doesn't "expose" anything. Its just a lazy way to add DNS to a test environment.

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
This service is super useful, I use it to test the custom domains feature in my app.
[+] kenforthewin|6 years ago|reply
Cool idea. I use dnsmasq locally but seems like this would work well too.
[+] yy77|6 years ago|reply
why will we need such service? If we have to include the detailed IP address in the URL, why not direct access use IP address itself?
[+] tacticaldev|6 years ago|reply
anyone else get a HTTP 105 while trying to access xip.io ? (ERR_NAME_NOT_RESOLVED)
[+] dragonwriter|6 years ago|reply
Error 105 is an internal Chrome DNS-related error code, not an HTTP code.

HTTP 1xx codes are informational, not error, codes, and 105 doesn't exist.

[+] ndidi|6 years ago|reply
That's not an HTTP error code.