Give HN: *.til.io resolves to 127.0.0.1
til.io
til.io
Basically, I'm pretty sure I could apt-get install bind, but then I would have no clue what I was doing and I'm not entirely sure what setting up a zone entails. These problems are probably all quite solvable, but without the foundational knowledge, it's not 1/10.
This applies to monads too.
> xip.io is a magic domain name that provides wildcard DNS for any IP address
So you can test stuff on your phone/tablet without messing with 'hosts' file, for instance: myapp.192.168.0.1.xip.io will resolve to 192.168.0.1.
edit: It's smack on the front page of xip.io :) "xip.io runs a custom DNS server on the public Internet.".
And if your IP address changes, surely it is more of a pain to edit the hosts file again on these several other phones/tablets/computers than to just send a new link.
You wouldn't need to edit the hosts file, since your made up domain would just point to 127.0.0.1
Pow[1] by the Basecamp folks provides a nicely packaged version of dnsmasq tooling for Rack & Rails apps. See also, the guard-pow and powder gems which make using Pow even nicer.
For other cases (and the DIYers among us) Thomas Sutton wrote up instructions for setting up dnsmasq[2] on OS X for app development. IIRC, the dnsmasq setup should be identical on other *nix flavors. Your local resolver configuration may vary, but this guide will get you pointed the right direction. I highly recommend reading [2] even just as a guide to understand/demystify what Pow does under the hood.
The dnsmasq setup can also be used for tools like Dokku[3], a Heroku-style service you can run in (e.g.) a local VM.
[1] http://pow.cx/
The .dev TLD might end up existing soon[1], whereas .local is reserved and will never exist on root nameservers[2]. So eventually, developers using Pow might have conflicts between their local-only dev sites and real websites. Bad mojo.
Really, there just needs to be a small set of reserved TLDs. This includes one for which queries should never* be issued off a given host. .local (== 127.0.0.1) would have been ideal, but zeroconf slurped it up first. I'd put my vote in for .dev, but the Wikipedia link indicates that Google's looking to score it. :-P
Then devs around the globe scramble to find out what data might have been leaked and to whom.
But yes, if you're working on top secret projects or something that might leak sensitive data it's probably not a good idea to use this or any of these other services.
Example:
I own rikk.us and want to be able to set up many websites on a few machines with my network, so:
I point ✱.l.rikk.us to my laptop and now I can set up as many websites as I like on my laptop, so long as they have a binding matching ✱.l.rikk.us, and have them all work just as if they were on separate hosts.
This allows me to make testsite1.l.rikk.us, testsite2.l.rikk.us, oh.bugger.i.broke.it.l.rikkus.us, etc.
✱ Sorry for the heavy asterisks but I don't know how to write a normal one without it triggering <em>
I've found this invaluable when testing subdomains. Each of our accounts gets their own subdomain and testing that is a huge pain with a hosts file (need to explicitly map each one).
The wildcard nature of .til.io or .lvh.me is key.
The only issue I've noticed with 192.168.1.101.xip.io is that if your server code splits domains on dots and expects things to be in the "nth" place then things can go wrong (cough cough Rails).
The other thing this is super useful for is testing subdomains locally from a mobile device.
If it turns out that someone starts up a .vm tld for real, well, no loss. I'll just switch to something else.
There's no right and no wrong way to do this on your local machine as long as you don't break the internet for everyone else and as long as it's repeatable/undoable.
Each virtual host is configured with the name project1.vm and so on and so forth.
If I really felt like it, I could put a site on my called yahoo.com and change my hosts file to point that instead. I don't use yahoo for anything (nothing against them, I just don't) so it wouldn't hurt anything.
Additionally, my vms all have two network addresses - one is dynamic from my router (for updates, etc.) and one is a host-only connector with a fixed IP. That's the address I use to connect to the sites.
I don't bother with running a private DNS or anything - I'm more concerned with site development, not routing issues. The VM is an ends to a means and all that other stuff, while useful to know, takes up time I don't really feel like spending.
There are a variety of methods to handle this, but commonly you add a record to your system's host file to resolve these domain names to the ip address 127.0.0.1 (your local computer).
Using site1.til.io and site2.til.io instead eliminates having to manage that host file (which is a minor and repetitive annoyance).
For instance: http://www.charlesproxy.com/documentation/faqs/accessing-loc...
But yes, an obvious disclaimer of "don't trust me by POSTing your bank passwords to any of these subdomains" might be in order.
This is useful when you want to have several different virtual hosts on your machine, all of which would otherwise be called "localhost".
I freed that one up.
In 2014?