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]
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.
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
