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
- 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
- remove the alert about not using the sslip.io nameservers as
general-purpose nameservers — I feel if they're looking at the page,
they already know enough not to use the nameservers as recursive
nameservers.
- deprecate ns-azure.
- extend the shutdown to 12/25 for ns-aws & ns-azure
- add a shoutout to Let's Encrypt
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.
- located in Warsaw, Poland
- IPv4: 51.75.53.19
- IPv6: 2001:41d0:602:2313::1
The crux of this is to take the load off ns-aws, which jumped from
$12.66 → $20.63 → $38.51 → $62.30 in the last four months due to
bandwidth charges exceeding 10 TB.
The real fix is to randomize the order in which the nameservers are
returned.
Previously the GCP NS was a k8s container, but now it's a standalone VM
(for, believe it or not, cost reasons: it was cheaper to assign a static
IP to a VM than to a load balancer).
The instructions now include the procedure to update the GCP VM.
Also, we double-checked that all servers had the same version number
twice, and now we only do it once. And we incorporate it with another
step, so there are two fewer steps to follow.
I don't need this k8s configuration for sslip.io (DNS, NTP) because I'm
no longer hosting on GKE now that it has an ephemeral IP instead of a
reserved IP because otherwise I'd have to pay $360 extra per year for a
premium-tier load balancer.
Fixes, `fly trigger-job ...`:
```
error: resource not found
```
Fixes, `kubectl logs ...`:
```
flag provided but not defined: -etcdHost
Usage of /usr/sbin/sslip.io-dns-server:
```
I'm disabling the key-value store because no one was using it.
There are other reasons, too:
- The removal of the `etcd` library dropped the executable size by over
half from 17MB to 7MB
- I didn't want users who've deployed it internally to be "surprised" by
unexpected key-value features
- Key-value-over-DNS has a seamy side to it: "data exfiltration". I know
there are legitimate uses for it, but I've come to believe that a
Key-value-over-HTTP solution is preferable because it's not only more
legitimate but also because it eliminates the DNS caching problem.
Note: the two biggest users are Cypriot IP addresses:
```
2 106.52.50.235 <- Tencent
1 223.71.46.114 <- China Mobile
157 31.153.14.207 <- Cypriot
110 62.228.164.123 <- Cypriot
4 73.189.219.4 <- My home IP
```
`
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.
We conform to the modern usage of "blacklist". In Google search,
"blacklist" appears 45 million times, "black list", 7 million.
Yes, I'm aware that we're using "block", not "black", for the variable
name, but keep in mind that we're using "block" as a drop-in replacement
for "black". And the newer "blocklist" has a puny 1 million appearances
to "blacklist"'s 45.
Previously I never checked if `net.ParseIP()` returned `nil` for an IPv4
address—I couldn't imagine my IPv4 regex was incomplete. I was wrong.
Moral of the story: always check for errors, always check for nil.
Oddly, I checked for IPv6 addresses—I guess I wasn't as confident about
the regex used.
Drive-bys:
- updated SOA with today's date
- updated dependencies `go get -u`
[fixes#15]
