We replace `ns-ovh-sg` with `ns-do-sg`; this is a purely financial
decision: `ns-ovh-sg` costs $60/month, $720/year.
`ns-do-sg` (Digital Ocean), is also a Singapore-based DNS server. It's a
basic-regular-2vcpu-4GiB RAM-80GB SSD-4TiB bandwidth for $24/month,
$288/year.
That's a yearly savings of $432.
I had originally overspec'ed the Singapore server because I suspected
that there was a ton of traffic in Asia; I was wrong. It's not even 20%
the traffic of Europe or North America. I am confident the Digital Ocean
server will be able to handle it.
I also reintroduce `ns-gce` as the second server in North America, backing
up `ns-hetzner`. My hope is that `ns-hetzner` carries most of the load,
and `ns-gce` carries the rest, but not so much as to trigger Google
Cloud Platform's (GCP's) expensive bandwidth billing.
| DNS server | Queries / second |
|:-----------|-----------------:|
| ns-hetzner | 10706.4 |
| ns-ovh | 10802.0 |
| ns-ovh-sg | 1677.7 |
I'm worried the traffic to my GCP server will cost me a hundred dollars
in bandwidth fees. It has a volume similar to my late AWS server which,
in its last month, racked up ~$130 in bandwidth fees!
I'm also trying to balance the servers more geographically: instead of
having two servers in the US and none in Asia, I'll have one server in
the US and one in Asia (Singapore).
The OVH server in Asia is expensive — $60/month instead of $20/month for
the OVH server in Warsaw. Also there's a monthly bandwidth cap in
Singapore in addition to the 300 Mbps cap.
I went with a dedicated server, similar to the one in Warsaw, but I took
the opportunity to upgrade it (same price):
- ns-ovh: KS-4: Intel Xeon-E3 1230 v6
- ns-ovh-sg: KS-5: Intel Xeon-E3 1270 v6
I'm hoping that by adding this server to Singapore, the traffic to the
ns-ovh, the Warsaw server, will lessen, and I won't get thos "Anti-DDoS
protection enabled for IP address 51.75.53.19" emails every few days.
Current Queries per second:
- 4,087 ns-gce
- 1,131 ns-hetzner
- 7,183 ns-ovh
When we promoted the Golang code to the root of the repo, we neglected
to update the paths in the documentation, helper scripts, and pipelines.
This commit addresses that oversight by updating the paths.
The original behavior was to return the deleted record, which
inadvertently prolonged the lifetime (in DNS cache) of the record which
was meant to expire as soon as possible.
- Removed the instructions to create a BOSH release. We are no longer
creating a BOSH release because we needed to colocate an etcd release
alongside the BOSH release, and we couldn't find an etcd BOSH release.
- Updated the instructions to run a quick test against the sslip.io DNS
server locally (sanity check) instead of deploying a VM with the BOSH
release & testing against that.
- Updated the instructions for updating ns-azure's DNS server. ns-azure
is no longer a BOSH-deployed VM.
Now we check first to see if etcd is running before diving in & testing
against it.
fixes:
```
Unexpected error:
<*fmt.wrapError | 0xc0003bc8e0>: {
msg: "couldn't GET \"my-key\": context deadline exceeded",
err: <context.deadlineExceededError>{},
}
```
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.
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.
[fixes#11]
- Returns version information for DNS server
- Contains 3 strings:
- Semantic version, e.g. "2.2.1"
- Date of compilation
- Latest git hash
Note: the BOSH Release will have a different compilation date &
different git hash than the released executables; the semantic version
will be the same.
I needed a way of determining the version that a server was running. I
orginally considered a command-line argument, but then I thought, "Why
not create a DNS record for it? That way I can query running servers
without needing to ssh onto the machine."
The TXT record consists of three distinct strings: version, compile
date, and git hash.
```bash
dig txt version.sslip.io +short
"2.2.1"
"2021/10/03-15:08:54+0100"
"6a928eb"
```
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.
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)
```
