8 ms·

Am I the only one who is getting fed up with everything under the sun having their own DNS resolver and DNS cache? It's border-lining madness right now. Before

Am I the only one who is getting fed up with everything under the sun having their own DNS resolver and DNS cache? It's border-lining madness right now. Before you had a situation like this. ISP: Server and cache. Router: Client, server and cache. OS: Client and cache. So if you ever encounter DNS failing, you only had 3 possible places to look for errors, or maybe not even errors, just stale data that may or may not correct itself over time. Flush the caches you can and hope for the best. Rinse and repeat. But then came the browsers and decided that 3 levels of caching was good enough. Let's add more which can fail in the name of performance! Combine this with mobile, mobility and data-roaming and now you not only have a DNS-cache (based on already tripple-cached data) which often is guaranteed to be wrong, your browser may actually have cached the wrong DNS-servers, so when you roam from Wifi to cell-data your precious LAN DNS servers are no longer available and your browser just looks stupid. And now systemd adds to this. What the flying fuck? All this nonsense because someone somewhere decided that a nice, shared, global OS level client and cache wasn't good enough. Handling this complexity once would just be too easy. Can someone tell me why? Why wasn't it good enough? What was it that prompted someone to go reimplement all this wrongly, yet again? Yes this is a rant, but if there are underlying technical reasons for this nonsense, I'm very, very interested to hear about it.

unwind 12y ago
The commit's comment (http://cgit.freedesktop.org/systemd/systemd/commit/?id=322345fdb9865ef2477fba8e4bdde0e1183ef505 http://cgit.freedesktop.org/systemd/systemd/commit/?id=32234...) says it all: resolved: add DNS cache Yes, that's the full commit message for what I think is the commit that adds the feature. I was trying to dig up an authorative source for the "why" you're asking, but I guess that failed. Perhaps it was discussed/motivated/described/something somewhere else, like a mailing list, I didn't search further.
- e40 12y ago
  Yes, that's the full commit message for what I think is the commit that adds the feature. If true (that it is a 4 word commit message), that is a disgrace. Seriously, something as important as this should contain a lot more information, if not just a pointer to a place that provides it.
  - custardcream 12y ago
    Lennart proclaimed therefore we all must follow. That appears to be how it works these days. No community, no discussion. Someone with commit access says bend over or fork it. Actually fuck that. Which is why I'm sitting here on a FreeBSD machine.
    - antientropic 12y ago
      I don't understand this attitude. Lennart has every right to write a DNS resolver if he feels like it. And you have every right not to use it. Nobody is being forced to do anything. (I'm not aware of any distribution currently using systemd-resolved by default, and you can disable it at build time and runtime.) So what's the problem exactly?
      - rwmj 12y ago
        A couple of problems: (1) This resolver has security bugs which have been fixed in the existing daemons. That doesn't matter except that: (2) systemd utilities get an easier route into distros than competing utilities, even where the competition is much better or more secure. This really matters since Linux improves because of the Darwinian nature of the competition between the different components. You can't have one group of packages claiming they are the "one true standard", or this doesn't work.
      - custardcream 12y ago
        Problems: 1. Solved problem. Contribute to something else. 2. Its another tentacle hanging off systemd. Some of us pay for our software (RHEL) so we'd in turn like to have some say in what we have to manage rather than prescriptive software development. We don't really get to choose to not use it because of the incestuous nature of the Linux ecosystem at the moment (I.e. Freedesktop/gnome/systemd). 3. Systemd is a buggy piece of crap. As are several of the "stable" bits of systemd I have encountered in RHEL7. I have quite a bit of experience with systemd and i really don't want it consuming any more things badly. Its been a complete pain in the arse to be honest. An init system has never been a problem until now. Its totally unreliable and incredibly difficult to debug. 4. Some of us get shit done, not use the ecosystem as a playground for egos and quote frankly incompetent twattery. This stuff can go on in the sidelines and mature independently, not knotted into the next "stable" drop because everything has suddenly been tangled with it. Its a complete fuck up at all levels and I haven't even started on the technical marvels of introducing something with the complexity of COM into a process model that requires reliability. This is not how to do software.
