2.2.3

Add NS servers in sslip.io domain

We currently use three nameservers in the nono.io domain, but that's confusing--why not have the nameservers in the sslip.io domain?

This commit starts the ball rolling to convert to the sslip.io. We'll have a brief period where we have both nono.io and sslip.io nameservers.

At which point we'll add the sslip.io nameservers to our registrar, Namecheap.com.

Once they've been added to our registrar, we'll wait a day or two to propagate, and then we'll delete references to the nono.io nameservers.

2.2.2

ip.sslip.io TXT returns origin IP

Our documentation was wrong; our homepage said to get the origin IP address by querying the TXT record of the root, i.e. dig @ns-aws.nono.io txt . +short; however, our code worked differently: it returned the origin IP when the .ip TLD was queried.

The new behavior is that it returns the origin IP when ip.sslip.io. is queried, and the documentation now reflects that behavior.

Also, that behavior is marked "experimental" to give us leeway to change.

2.2.1

TXT record for version.sslip.io returns version information

dig txt version.sslip.io returns version information of the sslip.io DNS server. This can be helpful when troubleshooting.

The TXT record consists of three distinct strings: version, compile date, and git hash.

dig @ns-aws.nono.io txt version.sslip.io +short
  "2.2.1"
  "2021/10/06-05:17:18-0700"
  "7bef649"

The three servers should always have the same semantic version (e.g. "2.2.1"), but their compile date & git hash may differ for technical reasons.

Full Changelog: 2.2.0...2.2.1

2.2.0

• ns-aws.nono.io now has an IPv6 address, 2600:1f18:aaf:6900::a
• You can use sslip.io's DNS servers (ns-aws.nono.io, ns-azure.nono.io, ns-gce.nono.io) to determine your public IP address by querying the TXT record of the root domain. If you're curious about your public IPv6 address, use the DNS server ns-aws.nono.io, for it has both IPv4 and IPv6 addresses:

dig @ns-aws.nono.io txt . +short    # sample reply "2607:fb90:464:ae1e:ed60:29c:884c:4b52"

🐞 Case-insensitive custom records

Binding to port 53: better messaging

This release addresses problems under Linux:

• The user needs to be root to bind to port 53 (or have the CAP_NET_BIND_SERVICE capability), so if we have a permissions-problem, we say, "try sudo".

• If we can't bind to INADDR_ANY, and we probably can't because "systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53" on port 53, which prevents us from binding, we fallback to attempting to bind to every available address individually.

🐞 Ignore case when comparing customized records

This fixes an error when procuring Let's Encrypt certs using HTTP-01 challenge—the server didn't recognize, when queried with SsLiP.iO, that it's the same as sslip.io, and so it didn't reply with the correct A/AAAA records.

fixes:

sudo /usr/local/bin/certbot renew
  No valid IP addresses found for sslip.io

log messages from /var/vcap/sys/log/sslip.io-dns-server/sslip.io-dns-server.stderr.log:

2021/01/30 21:45:49 3.122.55.230.22713 TypeA SsliP.IO. ? nil, SOA SsliP.IO. briancunnie.gmail.com. 2021011400 900 900 1800 300
2021/01/30 21:45:49 54.187.227.254.16621 TypeAAAA SslIP.io. ? nil, SOA SslIP.io. briancunnie.gmail.com. 2021011400 900 900 1800 300

🐞 Case-insensitive `_acme-challenge.` matching

Our DNS-01 challenges were failing because we weren't prepared for mixed-case queries. Now we properly recognize them.

Below are snippets from our log files, where we can see the queries' random casing (e.g. _ACMe-cHalLeNGE.34-83-219-164.sSlip.Io.). Henceforth we will ignore casing when detecting DNS-01 challenges.

2021/01/20 20:15:40 3.123.253.205.45368 TypeTXT _ACMe-cHalLeNGE.34-83-219-164.sSlip.Io. ? nil, SOA _ACMe-cHalLeNGE.34-83-219-164.sSlip.Io. briancunnie.gmail.com. 2021011400 900 900 1800 300

2021/01/20 20:15:40 18.219.85.19.35164 TypeTXT _acMe-chaLlENGe.34-83-219-164.ssliP.Io. ? nil, SOA _acMe-chaLlENGe.34-83-219-164.ssliP.Io. briancunnie.gmail.com. 2021011400 900 900 1800 300

2021/01/20 20:15:40 66.133.109.36.11107 TypeTXT _aCme-chaLleNGe.34-83-219-164.sSLip.Io. ? nil, SOA _aCme-chaLleNGe.34-83-219-164.sSLip.Io. briancunnie.gmail.com. 2021011400 900 900 1800 300

🐞 delegate _all_ "_acme-challenge." records

We now delegate all types of records (e.g. SOA A, AAAA, MX, PTR) for queries of domains prefixed with "_acme-challenge." to the hostname with the "_acme-challenge." portion stripped. Previously we limited our delegation of "_acme-challenge." records to TXT & NS records.

For example, when queried for the MX record of _acme-challenge.52-0-56-137.sslip.io, we would send a reply that would delegate to the DNS server 52-0-56-137.sslip.io (whose IP address 52.0.56.137 would be supplied as well). In other words, we'd disable the authoritative flag, send an empty Answers section, an Authoritative section consisting of one record, 52-0-56-137.sslip.io, and an Additionals section consisting of the IP address 52.0.56.137.

We also rigorously disable the authoritative flag. Previously we played fast-and-loose with the authoritative flag.

Additional Notes

For every nameserver listed in either the Answers or Authorities section, we now include their respective IP addresses in the Additionals section.

We fixed a bug where ID would get corrupted. dig for example, would sometimes emit the warning, ";; Warning: ID mismatch: expected ID x, got y".

🐞 "_acme-challenge" subdomains have special NS records

This is a bug fix to the previous release, which didn't delegate the subdomains properly.

Technical details:

When querying for a record with _acme-challenge. and an embedded IP address, we mistakenly responded with an answer with the authoritative flag set and the SOA record in the Authorities section. But that was wrong: we should NOT have set the authoritative flag, and we should have included the NS record, not the SOA record, in the Authorities section.

Additional Notes

Although it may seem incongruous to bump a major version for a bug fix, in this case it's appropriate, for it reflects a major re-write of the code (which had become too rigid to accommodate our requirements). We've also included a fairly rigorous set of integration tests, and deprectated some of the baroque and overly-complex unit tests.

"_acme-challenge" subdomains have special NS records

_acme-challenge. in query triggers special NS record

Prior behavior was that the same trinity of NS records was returned for every NS query:

• ns-aws.nono.io.
• ns-azure.nono.io.
• ns-gce.nono.io.

This commit introduces a change in that behavior: IF the NS query includes the string _acme-challenge. AND the query has an embedded IP address THEN the NS record returned is the query with the _acme-challenge. stripped.

For example:

dig +short ns _acme-challenge.104.155.144.4.sslip.io

Would return:

104.155.144.4.sslip.io.

This is an attempt to enable DNS-01 challenge for wildcard certs from Let's Encrypt or other CAs (Certificate Authorities).

Note that the embedded IP address would need to be routable (NOT 10.x 172.16-31.x, or 192.168.x).

Note that you would also need to run a DNS server such as acme-dns at that address.

Thanks @normanr !

CNAME Records

This release includes customized CNAME records for DKIM signing for the sslip.io domain.

The code now allows returning multiple A and AAAA records.