Yep! I remember one of the ISPs I worked for paying like $15K for a Cisco 4500 router with 8 synchronous serial ports and a couple of 10 megabit ethernets. We'd laugh at the sorta bandwidth today. We had a bunch of T1s and a couple of Ascend boxes off of the ethernet.
They work, but the documentation is overwhelming. With my last GCP project, I ran into security theater folks that didn't like predefined roles and demanded custom roles with dozens and dozens of granular permissions. Do you think they audited all those permissions? Nope. The simpler predefined roles were just not permitted by their checklists.
Security may be solved, but IAM is still a nightmare on both GCP and AWS. Nobody understands what all those privileges / actions / conditions / etc. do. Maybe LLMs pretend to.
Unless you're paying millions a month, they don't care. It can take weeks to get AWS SES (Simple Email Service) "approved for production" on a small account, and that's after dozens of emails to prove you're not a spammer. For an enterprise I was working with, I asked and 5 minutes later it was approved. No questions.
The fact that the private IPv4 block is not globally reachable counts for something. If I accidentally give you my private IP (192.168.17.102, by the way!) you can't do anything, absent other details, no matter how much misconfiguration occurs. If I give you my IPv6 GUA, there's a lot more variability.
Opus 5.5 is quite effective at generating Terraform for a "typical" app that needs a load balancer, compute, and a database or two. That's the exact sort of cookie-cutter, rote work that AI is perfect for and no one is really going to miss.
True. There were few (no other?) options for routers back then. I have fond memories of locking myself out of an ISP's core router then having to power cycle it.
Yep. I run into "enterprise" cloud environments where IPv6 is disabled, all the time. The sad thing is IPv6 is easier to understand than v4, just based on subnetting practices alone. The real problem is the average "IT" person doesn't understand hexadecimal.
Blocking /128 is unlikely to block anyone for very long around here. Both the major ISPs give out /56 blocks with prefix delegation. In almost 4 years, mine hasn't changed.
Most IPv4 "security" is a side-effect of NAT. NAT was not intended as a security feature, but it does provide a level of security in the common consumer implementation (PAT, single external IP, unroutable internal network.)
The tech that made the old web still exists. Everything is a GET, a form POST, and needs a page reload. You can still use tables for layout like it's 1996.
Not quite. AI is the new "god" for many. All seeing. All knowing. Just the other day I said something that contradicted Claude. Then I heard, "but Claude told me..." Then I sent a screenshot of the actual thing we were talking about.
Scary perhaps, but not surprising. Most IT "audits" and security reviews are little more than performative box checking activities. I'm sure their documentation and screenshots looked great.
Fortunately, you can investigate this stuff for yourself and develop your own opinion. IMHO, DNSSEC doesn't actually "secure" much of anything. It can be disabled trivially by anyone operating a resolver. As I mentioned elsewhere, none of the major sites (FAANG) use it. What does that tell you?
DNSSEC creates more operational issues than it solves. It's easy to screw up, which means your domain completely stops resolving when that inevitably occurs. None of the FAANGs use it for their main web sites, so what does that tell you?
It can also be disabled at the whim of anyone operating a resolver, as was seen with Cloudflare during the .de TLD DNSSEC snafu back in May.
I often run into larger entities that would prefer to use $expensive_cert_vendor instead of the automated certificate services built into the cloud platform they're already using (AWS, GCP.) They really enjoy those manual IT processes or using some third party thing to achieve the same result.