jacquesm 12y ago
You forgot about host files. Those typically over-rule the resolver so you have to check those as well.
- ominous_prime 12y ago
  Technically, those only over-rule the resolver from the local system libraries. They do not over-rule DNS queries.
  - jacquesm 12y ago
    Sure, but your average application does not do a DNS query directly, it simply uses gethostbyname and depends on those local system libraries to figure out what to return.
ominous_prime 12y ago
> And now systemd adds to this. What the flying fuck? While I agree with you that these layers of caching can lead to headaches, Linux doesn't have a built-in cache (and distros often don't provide one by default). Systemd would be one way to provide this, instead of other daemons that have been used in the past, like nscd, dnsmasq or bind. So it's not adding yet another layer, just providing the layer at the local host. As for technical reasons, I'm not sure what you want to hear, each layer implements a cache for performance and/or efficiency. No one throws in a DNS cache just because they feel like it.
- jacquesm 12y ago
  Linux doesn't need a cache, you can simply run a local DNS server. The kernel should not do more than it needs to do. (It's bloated enough as it is)
  - ominous_prime 12y ago
    I don't understand your comment. a DNS server is typically also a cache, and this is what systemd was attempting to provide, without the public server part. It's the same thing that distros were using e.g. dnsmasq for. What does the kernel have to do with this? No one is proposing that the kernel should have a DNS cache.
    - jacquesm 12y ago
      GP says 'Linux doesn't have a built in cache'. I presume (hopefully correct) that he means 'the kernel', since Linux doesn't have anything 'built in' that you don't run as a user process. The kernel of course has plenty of stuff built in but (fortunately) it tries hard to stay away from things that can and should be done in userland. Systemd is a user process and now tries to replicate functionality that we already had a perfectly good solution for. Since a DNS server is typically also a cache we already had this functionality (and more), simply make it listen to a local port and nothing else. That way you don't need to resort to rebuilding things we already have with incompatible interfaces.
_wmd 12y ago
Every client operating system under the sun implements a DNS cache, its part of the intended design of DNS. This is just systemd's bikeshed of a function already available on Linux, via nscd. Without caching, all DNS queries degrade to worst case behaviour, which is a recursive query involving 4-6 or more round trips, starting at the DNS roots (which, good luck finding them, since you don't have their addresses cached, which is exactly what the root hints file is). As for invalidating the cache when network configuration changes arise, that sounds like a bug report for wherever you experienced it. Certainly I've never seen this kind of problem on OS X, nor any time in the past 10 years on Windows.
- tedunangst 12y ago
  > Every client operating system under the sun implements a DNS cache errr, xxxxBSD don't. libc sends every DNS query to wherever /etc/resolv.conf says to send it.
  - deleted 12y ago
    [deleted]
peterwwillis 12y ago
The short answer is: the glibc DNS interface sucks balls and systemd wanted extra features. The long answer is: Often, systems do not come feature-complete. There are many cases of a platform, or OS, or service, or framework, or some other piece of software being released without every possible imaginable feature being implemented. When this happens, some other software may need to re-implement some core piece of technology in order to add functionality to it. Usually care is taken to not interfere with other systems or cause additional burden to the user. In the case of DNS, our use of DNS and different networks simultaneously requires additional functionality in order to process requests independently and efficiently. As the DNS protocol itself has an inherent flaw allowing for cache poisoning, it's non-trivial for people to implement without running into this security hole. And as someone else mentioned, the kernel and glibc don't have their own DNS cache. I didn't downvote you for the rant because you weren't being mean or insulting and you genuinely seem to want to know what's going on. But next time you feel yourself posting out of emotional reaction, I recommend typing it out in a draft and save it for a half hour, and see if you might want to reword it later to be less angry/ranty.
takeda 12y ago
Actually Unix out of the box (unlike for example windows) does not have system level dns cache, people often setup things like bind, unbound, dnsmasq, nscd etc. Systemd here tries to be the official standard system level caching. I agree though, about your extra caching sentiment to a degree. Actually as long the caches are RFC complaint (e.g. they obey TIL - looking at you nscd & java) or should be fine.
101914 12y ago
"Am I the only one..." No. But the solution is not to complain, but to use /etc/hosts, run your own root and your own cache. Any software that overrides /etc/hosts is not worth using, in my opinion. There are no "underlying technical reasons" for not letting the user control their own name resolution that benefit the user. Of course, there could be reasons that benefit someone else.
zurn 12y ago
Nit: Routers generally don't do DNS, though they do have (rarely needed) clients.

