compumike (u/compumike)

compumike commented on Stop using low DNS TTLs blog.apnic.net/2019/11/12... · Posted by u/swills

compumike · 12 days ago

The big thing that articles like this miss completely is that we are no longer in the brief HTTP/1.0 era (1996) where every request is a new TCP connection (and therefore possibly a new DNS query).

In the HTTP/1.1 (1997) or HTTP/2 era, the TCP connection is made once and then stays open (Connection: Keep-Alive) for multiple requests. This greatly reduces the number of DNS lookups per HTTP request.

If the web server is configured for a sufficiently long Keep-Alive idle period, then this period is far more relevant than a short DNS TTL.

If the server dies or disconnects in the middle of a Keep-Alive, the client/browser will open a new connection, and at this point, a short DNS TTL can make sense.

(I have not investigated how this works with QUIC HTTP/3 over UDP: how often does the client/browser do a DNS lookup? But my suspicion is that it also does a DNS query only on the initial connection and then sends UDP packets to the same resolved IP address for the life of that connection, and so it behaves exactly like the TCP Keep-Alive case.)

compumike commented on US electricity demand surged in 2025 – solar handled 61% of it electrek.co/2026/01/16/us... · Posted by u/doener

microtonal · a month ago

I am not sure where you live, but I cannot remember the last time our power went out (Western Europe).

I have gas-cooked since I was a kid (living in an area with a lot of natural gas, so houses were connected to gas since the 50ies), but induction is so much nicer that I'm happy to not be able to cook during a once in a ~10-20 year outage. Also a lot safer (it still happens quite frequently that a house blows up because of a gas leak, just this week there was a huge explosion in Utrecht what was presumably a gas leak).

Of course, the equation may change for countries with less stable power.

compumike · a month ago

It's very local here. I'm in the suburbs of Philadelphia, in one of the highest income counties in the state, two blocks from a major hospital, one block from a suburban downtown. Despite that, I've experienced one or two 4-6 hour long power outages per year the past few years. (Mostly correlated with weather.) One outage in June 2025 was 50 hours long!

Many larger homes in this area have whole-house generators (powered by utility natural gas) with automatic transfer switches. During the 50-hour outage, we "abandoned ship" and stayed with someone who also had an outage, but had a whole-house generator.

Other areas just 5-10 miles away are like what you describe: maybe one outage in the past 10 years.

compumike commented on 6-Day and IP Address Certificates Are Generally Available letsencrypt.org/2026/01/1... · Posted by u/jaas

qwertox · a month ago

I have now implemented a 2 week renewal interval to test the change to the 45 days, and now they come with a 6-day certificate?

This is no criticism, I like what they do, but how am I supposed to do renewals? If something goes wrong, like the pipeline triggering certbot goes wrong, I won't have time to fix this. So I'd be at a two day renewal with a 4 day "debugging" window.

I'm certain there are some who need this, but it's not me. Also the rationale is a bit odd:

> IP address certificates must be short-lived certificates, a decision we made because IP addresses are more transient than domain names, so validating more frequently is important.

Are IP addresses more transient than a domain within a 45 day window? The static IPs you get when you rent a vps, they're not transient.

compumike · a month ago

> If something goes wrong, like the pipeline triggering certbot goes wrong, I won't have time to fix this. So I'd be at a two day renewal with a 4 day "debugging" window.

I think a pattern like that is reasonable for a 6-day cert:

- renew every 2 days, and have a "4 day debugging window" - renew every 1 day, and have a "5 day debugging window"

Monitoring options: https://letsencrypt.org/docs/monitoring-options/

This makes me wonder if the scripts I published at https://heyoncall.com/blog/barebone-scripts-to-check-ssl-cer... should have the expiry thresholds defined in units of hours, instead of integer days?

compumike commented on The Dangers of SSL Certificates surfingcomplexity.blog/20... · Posted by u/azhenley

dextercd · 2 months ago

You need external monitoring of certificate validity. Your ACME client might not be sending failure notifications properly (like happened to Bazel here). The client could also think everything is OK because it acquired a new cert, meanwhile the certificate isn't installed properly (e.g., not reloading a service so it keeps using the old cert).

I have a simple Python script that runs every day and checks the certificates of multiple sites.

