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

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

It depends on the implementation of the DNS rebinding protection.

I have just checked, and my pfSense firewall (which claims to block DNS rebinding) blocks local addresses from resolving through xip.io (tested with loopback and several RFC1918. All blocked, regardless of whether they match the subnet in use). External addresses (e.g. 1.1.1.1.xip.io) resolve fine.

I see this too, with Unbound. Using Cloudflare over TLS as my upstream resolver.

It was the first thing that came to my mind when I read about xip.io!

It should work for external IP addresses regardless.

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.

Thanks for the advice.

A good alternative to ngrok is Serveo, which has a public instance of self-hosting options: https://serveo.net/

It's not feature-parity with Ngrok, but it does what's needed.

Thanks for the comment- I haven't used Serveo personally, but it looks like a product that ticks pretty much all the boxes my setup goes for without all of the configuration- And their not trying to sell me something +1 for serveo

I don't think it's likely wildcards will ever be implemented in /etc/hosts, but you could hack glibc to support it without too much effort I think (somewhere in this file https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/nss_fil...)

(It's possible that you'll sometimes run into applications that do their own /etc/host parsing.)

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.

This is so absolutely trivial to implement, why would anyone use their service in the first place?

I agree. If you're using it for development within your company, you should just configure your own. There are a number of open source DNS resolvers (some mentioned in these comments) that can be configured to do this.

Still not sure why that is not available

https://nip.io is another option

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).

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

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...

What's the advantage over just typing the IP into the browser bar?

You can create SSL certificate with a domain name but not so easy with an IP.

See https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

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;

When developing for iphone, react native uses xip (i think?) to have direct access to the development server on the laptop. Apple does not allow connecting to the ip directly. Details: https://github.com/facebook/react-native-website/blob/master...

Seems to be targeted at allow multiple vhosts and SSL certs on the same IP.

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.

this makes no sense -- all tcp connections are already to the "bare ip address". dns lookup happens independently of the ip connection. in the case of a browser, your browser asks the local resolver (or with doh, remote nameserver) what the ip is for a given domain, then connects to that ip. I suppose it's possible your network has some strange setup that pokes holes through the firewall based on dns requests, but that would be obscenely expensive both computationally and financially.

He probably means his corporate proxy servers, not firewalls.

indeed, sorry.

The simplest implementation of this would be to block all outbound traffic for all hosts by default, and allow only web traffic out through a proxy. Then for other specific services poke holes for specific src<->dst.

The firewall or proxy is probably looking at the HTTP host header, and blocking requests with an IP there.

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.

that only resolves to localhost though..

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

"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

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.

Next up, TLS certs for the random hostnames?

Are there security implications to this?

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?

This service is super useful, I use it to test the custom domains feature in my app.

Is this still written in Bash?

Yes, fronted by PowerDNS.

https://github.com/basecamp/xip-pdns/blob/master/bin/xip-pdn...

Cool idea. I use dnsmasq locally but seems like this would work well too.

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?

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.

That's not an HTTP error code.

yes