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

TXT Records, Take Two

🐞 TXT Records: only ONE string per record

Previously we were returning one TXT record with multiple strings for sslip.io. That did not work for ProtonMail's domain verification.

It seems a convention that each TXT record has one string. google.com, for example, has a separate TXT record for each string.

It turns out I had misunderstood the StackExchange thread.

fixes (from ProtonMail domain verification):

Verification did not succeed, please try again in an hour.

TXT Records

This release has custom TXT records for the sslip.io domain. The motivating factor was to re-enable ProtonMail email service for sslip.io, which requires specific TXT records.

Fixed IPv4 & IPv6 resolution bugs

• 🐞 fix IPv6 resolution (double dashes were matched too short) :

2601-41d0-2-e01e--56dB-3598.sSLIP.io. → 2601:41d0:2:e01e::56db      (wrong)
                                      → 2601:41d0:2:e01e::56db:3598 (right)

• 🐞 fix IPv4 resolution (no longer mixes dashes and dots while parsing):

minio-01.192-168-1-100.sslip.io → 1.192.168.1   (wrong)
                                → 192.168.1.100 (right)

Thanks @pandaxin!

Restore the https://sslip.io Website

We broke our website; we forgot to add A records for it. This release has the A records.

fixes:

curl: (6) Could not resolve host: sslip.io

Bugfix: compilation

Fixes:

+ go build -o /var/vcap/packages/sslip.io-dns-server/bin/sslip.io-dns-server
main.go:7:2: package xip/xip is not in GOROOT (/var/vcap/data/packages/golang-1-linux/da1e0a99a1246edab92d9ffd0c4a2e7c3d5df83a/src/xip/xip)