If there are no custom records, then return the querier's IP address.
This is so that I can use it instead of Google'ing "what is my IP
address" or `curl ident.me` or `curl -s httpbin.org/ip` or `curl
checkip.amazonaws.com`.
`dig @ns-aws.nono.io txt . +short`
Inspired by Google's `dig txt o-o.myaddr.l.google.com @8.8.8.8 +short`
Dockerfile:
- We use `CMD` instead of `ENTRYPOINT` because it's marginally easier
to debug.
- We include 64-bit ARM, but not 32-bit
- We had to re-order the steps so that `apk add bind-tools` came
before copying the binary; that fixed a bug where the
`sslip.io-dns-server` wasn't on the ARM container filesystem (but it
was on the amd64 filesystem 🤔)
Binaries
- We now build arm64 (GOARCH) versions of FreeBSD, Linux, and macOS
(GOOS), but not Windows. It apparently doesn't have arm64 support yet.
- Use HTTP-01 challenge for run-of-the-mill certificates
- White label domains can acquire their own wildcard certificates
- VMware employees have access to *.sslip.io wildcard
- Use DNS-01 challenge for *.w-x-y-z.sslip.io wildcards
- when DNS gets a permission error, it helpfully suggests using `sudo`
- when DNS can't bind to `INADDR_ANY`, it's probably because it's Fedora
running `systemd.resolved` on port 53 of 127.0.0.53, so we try to bind
to each address individually.
- we don't implement similar checks for the HTTP server:
- if it's a permission problem, the DNS server has already warned the
user.
- if it's a binding problem, the user is probably running an HTTP
server bound to `INADDR_ANY`, so we might as well exit.
- we ported this code from main `sslip.io` DNS server.
The `wildcard-dns-http-server` didn't clearly differentiate the DNS
subsystem log messages from the HTTP subsystem log messages. We now
prepend "DNS:" and "HTTP:" depending the source of the message.
This fixes an error when procuring Let's Encrypt certs using HTTP-01
challenge--my server didn't recognize, when queried with `SsLiP.iO`,
that it's the same as `sslip.io`, and so it doesn'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
```
The bulk of this commit is to address 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.
This commit bloats `main.go`, which I have mixed feelings about because
it's untested.
The purpose of this commit is to enable Let's Encrypt DNS-01 challenges
for wildcard certificates.
To accomplish that, we'd like to delegate queries for ALL types (e.g.
NS, SOA, A, AAAA) to the IP address of that server. For example, any
query for `_acme-challenge.52-0-56-137.sslip.io` would be delegated to
the DNS server `52-0-56-137.sslip.io` (whose IP address 52.0.56.137
would be supplied as well).
Thanks @NormanR !
On a personal note, I feel the code is getting bloated again. Also, I'm
inconsistent with my parameters: `NSResponse()`, for example, has
arguments which it mutates (`response`), and which are returned
(`logMessage`). This offends my esthetics.
[#6]
When querying for NS (name server) records, the responses include an
"Additionals" section which lists the IP addresses of the name server.
This is a courtesy & an optimization: by sending the IP address, we
avoid the client sending a second query for the IP address of the
nameserver.
With this change, the following command...
```
dig @ns-aws.nono.io sslip.io ns
```
...will yield these additional records:
```diff
+;; ADDITIONAL SECTION:
+ns-aws.nono.io. 604800 IN A 52.0.56.137
+ns-azure.nono.io. 604800 IN A 52.187.42.158
+ns-gce.nono.io. 604800 IN A 104.155.144.4
```
Our CI is failing, and it appears that the `Eventually` pointer is moved
ahead by one of the tests, skipping over the line that another test is
waiting for.
To fix, rather than relying on a pointer, we compare the entire contents
of the DNS server's stderr output. We also remove the `$` anchor from
the regex which was causing it to fail.
fixes <https://ci.nono.io/teams/main/pipelines/sslip.io/jobs/unit/builds/149>:
```
Got stuck at:
2021/01/19 15:34:28 127.0.0.1.60973 TypeNS example.com. ? ns-aws.nono.io., ns-azure.nono.io., ns-gce.nono.io.
2021/01/19 15:34:28 127.0.0.1.46683 TypeMX sslip.io. ? 10 mail.protonmail.ch., 20 mailsec.protonmail.ch.
Waiting for:
TypeNS example.com. \? ns-aws.nono.io., ns-azure.nono.io., ns-gce.nono.io.\n$
```
When I ran the following code, I would get at least one of the above
messages when run on the Linux CI container:
```bash
for i in $(seq 1 32); do
dig @localhost asdf +short &
done
```
The error hasn't recurred after this change, in spite of running the
above code a dozen times.
The behavior of `dig` version **9.11.25-RedHat-9.11.25-2.fc32** differs
from macOS's `dig` version **9.10.6**. In other words, this test passes
on my mac but not until now on (Linux-based) CI.
I also took the opportunity to refactor our `dig` arguments to conform with
the suggested usage:
> Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
fixes <https://ci.nono.io/teams/main/pipelines/sslip.io/jobs/unit/builds/145>:
```
Expected
<int>: 9
to match exit code:
<int>: 0
```
Note that for the `any` test I had to append an additional `+notcp`
argument to avoid an attempted TCP connection. I suspect a bug in `dig`:
```
dig any sslip.io @localhost
;; Connection to 127.0.0.1#53(127.0.0.1) for sslip.io failed: connection refused.
```
- it appears that Let's Encrypt requires setting at least two TXT
records; before I only allowed one to be set; now you can set as many as
you want.
- our records had a TTL of 0 seconds; I bumped it to 60: long enough to
get a cert, short enough to refesh for a second attempt if the first one
failed.
Previously we weren't returning a response when `acme.sh` updated our
TXT record, but the acme-dns endpoint specifies a
[response](https://github.com/joohoi/acme-dns#response), and acme.sh
expects [a
response](b7a3fe05a4/dnsapi/dns_acmedns.sh (L38)).
fixes:
```
[Mon Jan 18 19:09:26 UTC 2021] invalid response of acme-dns
[Mon Jan 18 19:09:26 UTC 2021] Error add txt for domain:_acme-challenge.34-83-219-164.sslip.io
```
We had moved the DNS server to a sub-directory to make room for a
sibling application, a small DNS server + small HTTP server.
fixes:
```
cannot find package "main.go" in any of:
/usr/local/Cellar/go/1.15.6/libexec/src/main.go (from $GOROOT)
/Users/cunnie/go/src/main.go (from $GOPATH)
```
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.
Created much-needed integration-level tests. The existing unit tests
were difficult to set up, were too constricting when refactoring, and
were less meaningful than the integration tests.
Hygiene:
- Eliminated the `ErrNotFound` error; it was hack: it was a substitute
for returning an empty set, which I wasn't handling correctly. Now, when
a record isn't found (usually because it's not a customized domain), it
returns an empty set, not an error.
- Used the `dnsmessage` capitalization convention where applicable, e.g.
`SOAResource()` not `SOAResource()`
- Replaced painful low-level copying with the `dnsmessage`'s utility
functions, `NewName()` and `MustNewName()`
This change triggered a huge rewrite, for we had hard-coded the
**authoritative** flag. The newer code is more flexible, and lays the
groundwork for future changes such as including IP addresses in the
**Additionals** section.
