Welcome to sslip.io

sslip.io

Operational Status: ^[Status]

sslip.io is a DNS (Domain Name System) service that, when queried with a hostname with an embedded IP address, returns that IP address. It was inspired by xip.io, which was created by Sam Stephenson.

Here are some examples:

Hostname / URL	IP Address	Notes
https://104.155.144.4.sslip.io	104.155.144.4	dot separators, sslip.io website mirror (IPv4)
https://52-0-56-137.sslip.io	52.0.56.137	dash separators, sslip.io website mirror (IPv4)
www.192.168.0.1.sslip.io	192.168.0.1	subdomain
www.192-168-0-1.sslip.io	192.168.0.1	subdomain + dashes
https://www-78-46-204-247.sslip.io	78.46.204.247	dash prefix, sslip.io website mirror (IPv4)
--1.sslip.io	::1	IPv6 — always use dashes, never dots
https://2a01-4f8-c17-b8f--2.sslip.io	2a01:4f8:c17:b8f::2	sslip.io website mirror (IPv6)

Branding / White Label / Custom Domains

sslip.io can be used to brand your own site (you don’t need to use the sslip.io domain). For example, say you own the domain “example.com”, and you want your subdomain, “xip.example.com” to have xip.io-style features. To accomplish this, set the following three DNS servers as NS records for the subdomain “xip.example.com”

2021-11-27 FYI (for your information), we've switched to using our own nameservers (sslip.io) instead of the old nono.io nameservers. You don't need to change anything. Don't worry if you're pointing to the old nameservers—they'll continue to work properly. In fact, under the hood they are the same nameservers; the change is merely cosmetic: we've created sslip.io DNS records for them.

hostname	IP address	Location
`ns-aws.sslip.io.`	52.0.56.137 2600:1f18:aaf:6900::a	USA
`ns-gce.sslip.io.`	104.155.144.4	USA
`ns-azure.sslip.io.`	52.187.42.158	Singapore

Let’s test it from the command line using dig:

dig @ns-gce.sslip.io. 169-254-169-254.xip.example.com +short

Yields, hopefully: ^{[connection timed out]}

169.254.169.254

But I Want My Own DNS Server!

If you want to run your own DNS server, it's simple: you can compile from source or you can use one of our pre-built binaries. In the following example, we install & run our server within a docker container:

docker run -it --rm fedora
curl -L https://github.com/cunnie/sslip.io/releases/download/2.3.0/sslip.io-dns-server-linux-amd64 -o dns-server
chmod +x dns-server
./dns-server 2> dns-server.log &
dnf install -y bind-utils
dig @localhost 127-0-0-1.sslip.io +short # returns "127.0.0.1"

TLS

You can acquire TLS certificates for your externally-accessible hosts from certificate authorities (CAs) such as Let's Encrypt. The easiest mechanism to acquire a certificate would be to use the HTTP-01 challenge. It requires, at a minimum, a web server running on your machine. The Caddy web server is one of the most popular examples. For example, if you had a webserver with the IP address 52.0.56.137, you could obtain a TLS certificate for "52.0.56.137.sslip.io", or "www.52.0.56.137.sslip.io", or "prod.www-52-0-56-137.sslip.io".

2021-02-12 Let's Encrypt Rate Limits If your request for an "sslip.io" certificate is rate-limited, please open a GitHub issue and we'll request a rate-limit increase.

If you have procured a wildcard certificate for your branded / white label / custom sslip.io-style subdomain, you may install it on your machines for TLS-verified connections.

When using a TLS wildcard certificate in conjunction with your branded sslip.io style subdomain, you must use dashes not dots as separators. For example, if you have the TLS certificate for *.xip.example.com, you could browse to https://www-52-0-56-137.xip.example.com/ but not https://www.52.0.56.137.xip.example.com/.

if you're interested in acquiring a wildcard certificate for your sslip.io domain, e.g. "*.52-0-56-137.sslip.io", the procedure is described here.

Experimental Features

Experimental features can change; don't depend on them.

Determining Your External IP Address via DNS Lookup

You can use sslip.io's DNS servers (ns.sslip.io) to determine your public IP address by querying the TXT record of ip.sslip.io:

