Default PTR record domain has changed from "sslip.io" to "nip.io".
For example, `dig -x 127.0.0.1 @ns.nip.io` previously returned
`127-0-0-1.sslip.io.`, now returns `127-0-0-1.nip.io.`
Previously, the PTR domain was hard-coded to `sslip.io.`, but this
commit introduces two changes:
- the default PTR domain is now `nip.io.`. Hey, it's shorter.
- the PTR domain can now be set with the `-ptr-domain` flag, e.g. `go
run main.go -ptr-domain=xip.example.com` and then querying `dig -x
169.254.169.254` would return `169-254-169-254.xip.example.com.`
Notes:
- Our new flag, `-ptr-domain`, follows the kebab-case convention of
Golang flags, but this is inconsistent with our previous camelCase
convention, e.g. `-blocklistURL`. We didn't know any better, and it's
too late to change existing flags.
- removed two comment-out `panic()` whose purpose has long since been
forgotten
- I don't feel bad about changing the default behavior because hardly
anyone uses PTR lookups. Out of 12,773,617,290 queries, only 1564 were
PTR records (0.000012%)!
- In that vein, I acknowledge that this is a feature that no one's
clamoring for, no one will use, but it's important to me for reasons
that I don't fully understand.
I want to promote nip.io to the same status as sslip.io, same features,
same special TXT records.
This will allow me to write automated health checks for both nip.io and
sslip.io instead of only sslip.io
Side note: I prefer the shorter "nip.io". I went with "sslip.io" when
Sam Stephenson suggested it even though I thought that "tlsip.io" would
be more apropos (TLS had long since replaced SSL), and within a month
the domain name didn't make sense because Comodo had revoked our
certificate.
- ip.nip.io returns the IP address TXT record
- version.status.nip.io returns the version information in a TXT record
- metrics.status.nip.io returns the metrics information in a TXT record
The Sender Policy Framework (SPF) TXT records remain different for both
domains.
sslip.io Public Suffix List (PSL) TXT remains & was not implemented for
nip.io. The PSL has denied our PR to add sslip.io to the list. That TXT
record will be removed in a future commit.
I backfilled unit tests for {version,metrics].status.{nip,sslip}.io.
Drive-by: A `for` loop was rewritten as a `copy()` at the behest of the
linter.
e.g. `00000000000000000000000000000001.nip.io` → ::1
This is to bring parity with IPv4's hexadecimal notation, though IPv6's
hexadecimal notation is so clunky that I doubt it'll ever be used.
- The hexadecimal-notated IPv6 must be exactly 32 hexadecimal
characters, no separators.
- Any hexadecimal notation _must_ be bookended by dots or by the
beginning or end of the string
(www.0000000000000000000000000000001.sslip.io or
00000000000000000000000000000001.sslip.io). No dashes.
- If a normal IP notation and a hex notation are in the same hostname,
then the normal IP notation takes precedence. This preserves existing
behavior for sslip.io users, e.g.
(00000000000000000000000000000001.2600--.nip.io resolves to 2600::,
not ::1)
e.g. `7f000001.sslip.io` → 127.0.0.1
This came about as a result of the nip.io migration to sslip.io servers:
nip.io supported hexadecimal notation; sslip.io didn't. Several nip.io
users were blindsided by the feature's lack, and raised an issue.
- The hexadecimal-notated IPv4 must be exactly 8 hexadecimal characters,
no separators.
- Any hexadecimal notation _must_ be bookended by dots or by the
beginning or end of the string (www.0a09091e.sslip.io or
0a09091e.sslip.io). No dashes.
- If a normal IP notation and a hex notation are in the same hostname,
then the normal IP notation takes precedence. This preserves existing
behavior for sslip.io users, e.g. (0a09091e.127-0-0-1.sslip.io
resolves to 127.0.0.1, not 10.9.9.30)
[#92]
rand.Seed() has been deprecated since Golang 1.20, and is now a no-op:
Deprecated: As of Go 1.20 there is no reason to call Seed with a random
value. Programs that call Seed with a known value to get a specific
sequence of results should use New(NewSource(seed)) to obtain a local
random generator.
As of Go 1.24 Seed is a no-op.
And the reason I used it — to reproduce failures if necessary — has
never been necessary.
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.
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
