
Give HN: *.til.io resolves to 127.0.0.1 - jtolj
http://til.io
======
sk5t
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...

~~~
chc
This kind of reminds me of "A monad is just a monoid in the category of
endofunctors, what's the problem?"

~~~
mercer
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?

~~~
0942v8653
For anyone not getting the reference, here's the link: [http://james-
iry.blogspot.com/2009/05/brief-incomplete-and-m...](http://james-
iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html)

------
slig
See also: [http://xip.io/](http://xip.io/)

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

~~~
unfamiliar
That seems like more of a mess than just "messing with the hosts file." What
happens when your ip changes and none of your links work correctly?

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

~~~
unfamiliar
>And if your IP address changes, surely it is more of a pain to edit the hosts
file again

You wouldn't need to edit the hosts file, since your made up domain would just
point to 127.0.0.1

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

[1] [http://pow.cx/](http://pow.cx/)

[2] [http://passingcuriosity.com/2013/dnsmasq-dev-
osx/](http://passingcuriosity.com/2013/dnsmasq-dev-osx/)

[3] [https://github.com/progrium/dokku](https://github.com/progrium/dokku)

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

1 [http://icannwiki.com/.dev](http://icannwiki.com/.dev)

2 [http://en.wikipedia.org/wiki/.local](http://en.wikipedia.org/wiki/.local)

~~~
saidajigumi
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

~~~
scott_karana
I guess .localhost (already reserved for exactly that purpose) would work
then. :)

------
Spone
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](https://github.com/cogitatio/vagrant-hostsupdater)

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

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

------
rdtsc
So does localhost

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

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

------
seanp2k2
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?

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

~~~
TazeTSchnitzel
Worse than that: Someone would need to found a country called JavaScriptLand.
2-letter domains are reserved for ccTLDs.

~~~
petercooper
Good call! I could imagine a country being easier to form than getting the
community to agree who would own a GTLD anyway.. ;-)

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

[1]: [http://django-hosts.readthedocs.org/en/latest/](http://django-
hosts.readthedocs.org/en/latest/)

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

~~~
kgc
How do you do that .vm thing?

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

------
Kiro
Can someone explain what the puprose is?

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

~~~
monk_e_boy
.dev? heathen! .local please :)

~~~
jatoben
Careful; if you or your coworkers use OS X, you may run into conflicts with
Bonjour-registered hostnames.

------
devoldmx
I have used this for a while and it works fine. I understand that it is not
for every project, but you can set up quickly an app.

[https://ngrok.com/](https://ngrok.com/)

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

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

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

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

------
jongalloway2
[http://readme.localtest.me/](http://readme.localtest.me/)

------
sildur
Also, [http://whatever.new/](http://whatever.new/)

------
tootie
How does this work? Isn't 127.0.0.1 a loopback? How does it get to the
internet?

~~~
astrodust
The point is it doesn't go to the internet, it just sets up an alias to your
local machine.

This is useful when you want to have several different virtual hosts on your
machine, all of which would otherwise be called "localhost".

~~~
extc
It does go to the Internet, for the DNS query. This won't work offline.

------
swalsh
This is pretty cool. Thanks, will be using.

------
spacefight
Well, www.til.io doesn't, for a start.

~~~
jtolj
Touche.

I freed that one up.

------
dingaling
Ingenious idea, but no AAAA RR for ::1?

In 2014?

~~~
jtolj
Good call, added. Might take a few to propogate.

~~~
dingaling
Cheers!

------
_mikz
like lvh.me. also check xip.io

