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”
+ 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”
@@ -158,7 +160,7 @@ src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js">
ns-ovh.sslip.io. |
51.75.53.19
- 2001:41d0:602:2313::1 |
+ 2001:41d0:602:2313::1
Poland |
@@ -168,10 +170,11 @@ src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js">
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:
+
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/3.2.4/sslip.io-dns-server-linux-amd64 -o dns-server
@@ -181,34 +184,37 @@ 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".
+ 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".
-
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
+
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.
+ 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/.
+
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.
+ "*.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:
+ 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"
@@ -221,8 +227,8 @@ dig @ns.sslip.io txt ip.sslip.io +short -6 # forces IPv6 lookup; sample reply "2
+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-azure.sslip.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.
+
ns-azure.sslip.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
sslip.io software by querying the TXT record of
version.status.sslip.io:
@@ -254,8 +262,9 @@ dig @ns-gce.nono.io version.status.sslip.io txt +short
"8f7f2df"
The first number, ("2.6.1"), 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.
+ 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.sslip.io
@@ -282,54 +291,55 @@ dig @ns-azure.sslip.io metrics.status.sslip.io txt +short
The first value ("2023-10-04 07:37:50-07") is the date the blocklist was last downloaded. The following two
numbers are the number of string matches that are blocked (e.g. "raiffeisen" is a string that is blocked if
it appears in the queried hostname) and the number of CIDR matches that are blocked (e.g. "43.134.66.67/24"
- is blocked). The blocklist can be found here
+ is blocked). 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)
+ 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
+ the number of queries. DNS typically uses the UDP protocol
Answered Queries
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 answered queries is typically a third or fourth the size of the overall queries. 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.sslip.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.sslip.io" may generate up to four queries for A records ("1.sslip.io",
- "0.1.sslip.io", "0.0.1.sslip.io" and "127.0.0.1.sslip.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.sslip.io" instead of "10.9.9.30.sslip.io")
+ in the answer section, and the second is the first number divided by the uptime (i.e. queries/second). Note
+ that the number of answered queries is typically a third or fourth the size of the overall queries. 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.sslip.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.sslip.io" may generate up to four queries for A records ("1.sslip.io",
+ "0.1.sslip.io", "0.0.1.sslip.io" and "127.0.0.1.sslip.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.sslip.io" instead of "10.9.9.30.sslip.io")
A
The number of responses which included an A (IPv4) record since starting operation (e.g. "dig
- 127.0.0.1.sslip.io")
+ 127.0.0.1.sslip.io")
AAAA
The number of responses which included an AAAA (IPv6) record since starting operation (e.g. "dig
- --1.sslip.io aaaa")
+ --1.sslip.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.sslip.io ip.sslip.io txt")
+ (e.g. "dig @ns.sslip.io ip.sslip.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-azure.sslip.io version.status.sslip.io txt")
+ (e.g. "dig @ns-azure.sslip.io version.status.sslip.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
+ (
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-gce.sslip.io
- _acme-challenge.192.168.0.1.sslip.io. soa")
+ 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-gce.sslip.io
+ _acme-challenge.192.168.0.1.sslip.io. soa")
-
xip.io: the inspiration for sslip.io. Sadly, this appears to be no longer
maintained after Sam Stephenson left
- Basecamp.
+ Basecamp.
-
nip.io: similar to xip.io, but the PowerDNS backend is written in elegant Python
@@ -342,20 +352,21 @@ dig @ns-azure.sslip.io metrics.status.sslip.io txt +short
[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]
+ 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:
+ 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.
+ 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.