dig @ns.sslip.io txt ip.sslip.io +short    # sample reply "2607:fb90:464:ae1e:ed60:29c:884c:4b52"
dig @ns.sslip.io txt ip.sslip.io +short -4 # forces IPv4 lookup; sample reply "172.58.35.231"
dig @ns.sslip.io txt ip.sslip.io +short -6 # forces IPv6 lookup; sample reply "2607:fb90:464:ae1e:ed60:29c:884c:4b52"

When querying for your IP address, always include the sslip.io nameserver (e.g. @ns.sslip.io). If omitted, you won't get your IP address; instead, you'll get the IP address of your upstream nameserver.

This feature was inspired by Google's DNS lookup, i.e. dig txt o-o.myaddr.l.google.com @8.8.8.8 +short. There are also popular HTTP-based services for determining your public IP address:

A big advantage of using DNS queries instead of HTTP queries is bandwidth: querying ns-aws.sslip.io requires a mere 592 bytes spread over 2 packets; Querying https://icanhazip.com/ requires 8692 bytes spread out over 34 packets—over 14 times as much! Admittedly bandwidth usage is a bigger concern for the one hosting the service than the one using the service.

`kv.sslip.io`: (key-value) read/write/delete TXTs

We enable special behavior under the kv.sslip.io subdomain: it can be treated as a key-value store, the sub-subdomain being the key, and the TXT record being the value.

For example, to write ("put") the value "12.0.1" to the key "macos-version" on the ns-gce.sslip.io. nameserver, you'd use the following dig command:

dig @ns-gce.sslip.io. txt put.12.0.1.macos-version.kv.sslip.io.

To read ("get") the value back, you'd write the following dig command:

dig @ns-gce.sslip.io. txt get.macos-version.kv.sslip.io.

Since "get" is the default behavior, you don't need to include it in the domain name:

dig @ns-gce.sslip.io. txt macos-version.kv.sslip.io.

Finally, when you're done with the key-value, you can "delete" it:

dig @ns-gce.sslip.io. txt delete.macos-version.kv.sslip.io.

Notes:

Keys are case-insensitive (to accommodate DNS convention). In other words, KEY.kv.sslip.io and key.kv.sslip.io return the same TXT record.
Values are case-sensitive. put.CamelCase.style.kv.sslip.io sets the TXT record to "CamelCase".
put requests will return the TXT record being put; i.e. put.hello.world.kv.sslip.io returns one TXT record of one string, hello.
delete requests will return the TXT record being deleted; i.e. delete.world.kv.sslip.io returns one TXT record of one string, hello. If the TXT record does not exist, no TXT records will be returned.
Values are limited to 63 bytes to mitigate using the sslip.io servers in a DNS amplification attack.
Values are not persistent: if the server is restarted, all values disappear. Poof.
Values are not consistent. If a value is set in ns-aws.sslip.io, it does not propagate to ns-gce.sslip.io nor ns-azure.sslip.io.

Determining The Server Version of Software

You can determine the server version of the sslip.io software by querying the TXT record of version.sslip.io:

dig @ns-aws.sslip.io txt version.sslip.io +short
            "2.2.3"
            "2021/11/27-11:35:50-0800"
            "074f0a8"

The first number, ("2.2.3"), is the version of the sslip.io DNS software, and is most relevant. The other two numbers are the date compiled and the most recent git hash, but those values can differ across servers due to the manner in which the software is deployed.

xip.io: the inspiration for sslip.io
nip.io: similar to xip.io, but the PowerDNS backend is written in elegant Python
localtls: A DNS server + webserver to provide TLS to on local addresses.

Footnotes

^[Status] A status of “build failing” rarely means the system is failing. It’s more often an indication that when the servers were last checked (currently every six hours), the CI (continuous integration) server had difficulty reaching one of the three sslip.io nameservers. That’s normal. ^{[connection timed
out]}

^{[connection timed out]}

DNS runs over UDP which has no guaranteed delivery, and it’s not uncommon for the packets to get lost in transmission. DNS clients are programmed to seamlessly query a different server when that happens. That’s why DNS, by fiat, requires at least two nameservers (for redundancy). From IETF (Internet Engineering Task Force) RFC (Request for Comment) 1034:

A given zone will be available from several name servers to insure its availability in spite of host or communication link failure. By administrative fiat, we require every zone to be available on at least two servers, and many zones have more redundancy than that.