unwind 12y ago

The commit's comment (http://cgit.freedesktop.org/systemd/systemd/commit/?id=322345fdb9865ef2477fba8e4bdde0e1183ef505 http://cgit.freedesktop.org/systemd/systemd/commit/?id=32234...) says it all: resolved: add DNS cache Yes, that's the full commit message for what I think is the commit that adds the feature. I was trying to dig up an authorative source for the "why" you're asking, but I guess that failed. Perhaps it was discussed/motivated/described/something somewhere else, like a mailing list, I didn't search further.

e40 12y ago
Yes, that's the full commit message for what I think is the commit that adds the feature. If true (that it is a 4 word commit message), that is a disgrace. Seriously, something as important as this should contain a lot more information, if not just a pointer to a place that provides it.
- custardcream 12y ago
  Lennart proclaimed therefore we all must follow. That appears to be how it works these days. No community, no discussion. Someone with commit access says bend over or fork it. Actually fuck that. Which is why I'm sitting here on a FreeBSD machine.
  - antientropic 12y ago
    I don't understand this attitude. Lennart has every right to write a DNS resolver if he feels like it. And you have every right not to use it. Nobody is being forced to do anything. (I'm not aware of any distribution currently using systemd-resolved by default, and you can disable it at build time and runtime.) So what's the problem exactly?
    - rwmj 12y ago
      A couple of problems: (1) This resolver has security bugs which have been fixed in the existing daemons. That doesn't matter except that: (2) systemd utilities get an easier route into distros than competing utilities, even where the competition is much better or more secure. This really matters since Linux improves because of the Darwinian nature of the competition between the different components. You can't have one group of packages claiming they are the "one true standard", or this doesn't work.
    - custardcream 12y ago
      Problems: 1. Solved problem. Contribute to something else. 2. Its another tentacle hanging off systemd. Some of us pay for our software (RHEL) so we'd in turn like to have some say in what we have to manage rather than prescriptive software development. We don't really get to choose to not use it because of the incestuous nature of the Linux ecosystem at the moment (I.e. Freedesktop/gnome/systemd). 3. Systemd is a buggy piece of crap. As are several of the "stable" bits of systemd I have encountered in RHEL7. I have quite a bit of experience with systemd and i really don't want it consuming any more things badly. Its been a complete pain in the arse to be honest. An init system has never been a problem until now. Its totally unreliable and incredibly difficult to debug. 4. Some of us get shit done, not use the ecosystem as a playground for egos and quote frankly incompetent twattery. This stuff can go on in the sidelines and mature independently, not knotted into the next "stable" drop because everything has suddenly been tangled with it. Its a complete fuck up at all levels and I haven't even started on the technical marvels of introducing something with the complexity of COM into a process model that requires reliability. This is not how to do software.

jacquesm 12y ago

You forgot about host files. Those typically over-rule the resolver so you have to check those as well.

ominous_prime 12y ago
Technically, those only over-rule the resolver from the local system libraries. They do not over-rule DNS queries.
- jacquesm 12y ago
  Sure, but your average application does not do a DNS query directly, it simply uses gethostbyname and depends on those local system libraries to figure out what to return.

ominous_prime 12y ago

