Perhaps I am missing something - what problem does this solve? Instead of an IPv4 address, you are now entering (optional) prefix, the IPv4 address, and a postfix ".xip.io" Where is the added value over entering the IP address directly?
I have something against stupid trends. io is a gcc TLD, shouldn't be polluted just because everybody thinks it's the cool 2014 way to build something hype.
You can set up your web server to serve different applications on different domains if you're working on multiple projects at the same time and don't want to put them on different ports or use subdirectories.
Another use case I can see is for testing subdomain-based web apps where you give each customer a subdomain (really just a wildcard dns record), e.g. acme.myapp.com
Why not just customizing /etc/hosts then... You guys are relying too much on 3rd party tools without knowing what they do with your data and what they're becoming in the future.
Testing web page with custom subdomain in a mobile devices, passing a test URL to co-workers, etc. I did this a lot, even though I have my own DNS server setup for this purpose in my own LAN, I could see myself using this if I don't already have the DNS set up.
In most cases, customizing /etc/hosts would require every person working on a project to customize their /etc/hosts the same way. It becomes a burden when somebody wants to add or change an entry. They would need to email everybody who works on the project to tell them all to make the same change.
It's a DNS server. The only data they can get from you is what you're calling the subdomains on your apps.
Yes, you could achieve the same functionality by editing /etc/hosts, but that's a pain in the arse if you're rapidly switching between a set of different sites, or if you want to access a coworker's machine in the same way.
You guys are complaining too much about useful hacker-friendly tools from well-known companies.
Editing /etc/hosts also requires root access, which becomes an issue if you're running tests on a shared server that's locked down, rather than just on your PC.
If you're developing an app that relies on wildcard subdomain matching - all the organization-oriented apps that give you a your-team-name.example.com URI, for instance - fiddling with /etc/hosts is going to become a chore.
Using this service doesn't touch our "data" in any way whatsoever. It's a DNS service; it's not like I need to give them access to my Postgres database and Google Analytics password.
For local testing you can simply use the whole 127.0.0.0/8 subnet. If your webserver's listening socket is bound to the any-local address (0.0.0.0) then you can setup 127.0.0.1, .2, ... , 127.255.255.254 as vhosts.
my use case: some of services won't allow me to interact with them (i.e. oauth) unless I register a domain.
127.0.0.1 and "localhost" do not work, 127.0.0.1.xip.io inexplicably does.
This is very useful for me, because lots of the software I write is SaaS where the customer has their own subdomain - and testing on mobile in a local network is a PITA.
Think of setting acme.example.local and foo.example.local in hosts to 127.0.0.1. In my code I have middleware that sniffs the leftmost part of the hostname and authenticates and routes based on that info.
With this I don't need to mess with hosts, and I don't need to worry about putting in a hack for mobile (on which you cannot change any hosts).
It's just DNS, which doesn't bring port into the picture. A domain name resolves to an IP address separately from whatever ports the server at that address might listen on.
Hmm, this doesn't seem to be working for me in the same way that xip.io does.
One of my favorite features of Pow (also 37Signals, mentioned on xip.io) is the ability to forward .dev domains to certain ports. For instance:
`echo 3000 >> ~/.pow/myapplication` gives you `myapplication.dev` as an alias for `localhost:3000`.
xip.io seems to be able to figure that out -- myapplication.10.0.0.1.xip.io will work, whereas myapplication.10.0.0.1.nip.io does not (just shows the Pow page you would see for going to `localhost`).
Am I missing something here to get it to work with nip.io? I'm all for simpler tools, but since the port functionality is 100% of what I use Pow for, xip.io seems to be the way to go for now.
Pow has a special support for .xip.io domain[1]. If you add `export POW_EXT_DOMAINS=10.0.0.1.nip.io pow` to `~/.powconfig` it should work[2]. I haven't tried this myself though.
It has built-in support for .xip.io domains; you can configure multiple sites by pointing it at local directories and it'll serve them up using a built-in POW server (http://pow.cx, also from 37signals).
Great for example for remote testing on your local LAN without having to mess with your HOSTS file.
Is it just me or does anybody else also find it really annoying that the blinking cursor there (behind the “everyone”) is not actually a cursor and one cannot delete text with backspace?
I can see how this would be useful for testing across-device inside your home network, but for resolving domains for development on my macbook I prefer dnsmasq which I set to resolve the tld .dev to localhost. [1] I'm often commuting by bus/train so I don't have a stable internet connection at all time so I couldn't use xip.io anyway.
For php apps the only thing I need to do currently is make a symlink, and an apache vhost entry makes it work [2], kinda like pow! Thinking about it, I could even make that symlink step optional, or add passenger to the mix to support nodejs/rack apps.
+1 for using Apache's vhost_alias module [1]; it's interesting how few people are aware of it. DNS wildcards + vhost wildcards make for a very convenient dev environment.
Here is the comment in the config file for the option:
# Enforce privacy of these addresses. Strips them away from answers.
# It may cause DNSSEC validation to additionally mark it as bogus.
# Protects against 'DNS Rebinding' (uses browser as network proxy).
# Only 'private-domain' and 'local-data' names are allowed to have
# these private addresses. No default.
The reason I have this enabled is because it can help stop certain attacks against the local network!
I always use my own resolver, with powerdns recursor, because some ISPs resolvers are dog slow. If you have such a setup, it's really simple to set aside a tld for development.
On the powerdns recursor configuration, tell it to authoritatively serve a tld:
auth-zones=dev=/etc/powerdns/dev.zone
And then use a BIND style zone definition file. Something like:
@ 86400 IN SOA ns root 1 604800 86400 2419200 604800
86400 IN NS ns
86400 IN A 127.0.0.1
* 86400 IN A 127.0.0.1
Now, domains such as "newshiningapp.dev" or "imgonatakeovertheworld.dev" resolv to 127.0.0.1.
Am a little lost. Why cant we use hosts file instead? I would understand if it was complicated. But add entries to hosts is super simple and definitely requires no special knowledge.
As binarymax mentioned[1], it's very useful when you want to test on multiple devices where editing the host file would be undesired or not possible. This includes mobile devices or computers that are not your own or that you don't have administrative access to. It's also easier to just share a link instead of asking people to change their hosts file just to test a part of a site.
A word of warning for any UK based BT customers: xip.io doesn't work on BT Home Hub 5! I recently upgraded to the 5 from a Home Hub 3 (which it worked fine on), but had to send it back because of this. The 'BT tech experts' couldn't give an explanation. Has anyone else had the same issue?
73 comments
[ 0.25 ms ] story [ 115 ms ] threadAnyway, out of subject.
[0]http://nic.io
I guess the 'TLD's shouldn't be polluted' ship has sailed quite some time ago.
[1] http://tools.ietf.org/html/rfc1591
Another use case I can see is for testing subdomain-based web apps where you give each customer a subdomain (really just a wildcard dns record), e.g. acme.myapp.com
Yes, you could achieve the same functionality by editing /etc/hosts, but that's a pain in the arse if you're rapidly switching between a set of different sites, or if you want to access a coworker's machine in the same way.
You guys are complaining too much about useful hacker-friendly tools from well-known companies.
[1] https://github.com/sstephenson/xipd
No need for DNS or different ports.
Think of setting acme.example.local and foo.example.local in hosts to 127.0.0.1. In my code I have middleware that sniffs the leftmost part of the hostname and authenticates and routes based on that info.
With this I don't need to mess with hosts, and I don't need to worry about putting in a hack for mobile (on which you cannot change any hosts).
One of my favorite features of Pow (also 37Signals, mentioned on xip.io) is the ability to forward .dev domains to certain ports. For instance:
`echo 3000 >> ~/.pow/myapplication` gives you `myapplication.dev` as an alias for `localhost:3000`.
xip.io seems to be able to figure that out -- myapplication.10.0.0.1.xip.io will work, whereas myapplication.10.0.0.1.nip.io does not (just shows the Pow page you would see for going to `localhost`).
Am I missing something here to get it to work with nip.io? I'm all for simpler tools, but since the port functionality is 100% of what I use Pow for, xip.io seems to be the way to go for now.
[1]: https://github.com/basecamp/pow/blob/master/lib/configuratio...
[2]: http://pow.cx/docs/configuration.html
[1] https://github.com/sstephenson/xipd/commit/ea40f65300ccc3d32...
I guess this is because it's been used by some bad guys already.
It has built-in support for .xip.io domains; you can configure multiple sites by pointing it at local directories and it'll serve them up using a built-in POW server (http://pow.cx, also from 37signals).
Great for example for remote testing on your local LAN without having to mess with your HOSTS file.
For php apps the only thing I need to do currently is make a symlink, and an apache vhost entry makes it work [2], kinda like pow! Thinking about it, I could even make that symlink step optional, or add passenger to the mix to support nodejs/rack apps.
[1]: https://github.com/larrybolt/dotfiles/blob/master/homebrew/p...
[2]: https://github.com/larrybolt/dotfiles/blob/master/apache/999...
I've toyed with bonjour spoofing before, but I always found querying was incredibly difficult, using dns-sd, e.g.:
Obviously tailored specifically for that project, but I hope you catch my drift. And add to that the port lookup.I'm fairly certain I'm not using it as you do, so would you mind giving an example of how your use MDNS for local dev testing?
[1] - http://httpd.apache.org/docs/2.2/mod/mod_vhost_alias.html
https://news.ycombinator.com/item?id=4081591
On the powerdns recursor configuration, tell it to authoritatively serve a tld:
And then use a BIND style zone definition file. Something like: Now, domains such as "newshiningapp.dev" or "imgonatakeovertheworld.dev" resolv to 127.0.0.1.http://clickontyler.com/virtualhostx/
Xip.io is enormously useful if you are testing on virtual machines or mobile devices.
Allowing this on your network opens you up to http://en.wikipedia.org/wiki/DNS_rebinding attacks.
[1] https://news.ycombinator.com/item?id=7732756
Switching to Google DNS (8.8.8.8) temporarily fixed it.