Take DJB. He's an expert and djbdns has a stellar security record. He's not going to spend his time trying to make systemd's resolver secure. Instead systemd is going to end up repeating all the same mistakes BIND has made. At least BIND has a substantial head start over systemd-resolved.
So they would work on systemd then? Since it is set to have a far larger customer base in the near and long term than most independent cache resolvers (just see the list of distro's who have taken it up).
> Instead systemd is going to end up repeating all the same mistakes BIND has made. At least BIND has a substantial head start over systemd-resolved.
Potentially. But I don't think you've successfully shown that that is inherently due to systemd's design, complexity, or componentization. Instead it is likely due to systemd's relative immaturity of a codebase and that as discussed previously most cache resolvers have had a checkered history of security issues (and assuming systemd is "as bad" as everyone else, it will have security issues).
Is the systemd project passionate about DNS? Is the curl team passionate about protocols and files? Is the opensmtpd team passionate about e-mail?
I think two of the three are yes answers. The great strength of UNIX has always been people's ability to flock to places where their passion is shared and improve and learn (institutional knowledge) about their passions.
I don't think systemd will have passionate people for these extra services and it seems they don't have the institutional knowledge that others have gained since this is not a new kind of bug.
Tons of projects with a single focus have had countless security problems, some so bad the entire project was completely scrapped.
So the entire argument is based on a flawed premise.
Yes. And when it happened before, it was The Bug of the Century. Repeating that mistake is either stupidly incompetent or proof the systemd developers were literally born yesterday.
New development is expected to have some bugs, but it shouldn't sound like a tribute band playing the greatest hits of yesteryear. And they can't exactly fallback on the old standby of "oh, it's a legacy code base."
Why? This wasn't caused by systemd's complexity or having too much components interconnect poorly. It was a bug in one of their implementations that could have equally happened had it been a stand-alone DNS cache resolver.
> Generally, projects focused on doing one thing are able to do it well, while projects that attempt to do many things have a hard time doing any of them well.
I'd totally buy that if BIND didn't have such a checkered history. I mean with BIND 9 they scrapped the entire project and started again because it was so insecure...
Yet they're only attempting to do "one thing" so according to you they should have done it well.
> Unfortunately, as the steady stream of cache poisoning vulnerabilities in other DNS servers have demonstrated, implementing DNS securely is really hard.
This line oddly contradicts the line that directly proceeds it.
> For this reason, it's a task best left to a mature project run by people with DNS-specific experience who can focus on doing that one thing well.
According to the previous line they aren't doing that one thing well...