Show HN: Backname.io – every IP address gets its own domain | Hacker News Reader

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

backname.io

46 pointsTwixes48 comments

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.

Open articleView on HN

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.

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.

Well, there's no reason they can't run it locally: https://github.com/Twixes/backname

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

dnsmasq is a good option for that

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.

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.

Ok, but piHole can also be used to set up fake domains to be used inside the network.

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.

192-168-1-1.backname.io works for me. It might be useful to get DV certs for temporary things that need HTTPS.

I've done a sorta similar thing to enable HTTPS for local network IPs for IoT: https://news.ycombinator.com/item?id=36593547

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.

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.

Thanks, but I can do the same using PiHole and setting up a fake DNS

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.

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.

There is always use cases for things.

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

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.

https://sslip.io/ is the mental successor to xip and alike. Works perfect and they have no intentions to shut down the service.

There is also http://traefik.me/

There is https://ipq.co/ and https://fdns.uk/ that will let you create a name to point to a chosen ip.

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.

Does this serve the same purpose as .in-addr.arpa?

That's for reverse DNS. This is forward DNS. Think of it like a domain that maps to every possible IP address.

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.

Does it? Try dig any 8.8.8.8.in-addr.arpa you'll get dns.google.com or something. No IP address.

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

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

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

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.

But this day want make the IP accessible, just "known".

It's still a private IP.

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.

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

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

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

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) :-)

:-(

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

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?

You can even use a DNS challenge and leave the 127.0.0.1 record in place.

Use Firefox. No problems at all here.

Have you checked out https://www.getlocalcert.net/ yet? They're working on adding more login options than just Github, but they're not quite there yet.

If you want a CA you can just make a CA and add it to your trusted certificates.

Not sure if this works for Windows, but the author knows what he is doing and his technique seems fairly well thought out.

https://github.com/FiloSottile/mkcert

+1 for `mkcert`

Works like magic!

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?

Split horizon DNS could work, if you're able to run your own DNS server for your local network.

This is cool! So I can spin up a server, then instantly get a domain and then an SSL cert, nice!

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.

You can get SSL certs for ip addresses.

http://afraid.org

Reply on news.ycombinator.com