12 ms·

A special shout out to Lennart Poettering for recently breaking dig +trace! https://github.com/systemd/systemd/issues/5897 https://github.com/systemd/systemd/i

A special shout out to Lennart Poettering for recently breaking dig +trace! https://github.com/systemd/systemd/issues/5897 https://github.com/systemd/systemd/issues/5897

tyingq 8y ago
"poettering commented...This is really by design." Oy. It worked before. I get his notion of not wanting to make it a full dns resolver, but breaking something that worked seems clear enough.
jrockway 8y ago
It sounds like the underlying issue is that people think DNS resolution linux works like: 1) Read resolv.conf 2) Send DNS packets directly to one of the named servers. But that is never how it worked. Linux has always had the wacky NSS plugins that are involved, and the underlying model ends up being: 1) glibc or similar reads resolv.conf 2) glibc or similar does random stuff depending on a variety of other files 3) good luck if you aren't using glibc (go implements its own DNS stack, for example) This would be a Linux rant, but OS X is also crazy and I imagine all other OSes are too. The underlying issue is that "name resolution" and "DNS" are not exactly the same thing. There are all sorts of other things people expect to be able to use for name resolution, like mDNS. (I recall using LDAP and yp at some points in the past.) Thus, expecting a DNS trace to work for all "name resolution" is folly. If you want to dig +trace to work, just point it at a DNS server with the @ argument. dig is a DNS client, not a name resolution client.
- jjoonathan 8y ago
  The fact that linux (and OSX and Windows) support mechanisms of name resolution other than resolv.conf has zero bearing on dig's previous utility as a resolv.conf diagnostic tool, zero bearing on the fact that systemd changed the behavior of a nonrecursive query for root zone NS records, and zero bearing on the fact that Poettering insisted that this wasn't a problem instead of fixing it.
  - js2 8y ago
    dig is not a resolv.conf diagnostic tool, it's a DNS lookup utility. I don't think it even parses the full syntax of resolv.conf. Heck, it doesn't even consider multiple nameserver statements.
    - inopinatus 8y ago
      It worked before, they broke it, and as usual the response is an egregious "fuck you" and a queue of apologists castigating the aggrieved that they were Doing It Wrong All Those Years And They Must In Future Conform To Only The Approved Way. This is why people loathe systemd.
      - magila 8y ago
        Something which is wrong but has mostly worked by accident is still wrong. A tool which parses a config file it does not own and whose semantics do not necessarily match what the tool expects is wrong. The blame for any breakage which results is clearly on the tool in question. Lennart has done more to improve Linux than all of his detractors on HN combined in no small part because he is willing to break broken things and force them to be fixed. If the people whining about Lennart/systemd spent half as much time fixing their shit as they did writing angry comments on the internet the Linux ecosystem would be in much better shape.
        moocowtruck 8y ago
        yep this is the only way we're going to be able to drag linux into future, where maybe one day it actually will be year of the linux desktop
        inopinatus 8y ago
        It wasn’t broken, didn’t need fixing, and the config files existed before systemd did, so claiming they “belong to a tool” really just exemplifies the arrogance implicit in the whole project. As for contributing, no, you don’t get to piss in the well and then demand everyone drinks from it.

A special shout out to Lennart Poettering for recently breaking dig +trace! https://github.com/systemd/systemd/issues/5897 https://github.com/systemd/systemd/issues/5897

tyingq 8y ago

"poettering commented...This is really by design." Oy. It worked before. I get his notion of not wanting to make it a full dns resolver, but breaking something that worked seems clear enough.

jrockway 8y ago

It sounds like the underlying issue is that people think DNS resolution linux works like: 1) Read resolv.conf 2) Send DNS packets directly to one of the named servers. But that is never how it worked. Linux has always had the wacky NSS plugins that are involved, and the underlying model ends up being: 1) glibc or similar reads resolv.conf 2) glibc or similar does random stuff depending on a variety of other files 3) good luck if you aren't using glibc (go implements its own DNS stack, for example) This would be a Linux rant, but OS X is also crazy and I imagine all other OSes are too. The underlying issue is that "name resolution" and "DNS" are not exactly the same thing. There are all sorts of other things people expect to be able to use for name resolution, like mDNS. (I recall using LDAP and yp at some points in the past.) Thus, expecting a DNS trace to work for all "name resolution" is folly. If you want to dig +trace to work, just point it at a DNS server with the @ argument. dig is a DNS client, not a name resolution client.

jjoonathan 8y ago
The fact that linux (and OSX and Windows) support mechanisms of name resolution other than resolv.conf has zero bearing on dig's previous utility as a resolv.conf diagnostic tool, zero bearing on the fact that systemd changed the behavior of a nonrecursive query for root zone NS records, and zero bearing on the fact that Poettering insisted that this wasn't a problem instead of fixing it.
- js2 8y ago
  dig is not a resolv.conf diagnostic tool, it's a DNS lookup utility. I don't think it even parses the full syntax of resolv.conf. Heck, it doesn't even consider multiple nameserver statements.
  - inopinatus 8y ago
    It worked before, they broke it, and as usual the response is an egregious "fuck you" and a queue of apologists castigating the aggrieved that they were Doing It Wrong All Those Years And They Must In Future Conform To Only The Approved Way. This is why people loathe systemd.
    - magila 8y ago
      Something which is wrong but has mostly worked by accident is still wrong. A tool which parses a config file it does not own and whose semantics do not necessarily match what the tool expects is wrong. The blame for any breakage which results is clearly on the tool in question. Lennart has done more to improve Linux than all of his detractors on HN combined in no small part because he is willing to break broken things and force them to be fixed. If the people whining about Lennart/systemd spent half as much time fixing their shit as they did writing angry comments on the internet the Linux ecosystem would be in much better shape.
      - moocowtruck 8y ago
        yep this is the only way we're going to be able to drag linux into future, where maybe one day it actually will be year of the linux desktop
      - inopinatus 8y ago
        It wasn’t broken, didn’t need fixing, and the config files existed before systemd did, so claiming they “belong to a tool” really just exemplifies the arrogance implicit in the whole project. As for contributing, no, you don’t get to piss in the well and then demand everyone drinks from it.