nip.io has the complete set of NS records that sslip.io has. Previously
all the nameservers had only sslip.io records, e.g. ns-ovh.sslip.io.
With this commit, we now duplicate the nameservers, so now there's an
ns-ovh.nip.io as well. This also includes the "wildcard" record,
ns.sslip.io.
This unlocks the ability to use the shorter "nip.io" domain for certain
lookups, e.g. "dig txt @ns.nip.io ip.nip.io", whereas previously I'd
have to do "dig txt @ns.sslip.io ..."
- Proton insists on have a TXT record before adding that domain, and we
comply with "protonmail-verification=19b0837cc4d9daa1f49980071da231b00e90b313"
- We add A & AAAA records for nip.io, identical to sslip.io's.
- We add convenience records for ns1.nip.io and ns2.nip.io to eliminate
the dreaded automated message "dig: couldn't get address for
'ns1.nip.io': not found"
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
We don't need a custom `listLocalIPCIDRs()`; Golang now has a builtin:
`net.InterfaceAddrs()`. [0]
This is one of those wonderful commits that removes more lines than it
adds.
[0] https://pkg.go.dev/net#InterfaceAddrs
When I had introduced ns-hetzner, I forgot to update the records for
ns.sslip.io, which continued to point to the old, deprecated ns-azure.
This commit updates the ns.sslip.io records.
The nameserver on Azure is probably my least-favorite: much slower, much
higher latency. Even though it would've made more geographic sense to
dismantle my GCP nameserver in favor of the Hetzner, I'm using this
opportunity to get rid of the Azure.
And, of course, introduce the Hetzner nameserver with its 20TB of
bandwidth allowance, which I've come to need.
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.
- 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.
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
