HN Explorer

Show HN: Backname.io – every IP address gets its own domain (backname.io)

46 points by Twixes ↗ HN
I was setting up tests involving DNS resolution recently, where something like 127.0.0.1.service.foo would have been tremendously useful. Back in the day, I'd have used xip.io - but sadly that service died.

Well, every excuse is a good one when it comes to writing a DNS server! Backname.io joins nip.io and sslip.io in the wildcard DNS game.

48 comments

[ 3.1 ms ] story [ 340 ms ] thread
pipo234
> 127-0-0-1.backname.io resolves to 127.0.0.1

Is this enough to fool Edge (Windows 10) into allowing you to view your local Apache development environment?

repelsteeltje
That should allow access to port 80, maybe. But for TLS, you still need some CA to certify you're you. And you won't be able to convince LetsEncrypt that you control 127-0-0-1.backname.io because it resolves to localhost, which isn't you (from LetsEncrypt's perspective) :-)
pipo234
:-(

Developing on a webserver that runs locally on your desktop is becoming more an more painful.

fragmede
Chrome has an exception for requiring tls on localhost for certain services. That, plus an extension to disable CORS on it has gotten me as far as I've needed (so far). What roadblocks have you come across?
Sohcahtoa82
Couldn't you bind localhost.yourdomain.com to a public IP, get a certificate, install that certificate locally, then change localhost.yourdomain.com to resolve to 127.0.0.1?
da768
You can even use a DNS challenge and leave the 127.0.0.1 record in place.
Phrodo_00
If you want a CA you can just make a CA and add it to your trusted certificates.
fragmede
Split horizon DNS could work, if you're able to run your own DNS server for your local network.
YaBa
I'm failing to see the utility of this if I still have to type the IP address. Also, it fails using local address like 192-168-1-1.backname.io where it might be usefull somehow, so, please explain. Thanks.
globular-toast
I didn't understand first either. I first discovered these playing around with Rancher which would use xip.io for the same thing.

The point is some protocols require you to actually resolve a domain name. For example, if you set up a vhost or reverse proxy with Apache or nginx, it will use the domain name to figure out what vhost you were trying to access. When you request a page like google.com the browser resolves that to an IP address, but it sends google.com with the request.

So say you have a reverse proxy at 1.2.3.4. You could make two vhosts: site1.1.2.3.4.backname.io and site2.1.2.3.4.backname.io and it would just work from any browser on your network.

You can do this locally using the hosts file before you set up your DNS for real, but a service like this means you don't even have to do that. Useful for quick experiments.

YaBa
Ok, but piHole can also be used to set up fake domains to be used inside the network.
globular-toast
Think your company network where you can set up tests and stuff for colleagues but you don't control the DNS.

I guess it's the kind of thing if you need it, you'll know. There's no point looking for a reason to use this.

distract8901
Something I encountered recently: I have a jellyfin server hosting shows and movies that I would like to play on my Chromecast on my local network.

This is 100% not possible. The Chromecast always hits Google's DNS to resolve the media server's address. Which means you must host your media under a resolvable domain name, exposed to the internet.

This kind of thing (assuming it can resolve through Google DNS) would short-circuit that requirement. You could feed it a domain name that points back to a local address and not expose your server to the internet.

Of course there are other ways around the problem, but this would be far, far simpler. Honestly it seems like it'd be faster and simpler than setting up a subdomain and reverse proxy, which is what I did.

chatmasta
Chromecast hits 8.8.8.8 and 8.8.4.4 for DNS, so if you can configure your router to route port 53 on those addresses to your router's address, then it will use your router's DNS server, which can resolve IP addresses on your local network.
YaBa
Thanks, but I can do the same using PiHole and setting up a fake DNS
jeauxlb
Some of the utility is that if you're on an IPv6-only connection that uses 464XLAT and are trying to connect to a host, DNS lookups are required for the 4-to-6 translation process.
somplex
There is always use cases for things.

I had to make something similar in the past just for my own use case.

plagiat0r
The trick here is that this can be a value (rrdata) for NS records ;)

Or CNAME rrdata. Or MX rrdata. Albeit, there is little point in using it this way, as oppose to just add A record in your own domain anyway...

For people without a domain and a static IP, this may be useful too too publish a page, and possibly obtaining ACME tls cert.

