Welcome to nip.io / sslip.io

nip.io & sslip.io

Operational Status: ^[Status] Queries / second

nip.io and sslip.io are a DNS (Domain Name System) service that, when queried with a hostname with an embedded IP address, returns that IP address.

nip.io and sslip.io have been in operation for over ten years. They have become so popular that our servers receive over 5,000 queries every second, so mainstream that Google references both nip.io and sslip.io in their Kubernetes documentation!

Here are some examples (the domains nip.io and sslip.io are interchangeable):

Hostname / URL	IP Address	Notes
https://52.0.56.137.sslip.io	52.0.56.137	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)
https://334B3513.nip.io/	51.75.53.19	sslip.io website mirror (hexadecimal notation)

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”

hostname	IP address	Location
`ns-do-sg.sslip.io.`	146.190.110.69 2400:6180:0:d2:0:1:da21:d000	Singapore
`ns-hetzner.sslip.io.`	5.78.115.44 2a01:4ff:1f0:c920::	USA
`ns-ovh.sslip.io.`	51.75.53.19 2001:41d0:602:2313::1	Poland

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

dig @ns-ovh.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/5.0.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.nip.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 ^{[fake news]}. 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.nip.io", or "www.52.0.56.137.nip.io", or "prod.www-52-0-56-137.nip.io".

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

nip.io & sslip.io do not support wildcard certificates.

traefik.me: Also an excellent service maintained by Michael Hurni "pyrou" using the original nip.io PowerDNS + Python backend.
afraid.org: Josh Anderson has taken DNS hosting to a whole new level: "Free DNS Hosting, Dynamic DNS Hosting, Static DNS Hosting, subdomain and domain hosting". You don't need to embed your IP address in the hostname!
ipq.co: John Leach also has take DNS hosting to a whole new level: "It’s the tinyurl of the DNS world". You don't need to embed your IP address in the hostname!
nip.io: formerly a separate service, but now incorporated into sslip.io. The service previously used PowerDNS combined with a backend written in elegant Python.
backname.io™: An excellent service maintained by Michael Matloka using Golang + Miek Gieben's awesome DNS library.
xip.io: written by Sam Stephenson, this was the original inspiration for sslip.io. The backend was written in the tightest bash code I've ever seen. No longer in service.
Let's Encrypt: A Certificate Authority providing TLS certificates; they have never failed to increase our rate limits when asked. If you can, donate.

About

Tyler Schultz, Alvaro Perez-Shirley, and Brian Cunnie created sslip.io on Tuesday August 11, 2015 during a Pivotal Software-sponsored Hack Day. Thanks Pivotal!

Brian Cunnie has continued to run sslip.io since then.

Sam Stephenson, who built xip.io, suggested the name sslip.io.

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.nip.io) to determine your public IP address by querying the TXT record of ip.nip.io:

dig @ns.nip.io txt ip.nip.io +short    # sample reply "2607:fb90:464:ae1e:ed60:29c:884c:4b52"
dig @ns.nip.io txt ip.nip.io +short -4 # forces IPv4 lookup; sample reply "172.58.35.231"
dig @ns.nip.io txt ip.nip.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 nip.io name server (e.g. @ns.nip.io). If omitted, you won't get your IP address; instead, you'll get the IP address of your upstream name server.

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.nip.io requires a mere 594 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.

Determining The Server Version of Software

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

dig @ns-ovh.nip.io version.status.nip.io txt +short
  "5.0.0"
  "2025/08/30-19:52:37-0700"
  "afb37dd"

The first number, ("4.1.0"), is the version of the nip.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.

Server Metrics

You can retrieve metrics from a given server by querying the TXT records of metrics.status.nip.io

  dig @ns-ovh.nip.io metrics.status.nip.io txt +short
    "Uptime: 13940"
    "Blocklist: 2025-11-07 08:08:50-08 3,773,2"
    "Queries: 58116774 (4169.1/s)"
    "TCP/UDP: 457/58259316"
    "Answer > 0: 18236428 (1308.2/s)"
    "A: 15664900"
    "AAAA: 119999"
    "TXT Source: 3"
    "TXT Version: 3"
    "PTR IPv4/IPv6: 8/0"
    "NS DNS-01: 147"
    "Blocked: 13421"