> And now systemd adds to this. What the flying fuck? While I agree with you that these layers of caching can lead to headaches, Linux doesn't have a built-in cache (and distros often don't provide one by default). Systemd would be one way to provide this, instead of other daemons that have been used in the past, like nscd, dnsmasq or bind. So it's not adding yet another layer, just providing the layer at the local host. As for technical reasons, I'm not sure what you want to hear, each layer implements a cache for performance and/or efficiency. No one throws in a DNS cache just because they feel like it.

jacquesm 12y ago
Linux doesn't need a cache, you can simply run a local DNS server. The kernel should not do more than it needs to do. (It's bloated enough as it is)
- ominous_prime 12y ago
  I don't understand your comment. a DNS server is typically also a cache, and this is what systemd was attempting to provide, without the public server part. It's the same thing that distros were using e.g. dnsmasq for. What does the kernel have to do with this? No one is proposing that the kernel should have a DNS cache.
  - jacquesm 12y ago
    GP says 'Linux doesn't have a built in cache'. I presume (hopefully correct) that he means 'the kernel', since Linux doesn't have anything 'built in' that you don't run as a user process. The kernel of course has plenty of stuff built in but (fortunately) it tries hard to stay away from things that can and should be done in userland. Systemd is a user process and now tries to replicate functionality that we already had a perfectly good solution for. Since a DNS server is typically also a cache we already had this functionality (and more), simply make it listen to a local port and nothing else. That way you don't need to resort to rebuilding things we already have with incompatible interfaces.

_wmd 12y ago

Every client operating system under the sun implements a DNS cache, its part of the intended design of DNS. This is just systemd's bikeshed of a function already available on Linux, via nscd. Without caching, all DNS queries degrade to worst case behaviour, which is a recursive query involving 4-6 or more round trips, starting at the DNS roots (which, good luck finding them, since you don't have their addresses cached, which is exactly what the root hints file is). As for invalidating the cache when network configuration changes arise, that sounds like a bug report for wherever you experienced it. Certainly I've never seen this kind of problem on OS X, nor any time in the past 10 years on Windows.

tedunangst 12y ago
> Every client operating system under the sun implements a DNS cache errr, xxxxBSD don't. libc sends every DNS query to wherever /etc/resolv.conf says to send it.
- deleted 12y ago
  [deleted]

peterwwillis 12y ago

The short answer is: the glibc DNS interface sucks balls and systemd wanted extra features. The long answer is: Often, systems do not come feature-complete. There are many cases of a platform, or OS, or service, or framework, or some other piece of software being released without every possible imaginable feature being implemented. When this happens, some other software may need to re-implement some core piece of technology in order to add functionality to it. Usually care is taken to not interfere with other systems or cause additional burden to the user. In the case of DNS, our use of DNS and different networks simultaneously requires additional functionality in order to process requests independently and efficiently. As the DNS protocol itself has an inherent flaw allowing for cache poisoning, it's non-trivial for people to implement without running into this security hole. And as someone else mentioned, the kernel and glibc don't have their own DNS cache. I didn't downvote you for the rant because you weren't being mean or insulting and you genuinely seem to want to know what's going on. But next time you feel yourself posting out of emotional reaction, I recommend typing it out in a draft and save it for a half hour, and see if you might want to reword it later to be less angry/ranty.

takeda 12y ago

Actually Unix out of the box (unlike for example windows) does not have system level dns cache, people often setup things like bind, unbound, dnsmasq, nscd etc. Systemd here tries to be the official standard system level caching. I agree though, about your extra caching sentiment to a degree. Actually as long the caches are RFC complaint (e.g. they obey TIL - looking at you nscd & java) or should be fine.

101914 12y ago

"Am I the only one..." No. But the solution is not to complain, but to use /etc/hosts, run your own root and your own cache. Any software that overrides /etc/hosts is not worth using, in my opinion. There are no "underlying technical reasons" for not letting the user control their own name resolution that benefit the user. Of course, there could be reasons that benefit someone else.

zurn 12y ago

Nit: Routers generally don't do DNS, though they do have (rarely needed) clients.