4 ms·

The DNS Camel (2018)

9 points by omnibrain 5y ago

0xbadcafebee 5y ago
> DNS developers frequently see immense complexity not as a problem but as a welcome challenge to be overcome. I think all developers favor complexity. Complex widgets are just more fun to make, they make you more money, and complex things are just way easier to make than simple things. If you have a problem, throwing more software at it is just what you do. And if you want to retain backwards compatibility, or not have to build around something, you usually have to add complexity.
- userbinator 5y ago
  Not all but certainly most. I definitely don't think more complex code is more fun, and a complex system will only give you job security up to the point that it gets replaced by a much simpler, more efficient system.
dmckeon 5y ago
It seems like having a working and testable reference implementation should be a prerequisite for adoption of core internet technologies. In other words, more running code than rough concensus.
- tptacek 5y ago
  We had a working testable reference for the TLS Heartbeat Extension. Disaster still befell us.
1vuio0pswjnm7 5y ago
dnsmasq is a program that is generally used to forward queries to shared DNS caches. I do not intentionally use dnsmasq. (dnsmasq is difficult to avoid because it has been used by OpenWRT as a default and as the basis for Pi-Hole, as well as by numerous commercial vendors, including Google.) The reason I dislike dnsmasq is because I feel it tries to do "too many" things. Regardless of how talented the author may be or whether dnsmasq is bug-free or fixed immediately when bugs are found, I dislike the "omnibus" design pattern. This blog post discusses DNSSEC, and appears to acknowledge it is not simple to add DNSSEC to existing DNS software. Are the costs worth the benefits. The simplest way to avoid cache poisoning is to stop using shared caches. That has been remarkably easy for me to do, and for me it has resulted in faster, not to mention more private (authoritative servers with custom zone files bound to loopback), lookups over the long term. Last year, there were seven new vulnerabilities reported for dnsmasq. Unless I am mistaken, each one required DNSSEC to be enabled. Curiously, on nine occasions different users tried to post the news from the orginial source on those buffer overflows (jsof-tech.com) to HN and eight of the nine times the submission was killed. https://nvd.nist.gov/vuln/detail/CVE-2020-25681 https://nvd.nist.gov/vuln/detail/CVE-2020-25681 https://nvd.nist.gov/vuln/detail/CVE-2020-25682 https://nvd.nist.gov/vuln/detail/CVE-2020-25682 https://nvd.nist.gov/vuln/detail/CVE-2020-25683 https://nvd.nist.gov/vuln/detail/CVE-2020-25683 https://nvd.nist.gov/vuln/detail/CVE-2020-25684 https://nvd.nist.gov/vuln/detail/CVE-2020-25684 https://nvd.nist.gov/vuln/detail/CVE-2020-25685 https://nvd.nist.gov/vuln/detail/CVE-2020-25685 https://nvd.nist.gov/vuln/detail/CVE-2020-25686 https://nvd.nist.gov/vuln/detail/CVE-2020-25686 https://nvd.nist.gov/vuln/detail/CVE-2020-25687 https://nvd.nist.gov/vuln/detail/CVE-2020-25687

9 points by omnibrain 5y ago

> DNS developers frequently see immense complexity not as a problem but as a welcome challenge to be overcome. I think all developers favor complexity. Complex widgets are just more fun to make, they make you more money, and complex things are just way easier to make than simple things. If you have a problem, throwing more software at it is just what you do. And if you want to retain backwards compatibility, or not have to build around something, you usually have to add complexity.

userbinator 5y ago
Not all but certainly most. I definitely don't think more complex code is more fun, and a complex system will only give you job security up to the point that it gets replaced by a much simpler, more efficient system.

dmckeon 5y ago

It seems like having a working and testable reference implementation should be a prerequisite for adoption of core internet technologies. In other words, more running code than rough concensus.

tptacek 5y ago
We had a working testable reference for the TLS Heartbeat Extension. Disaster still befell us.

1vuio0pswjnm7 5y ago

dnsmasq is a program that is generally used to forward queries to shared DNS caches. I do not intentionally use dnsmasq. (dnsmasq is difficult to avoid because it has been used by OpenWRT as a default and as the basis for Pi-Hole, as well as by numerous commercial vendors, including Google.) The reason I dislike dnsmasq is because I feel it tries to do "too many" things. Regardless of how talented the author may be or whether dnsmasq is bug-free or fixed immediately when bugs are found, I dislike the "omnibus" design pattern. This blog post discusses DNSSEC, and appears to acknowledge it is not simple to add DNSSEC to existing DNS software. Are the costs worth the benefits. The simplest way to avoid cache poisoning is to stop using shared caches. That has been remarkably easy for me to do, and for me it has resulted in faster, not to mention more private (authoritative servers with custom zone files bound to loopback), lookups over the long term. Last year, there were seven new vulnerabilities reported for dnsmasq. Unless I am mistaken, each one required DNSSEC to be enabled. Curiously, on nine occasions different users tried to post the news from the orginial source on those buffer overflows (jsof-tech.com) to HN and eight of the nine times the submission was killed. https://nvd.nist.gov/vuln/detail/CVE-2020-25681 https://nvd.nist.gov/vuln/detail/CVE-2020-25681 https://nvd.nist.gov/vuln/detail/CVE-2020-25682 https://nvd.nist.gov/vuln/detail/CVE-2020-25682 https://nvd.nist.gov/vuln/detail/CVE-2020-25683 https://nvd.nist.gov/vuln/detail/CVE-2020-25683 https://nvd.nist.gov/vuln/detail/CVE-2020-25684 https://nvd.nist.gov/vuln/detail/CVE-2020-25684 https://nvd.nist.gov/vuln/detail/CVE-2020-25685 https://nvd.nist.gov/vuln/detail/CVE-2020-25685 https://nvd.nist.gov/vuln/detail/CVE-2020-25686 https://nvd.nist.gov/vuln/detail/CVE-2020-25686 https://nvd.nist.gov/vuln/detail/CVE-2020-25687 https://nvd.nist.gov/vuln/detail/CVE-2020-25687