One time this script signaled that a cert was close to expiring even though I saw a newer cert in my browser. It turned out that I had accidentally launched another reverse proxy instance which was stuck on the old cert. Requests were randomly passed to either instance. The script helped me correct this mistake before it caused issues.

compumike · 2 months ago

100%, I've run into this too. I wrote some minimal scripts in Bash, Python, Ruby, Node.js (JavaScript), Go, and Powershell to send a request and alert if the expiration is less than 14 days from now: https://heyoncall.com/blog/barebone-scripts-to-check-ssl-cer... because anyone who's operating a TLS-secured website (which is... basically anyone with a website) should have at least that level of automated sanity check. We're talking about ~10 lines of Python!

compumike commented on A Government Shutdown and a 1913 Data Assumption Caused an Outage in 2025 heyoncall.com/blog/total-... · Posted by u/compumike

compumike · 2 months ago

Thought you might find this story interesting, concerning the Total Real Returns website which originally launched on HN a while ago. https://news.ycombinator.com/item?id=32081943

This is probably the same kind of "one new row per month" assumption that many data pipelines with any sort of primary date/time column make!

compumike commented on PS5 now costs less than 64GB of DDR5 memory. RAM jumps to $600 due to shortage tomshardware.com/pc-compo... · Posted by u/speckx

compumike · 3 months ago

Lots of people are speculating that the price spike is AI related. But it might be more mundane:

I'd bet that a good chunk of the apparently sudden demand spike could be last month's Microsoft Windows 10 end-of-support finally happening, pushing companies and individuals to replace many years worth of older laptops and desktops all at once.

compumike commented on We should all be using dependency cooldowns blog.yossarian.net/2025/1... · Posted by u/todsacerdoti

compumike · 3 months ago

There's a tradeoff and the assumption here (which I think is solid) is that there's more benefit from avoiding a supply chain attack by blindly (by default) using a dependency cooldown vs. avoiding a zero-day by blindly (by default) staying on the bleeding edge of new releases.

It's comparing the likelihood of an update introducing a new vulnerability to the likelihood of it fixing a vulnerability.

While the article frames this problem in terms of deliberate, intentional supply chain attacks, I'm sure the majority of bugs and vulnerabilities were never supply chain attacks: they were just ordinary bugs introduced unintentionally in the normal course of software development.

On the unintentional bug/vulnerability side, I think there's a similar argument to be made. Maybe even SemVer can help as a heuristic: a patch version increment is likely safer (less likely to introduce new bugs/regressions/vulnerabilities) than a minor version increment, so a patch version increment could have a shorter cooldown.

If I'm currently running version 2.3.4, and there's a new release 2.4.0, then (unless there's a feature or bugfix I need ASAP), I'm probably better off waiting N days, or until 2.4.1 comes out and fixes the new bugs introduced by 2.4.0!

compumike commented on Cloudflare Global Network experiencing issues cloudflarestatus.com/inci... · Posted by u/imdsm

jcfrei · 3 months ago

This is unrelated to the cloudflare incident but thanks a lot for making that page. I keep checking it from time to time and it's basically the main data source for my long term investing.

compumike · 3 months ago

I appreciate that, thank you! :)

compumike commented on Cloudflare Global Network experiencing issues cloudflarestatus.com/inci... · Posted by u/imdsm

farhadhf · 3 months ago

Pretty much everything is down (checking from the Netherlands). The Cloudflare dashboard itself is experiencing an outage as well.

Not-so-funny thing is that the Betterstack dashboard is down but our status page hosted by Betterstack is up, and we can't access the dashboard to create an incident and let our customers know what's going on.

Edit: wording.

compumike · 3 months ago

Could always just use a status page that updates itself. For my side project Total Real Returns [1], if you scroll down and look at the page footer, I have a live status/uptime widget [2] (just an <img> tag, no JS) which links to an externally-hosted status page [3]. Obviously not critical for a side project, but kind of neat, and was fun to build. :)

[1] https://totalrealreturns.com/

[2] https://status.heyoncall.com/svg/uptime/zCFGfCmjJN6XBX0pACYY...

[3] https://status.heyoncall.com/o/zCFGfCmjJN6XBX0pACYY