ttymck
Does this serve the same purpose as .in-addr.arpa?
globular-toast
That's for reverse DNS. This is forward DNS. Think of it like a domain that maps to every possible IP address.
ttymck
I fail to see the difference.

127.0.0.1.in-addr.arpa and 127.0.0.1.backname.io are both domains to IP address, yes? That's "forward dns" in both cases, i think.

J_tt
in-addr.arpa domains don’t resolve to an IP address, an IP address resolves to them, you can test this with DIG or any dns look up tool
globular-toast
Does it? Try dig any 8.8.8.8.in-addr.arpa you'll get dns.google.com or something. No IP address.
globular-toast
xip.io was indeed useful. nip.io seems to still work.

Isn't the main useful aspect that you can do xyz.1.2.3.4.backname.io where xyz is anything you want? Perhaps you set this up anyway, but would be worth mentioning.

SeriousM
https://sslip.io/ is the mental successor to xip and alike. Works perfect and they have no intentions to shut down the service.
gitgud
This is cool! So I can spin up a server, then instantly get a domain and then an SSL cert, nice!
belltaco
You can get SSL certs for ip addresses.
paranoidrobot
I don't think this will help that much.

As belltaco says, you can get a (paid) SSL Certificate for IPs.

However there are caveats - it can't be a private IP.

All the paid certificate providers won't issue certs for RFC1918 or other non-publicly routable IP ranges.

So, you'd need to have a public IP, and be able to prove control of it in some way.

If your use-case is TLS Certs on your home/lab/internal networks -- this isn't going to help.

e: To be clear, LetsEncrypt would likely issue for this domain, however they won't be able to verify ownership using the TLS-SNI-01 or TLS-ALPN-01 methods by directly calling 192-168-1-1.backname.io, and you can't meet the DNS-01 challenge requirements because this service doesn't let you set DNS records.

eyepeevee
Nice. I've seen other usecases for this.

Accessing an IPv4 address on a IPv6-only network with NAT64/DNS64 is only possible if you access that IPv4 via a DNS name that resolves to the IPv4 address. DNS64 will turn your A record into an AAAA record, with the IPv4 address mapped to a v6 addrsss that the NAT64 layer knows how to "undo".

I've seen others need this a few times in practice.

quickthrower2
The problem is someone ends up using one of these in production. Then backname.io becomes an attractive target.

It would be cool to have it as a locally installed custom DNS resolver on the developers computer though.

safetytrick
I've been patiently watching for a nice way to plug in a local development DNS resolver (patiently waiting for someone to document and script the a few tiny patterns).
borplk
dnsmasq is a good option for that
thefilmore
I can think of at least four reasons and security concerns not to use a service like this:

- Exposing a potentially private IP to an external service

- If testing local IPs, adds a requirement for an internet connection

- Must trust that it will always resolve to the actual IP not another one

- Requires your service to accept a hostname that it likely shouldn't

paranoidrobot
> Exposing a potentially private IP to an external service

I have to ask why knowing an IP address would be an issue.

Surely it's not the key point in any reasonably possible exploit.

thefilmore
If you're using this for testing, it's likely that you haven't fully locked down your server yet. It's not an exploit in itself but it potentially makes the server a target. No reason to do that until and unless it's required.
paranoidrobot
But this day want make the IP accessible, just "known".

It's still a private IP.

ncruces
https://github.com/ncruces/keyless was my attempt to provide you with the necessary tools to build your own service that would not only:

  - give you a domain for any IP (even local IPs);
  - give you SSL on that domain (even local IPs!);
  - abide by Let's Encrypt terms.
plagiat0r
Just by looking at the handler, it is not RFC compliant. I do not see SOA record being generated properly nor do I see a proper handling of nxdomain vs nodatae responses.

See RFC 2308.

plagiat0r
When looking more closely at the code, this violates RFC in multiple ways, no SOA record, answers for NS are catch-all by qtype, resolve() doesn't modify authority or additional sections, they're not implemented. ANY qtype not implemented.

I'm not a fan of nodata responses with empty authority, same as nxdomain responses.

Missing TCP listener. While not required by any RFC, some ccTLD Registries enforce udp+tcp before delegating, like .de

plagiat0r
Also, for "www' you either return address records or cname, never both. This is a violation of RFC...