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
- ns-aws & ns-azure have been replaced by ns-hetzner & ns-ovh
- ns-azure has been completely destroyed (`terraform apply -destroy`);
the elastic IP has been released, so there's no hope of bringing it
back.
- ns-aws has been renamed to "blocked.sslip.io". It no longer answers
DNS queries, but lives on as the website we point "blocked" queries to
that warns about phishing.
- Some of the Markdown files' changes were mere reformatting changes
The torrent of traffic I'm receiving has caused my AWS bill to spike
from $9 to $148, all of the increase due to bandwidth charges.
I'm still maintaining ns-aws; the VM still continue to run, and continue
to serve web traffic, and maintain its hostname and IP addresses;
however, it will no longer be in the list of NS records for sslip.io.
There are much less expensive hosting providers. OVH is my current
favorite.
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.
**This process still does not work**. We need to fix our sslip.io DNS
server code. That being said, once our DNS server code is fixed, this
process _should_ work.
As much as we'd have liked to use `joohoi/acme-dns`, it didn't work with
our setup, possibly due to our DNS server code brokenness, mentioned
above. At any rate, we have our own `acme-dns` replacement, which we
intend to use going forward.
This small DNS server only returns one type of record, a TXT record,
meant to be a token assigned by a certificate authority (e.g. Let's
Encrypt) to verify domain ownership.
The TXT record will be updateable by an API endpoint on the webserver
(same executable as the DNS server), but I haven't yet written that
portion.
Drive-by: in our _other_ (main) sslip.io DNS server, I changed `break` →
`continue` in the main loop. Had we gotten a malformed UDP packet, we
would have exited, but now we continue to the next packet. Exiting is
not that big a deal—`monit` would have restarted the server—but moving
on to the next packet is a more robust approach.
[#6]
Warning: these instructions do not work & are incomplete.
I had high hopes for [acme-dns](https://github.com/joohoi/acme-dns), but
it seems much too baroque for my purposes—authentication, subdomains,
CNAMEs. It seems quite clever for a use case that is much more
complicated than mine.
I've resolved to write an _acme-dns_-compatible HTTP server & DNS server
to meet my much simpler needs.
