- 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
When using dig to determine the metrics of my servers, e.g. "dig txt
metrics.status.sslip.io @ns-ovh.sslip.io +short", one record looks
particularly heinous:
```
"Answer \226\137\165 1: 67974722 (651.9/s)"
```
It's supposed to look like this:
```
"Answer ≥ 1: 67974722 (651.9/s)"
```
`dig` doesn't handle Unicode well. So I'm replacing "Answer ≥ 1" with
"Answer > 0". No Unicode.
It was a worthy effort, but ultimately failed.
I've always been uncomfortable with the metric "Answered Queries" — it
implies that we don't answer all the queries. But we do answer all the
queries!
What the metric meant is "the number of DNS responses that we send that
have one or more records in the ANSWER section".
The new metric is "Answer ≥ 1". Not great, but better than before.
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.
Rather than bloating the code with yet another flag, one that only I
would use, and in only one specific case (ns-aws.sslip.io), it would be
better to simply take ns-aws.sslip.io out of the NS list.
I'm being gouged by bandwidth costs by AWS. Last month's bill was $148,
and all but $9 was about bandwidth.
My bandwidth has been inexplicably climbing since February:
Billing
Month Total GB % increase
2024/2 37.119
2024/3 52.953 42.66%
2024/4 58.745 10.94%
2024/5 69.307 17.98%
2024/6 173.371 150.15%
2024/7 334.064 92.69%
2024/8 539.343 61.45%
2024/9 568.745 5.45%
2024/10 1365.305 140.06%
The new flag will allow me to throttle the AWS bandwidth to ~287 queries
/ second, which, according to my calculations, will max out the free
100 GB bandwidth without dipping into the for-pay bandwidth.
We want to place sslip.io on the Public Suffix List so we don't need to
pester Let's Encrypt for rate limit increases.
According to https://publicsuffix.org/submit/:
> owners of privately-registered domains who themselves issue subdomains
to mutually-untrusting parties may wish to be added to the PRIVATE
section of the list.
References:
- https://publicsuffix.org/
- https://github.com/publicsuffix/list/pull/2206
[Fixes#57]
Previously when the NS records were returned, ns-aws was always returned
first. Coincidentally, 64% of the queries were directed to ns-aws. And
once I exceeded AWS's 10 TB bandwidth limit, AWS began gouging me for
bandwidth charges, and $12.66/month rapidly climbed to $62.30
I'm hoping that by randomly rotating the order of nameservers, the
traffic will balance across the nameservers.
Current snapshot (already ns-ovh is helping):
ns-aws.sslip.io
"Queries: 237744377 (1800.6/s)"
"Answered Queries: 63040894 (477.5/s)"
ns-azure.sslip.io
"Queries: 42610823 (323.4/s)"
"Answered Queries: 14660603 (111.3/s)"
ns-gce.sslip.io
"Queries: 59734371 (454.1/s)"
"Answered Queries: 17636444 (134.1/s)"
ns-ovh.sslip.io
"Queries: 135897332 (1034.4/s)"
"Answered Queries: 36010164 (274.1/s)"
Meant for obtaining wildcard certs from Let's Encrypt using the DNS-01
challenge.
- introduce a variant of `blocklist.txt` to be used for testing
(`blocklist-test.txt`) because the blocklist has grown so large it
clutters the test output
- more rigorous about lowercasing hostnames when matching against
customized records. This needs to be extendend when we parse _any_
arguments
TODOs:
- remove the wildcard DNS servers
- update instructions
- That's where the code is expected to be
- The only reason the code was buried two directories down was because
it was originally a BOSH release
- There hasn't been a BOSH release in over two years; last one was Feb
26, 2022
- Other than a slight adjustment to the relative location of
`blocklist.txt` file in the integration tests, there were no other
changes
