3 ms·

This is a perfect example of why the systemd approach of putting a bunch of disparate components under a single tightly-coupled umbrella is bad engineering. Ge

by agwa 12y ago

This is a perfect example of why the systemd approach of putting a bunch of disparate components under a single tightly-coupled umbrella is bad engineering. 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. Unfortunately, as the steady stream of cache poisoning vulnerabilities in other DNS servers have demonstrated, implementing DNS securely is really hard. A less-than-perfect attempt at implementing a caching DNS resolver will be insecure. 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.

Someone1234 12y ago
> This is a perfect example of why the systemd approach of reinventing a bunch of existing components under a single tightly-coupled umbrella is a bad approach. 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...
- agwa 12y ago
  The reason why a project with a bunch of tightly-coupled disparate components will have a hard time doing anything well is that an expert who could do a good job isn't going to spend their time working on an implementation that can only be used along with a bunch of unrelated baggage. They're going to work on an independent implementation that can be used by as many people as possible. 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.
  - Someone1234 12y ago
    > They're going to work on an independent implementation that can be used by as many people as possible. 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).
    - protomyth 12y ago
      > 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). 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.
      - Someone1234 12y ago
        As has already been shown through example, having a single unified purpose does not make something immune (or even resistant) from security issues. 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.
        12y ago
- tedunangst 12y ago
  > It was a bug in one of their implementations that could have equally happened had it been a stand-alone DNS cache resolver. 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."
deleted 12y ago
[deleted]
erhardm 12y ago
Totally agree. It's mind blowing to realize that because of the init system we have on our system we are now vulnerable to DNS poisoning. Do one thing and do it well.
- Xylakant 12y ago
  The init system is not vulnerable. The local dns caching daemon that you can optionally install and that shares the name and maybe some code with the init system is vulnerable. It's like saying "package dnsmasq.deb is vulnerable, so sysv-init.deb is now vulnerable, they share an extension"

by agwa 12y ago

Someone1234 12y ago

> This is a perfect example of why the systemd approach of reinventing a bunch of existing components under a single tightly-coupled umbrella is a bad approach. 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...

agwa 12y ago
The reason why a project with a bunch of tightly-coupled disparate components will have a hard time doing anything well is that an expert who could do a good job isn't going to spend their time working on an implementation that can only be used along with a bunch of unrelated baggage. They're going to work on an independent implementation that can be used by as many people as possible. 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.
- Someone1234 12y ago
  > They're going to work on an independent implementation that can be used by as many people as possible. 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).
  - protomyth 12y ago
    > 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). 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.
    - Someone1234 12y ago
      As has already been shown through example, having a single unified purpose does not make something immune (or even resistant) from security issues. 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.
      - 12y ago
tedunangst 12y ago
> It was a bug in one of their implementations that could have equally happened had it been a stand-alone DNS cache resolver. 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."

deleted 12y ago

[deleted]

erhardm 12y ago

Totally agree. It's mind blowing to realize that because of the init system we have on our system we are now vulnerable to DNS poisoning. Do one thing and do it well.

Xylakant 12y ago
The init system is not vulnerable. The local dns caching daemon that you can optionally install and that shares the name and maybe some code with the init system is vulnerable. It's like saying "package dnsmasq.deb is vulnerable, so sysv-init.deb is now vulnerable, they share an extension"