5 ms·

I can't tell if it's sarcasm or genuine, but I 90% agree. There's a lot of things that it makes easier. But there are areas which are just weird and overenginee

I can't tell if it's sarcasm or genuine, but I 90% agree. There's a lot of things that it makes easier. But there are areas which are just weird and overengineered and overcomplicated - for example resolved interacting with old files and creating lots of possible ways it can run. If you look at forums / SO it's obvious people are confused about what it tries to achieve. Instead of creating a whole new system, they could've started by implementing and standardizing the multi-interface behaviour in established projects like dnsmasq. Instead of that they went with NIH where it really wasn't necessary.

theamk 2y ago
For resolve.conf, I think it is fundamentally bad design that is hard to get right. Before systemd, I've spent plenty of time trying to get networkmanager and resolvconf to play together. And then there was those dhcp scripts which would edit the files directly. Also, what do you mean my "standardizing dnsmasq behaviour?" From my recollection of using it (and from manpage[0]), it's pretty basic. You (1) manually edit /etc/resolve.conf to point to localhost dnsmasq instance (2) use app-specific ways to configure nameservers, in dnsmasq's case it's an ad-hoc list of secondary resolv.conf files specified on command line, with no defaults. I don't think this is worth standardizing, as this scheme cannot even represent network interface -> dns entry associations. https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
- viraptor 2y ago
  I didn't say standardizing dnsmasq behaviour. I said multi home/interface which was one of the big reasons to write resolved. They could've added the missing feature to the 2 most popular daemons and use one of them as a default, but instead went with a whole new system written from scratch.
vetinari 2y ago
> If you look at forums / SO it's obvious people are confused about what it tries to achieve. Well, many people are confused about how DNS resolving works. Many of do not consider a problem, when they configure their resolv.conf to two different upstreams, each returning different answers (i.e. one responding for domains that the other doesn't) and then wondering, why stuff is broken.

theamk 2y ago

For resolve.conf, I think it is fundamentally bad design that is hard to get right. Before systemd, I've spent plenty of time trying to get networkmanager and resolvconf to play together. And then there was those dhcp scripts which would edit the files directly. Also, what do you mean my "standardizing dnsmasq behaviour?" From my recollection of using it (and from manpage[0]), it's pretty basic. You (1) manually edit /etc/resolve.conf to point to localhost dnsmasq instance (2) use app-specific ways to configure nameservers, in dnsmasq's case it's an ad-hoc list of secondary resolv.conf files specified on command line, with no defaults. I don't think this is worth standardizing, as this scheme cannot even represent network interface -> dns entry associations. https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

viraptor 2y ago
I didn't say standardizing dnsmasq behaviour. I said multi home/interface which was one of the big reasons to write resolved. They could've added the missing feature to the 2 most popular daemons and use one of them as a default, but instead went with a whole new system written from scratch.

vetinari 2y ago

> If you look at forums / SO it's obvious people are confused about what it tries to achieve. Well, many people are confused about how DNS resolving works. Many of do not consider a problem, when they configure their resolv.conf to two different upstreams, each returning different answers (i.e. one responding for domains that the other doesn't) and then wondering, why stuff is broken.