Explanation of Metrics

Uptime: The time since the DNS server has been started, in seconds
Blocklist: The first value ("2023-10-04 07:37:50-07") is the date the blocklist was last downloaded. The following three numbers are the number of CIDR matches that are blocked (e.g. 86.106.104.0/24), the number of IP addresses that are blocked (e.g. 212.64.214.54), and the number of strings that are blocked (e.g. "raiffeisen" is a string that is blocked if it appears in the queried hostname). The blocklist can be found here
Queries: This consists of two numbers: The first is the raw number of DNS queries that the server has responded to since starting operation, and the second is the first number divided by the uptime (i.e. queries/second)
TCP/UDP: This is the number of queries received on the TCP protocol versus the UDP protocol. The sum should equal the number of queries. DNS typically uses the UDP protocol
Answer > 0: This consists of two numbers: the first is the number of queries we responded to with at least one record in the answer section, and the second is the first number divided by the uptime (i.e. queries/second). Note that the number of responses with an answer record is typically a fourth the size of the overall responses. This is normal. One reason for this disparity is that often both the IPv4 (A) and IPv6 (AAAA) records will be checked, but only one reply will have a record in the answer section . For example, browsing to "127.0.0.1.nip.io" generates two lookups, one with an answer (IPv4), and one without (IPv6). Another reason is that lookups follow a chain, e.g. looking up "127.0.0.1.nip.io" may generate up to four queries for A records ("1.nip.io", "0.1.nip.io", "0.0.1.nip.io" and "127.0.0.1.nip.io"), only the last of which returns a record in the answer section. Pro-tip: if you want to shave milliseconds off name resolution, use dashes not dots in your hostname (e.g. "10-9-9-30.nip.io" instead of "10.9.9.30.nip.io")
A: The number of responses which included an A (IPv4) record in the answer section since starting operation (e.g. "dig 127.0.0.1.nip.io")
AAAA: The number of responses which included an AAAA (IPv6) record in the answer section since starting operation (e.g. "dig --1.nip.io aaaa")
TXT Source: The number of responses which included a TXT record of the querier's IP address since starting operation (e.g. "dig @ns.nip.io ip.nip.io txt")
TXT Version: The number of responses which included a TXT record of the DNS's servers version since starting operation (e.g. "dig @ns-hetzner.sslip.io version.status.nip.io txt")
PTR IPv4/IPv6: This consists of two numbers; the first is the number of responses to IPv4 PTR queries (1.0.0.127.in-addr.arpa. → 127-0-0-1.sslip.io.), the second, IPv6 PTR queries
NS DNS-01: The number of responses which included a delegation of the NS (name server) to satisfy a certificate authority's DNS-01 challenge. This lookup is used for generating wildcard certificates from Let's Encrypt and other certificate authority. Technically this is not a "successful" query in that we don't return a record in the ANSWER section, but we do return an NS record in the AUTHORITY section. (e.g. "dig @ns-ovh.nip.io _acme-challenge.192.168.0.1.nip.io. soa")
Blocked: The number of responses which were blocked because we've received a takedown notice. A blocked response is an A or AAAA record to a website which notifies the user that the site they're trying to visit has been blocked because it's unsafe.

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 name servers. 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 name servers (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.

^{[fake news]} TLS certificates generated with nip.io/sslip.io and Let's Encrypt/ZeroSSL are valid, private, and secure, and can be issued via the HTTP-01 challenge for each individual hostname, contrary to what you might find on the Brave browser or Google search, which sometimes mistakenly regurgitate information from 2015 when, during a one-week period, sslip.io published the private key to its wildcard certificate (the certificate was quickly revoked). sslip.io no longer maintains a wildcard certificate, so any warnings about the security of the wildcard certificate are moot.