I got tired of editing my host file for local development. Have been meaning to do this for a while, but I never had a domain name short enough so as not to be annoying to type.
This is brilliant. Just wait till lots of people are using this, load up a ton of patched software for every known protocol to record usernames and passwords on a machine. Then you can just intermittently have the domain resolve to that machine and collect the usernames and passwords. It'll be difficult to detect because it won't even be reproducible.
Not following how this might present a security issue, but I'm curious for you to expand on this. Seems like even if the DNS record managed to change in the midst of a POST request, the post would pretty obviously fail to perform as expected.
But yes, an obvious disclaimer of "don't trust me by POSTing your bank passwords to any of these subdomains" might be in order.
You can trivially farm data that people are sending to their local apps by having DNS occasionally change to an IP you own (and then immediately back, to avoid detection). On that IP, you would have something that remembers the parts of the request that might be interesting (query parameters, body) and return a benign-looking error (just severing the connection without a response would probably do it). At the very least, you'd probably get some email/pass pairs that work on a few major sites.
From your browser's perspective, the POST would fail, if it expected a certain response. That would happen after the site already recorded the contents of your POST.
It is generally more difficult to edit a hosts file on a phone or tablet or on your non-technical coworker's computer. xip.io is useful for these situations.
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.
For example, I use dev.projectname.com for every project I work on locally. This way, the auto-filled usernames/passwords never get mixed up between projects, as they do when you do everything on 127.0.0.1:8000
If you develop multiple websites on your local machine, you distinguish them by using different domain names for each of them. You might have site1.dev and site2.dev.
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).
Is the point of this that a proxy server on your local machine has access to the domain names (site1.til.io and site2.til.io) and can forward the request to the appropriate service on your local machine by modulating on the subdomain?
OT, but someone should start the .JS TLD for the tons of useful javascript libs out there. How awesome would it be to just go to Angular.js or node.js and have that be their actual site?
I agree, but it would need someone to put up the $180,000 non refundable fee for it to be considered or whatever it is. Google could afford that, but then imagine the storm they'd get from the JS community..
Your browser asks the DNS server for the IP address corresponding to the domain name. If you ask for google.com it will reply e.g. 74.125.228.228 and then your browser will connect to 74.125.228.228 directly. When your browser asks that same DNS server for til.io's IP address, it gets 127.0.0.1, and then your browser connects to 127.0.0.1!
Relying on a magical domain "just for development" is extremely careless behavior. Even assuming that these addresses always resolved to 127.0.0.1 with no interruption, slowdown, or redirection ever, do you really want to be leaking private hostnames etc. over the internet? Simply run a local DNS with forwarding, create a zone or two for your internal machines, all done. And you can even have other record types besides A and PTR...
Do you mean that I am understating the difficulty of running DNS on a development workstation or home network? Running secure DNS at huge scale is challenging, but a puny server to mess around with is 1/10 the challenge of almost any development chore. (Apologies if I misunderstand the comparison to monad-speak.)
I'm basically saying you're overestimating the average developer's understanding of the running of a private DNS server at all. Monoids and endofunctors aren't actually difficult either, but they're arcane knowledge that most people don't have, so any statement that relies on average developers having that knowledge is a bit unrealistic.
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.
Oh lord, you made me read those fake histories again. They consistently tickle my funny-bone in an unusually strong way and I'm not entirely sure why exactly. Can anyone recommend more of this kind of stuff?
Or, as I posted elsewhere in this thread, just setup dnsmasq for a very straightforward way to wildcard an entire TLD to 127.0.0.1. See [1] for setup details on OS X, which should be easily adaptable to other *nixen.
If you use Vagrant for development, there are some plugins that will modify your HOSTS file automatically when you start your Vagrant VM. See for instance https://github.com/cogitatio/vagrant-hostsupdater
Or, if you have your own domain, set up a wildcard in your DNS, which could be external (I use cloudflare - free and reliable).
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>
We have something very similar at our workplace. *.l.tsl.io resolves to localhost. We usually use it to test hostnames[1] on our django projects on the the local developeent server. Definitely beats having to add a lot of records to /etc/hosts.
This looks like another .lvh.me Although it's nice to have a backup.
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.
It resolves at least to that for now. Until someone forgets to pay the bill (for various reasons), runs out of money in their bank account to keep it up or whatever reason there might be.
Then devs around the globe scramble to find out what data might have been leaked and to whom.
It's around $50 a year for the domain, which is a cost I'm happy to eat as I'm using it myself.
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.
I'll recommend using dnsmasq plus some local resolver configuration to set up your own host-local magic domain, eliminating the need for reliance on a third-party magic domain.
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.
I love Pow, but I really, really wish they'd change their default tld from .dev to .local.
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.
That won't work if you're using mDNS on the local network, as the dnsmasq resolution will hijack all queries to .local.
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
I usually just use the real sitename with a .vm tld if I'm working in local dev space.
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.
In my hosts file, sites that are on my local vm are referred to as project1.vm, project2.vm and so on.
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.
80 comments
[ 3.3 ms ] story [ 145 ms ] threadBut yes, an obvious disclaimer of "don't trust me by POSTing your bank passwords to any of these subdomains" might be in order.
> 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
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...
This is useful when you want to have several different virtual hosts on your machine, all of which would otherwise be called "localhost".
This applies to monads too.
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.
[1] http://passingcuriosity.com/2013/dnsmasq-dev-osx/
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>
[1]: http://django-hosts.readthedocs.org/en/latest/
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.
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.
I freed that one up.
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/
[2] http://passingcuriosity.com/2013/dnsmasq-dev-osx/
[3] https://github.com/progrium/dokku
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.
1 http://icannwiki.com/.dev
2 http://en.wikipedia.org/wiki/.local
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
https://ngrok.com/
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.
In 2014?