3 ms·

> Fun fact: since Linux has no built-in DNS caching, most of the DNS queries are looking for … itself. This is wrong in two ways, and isn't factual at all. Fi

by JdeBP 11y ago

> Fun fact: since Linux has no built-in DNS caching, most of the DNS queries are looking for … itself. This is wrong in two ways, and isn't factual at all. First, the cause of the queries is nothing to do with whether DNS query answers are cached locally or not. There is no causal link here. What causes such queries is applications that repeatedly look up the same things, over and over again; not the DNS server arrangements. One could argue that this is poor design in the applications, and that they should remember the results of lookups. But there's a good counterargument to make that this is good design. Applications shouldn't all maintain their own private idiosyncratic DNS lookup result caches. History teaches us that applications attempting to cache their own DNS lookup results invariably do it poorly, for various reasons. (See Mozilla bug #162871, for one of several examples.) Good design is to hand that over to a common external subsystem shared by all applications. Which brings us to the second way in which this is wrong. A common Unix tradition is for all machines to have local proxy DNS servers. Linux operating systems have plenty of such server softwares that can be used: dnsmasq, pdnsd, PowerDNS, unbound ... One of the simplest, which does only caching and doesn't attempt to wear other hats simultaneously, is even named "dnscache". Set this up listening on the loopback interface, point its back-end at the relevant external servers, point the DNS client library at it, and -- voilà! -- a local caching proxy DNS server. * http://cr.yp.to/djbdns.html http://cr.yp.to/djbdns.html * http://cr.yp.to/djbdns/run-cache.html http://cr.yp.to/djbdns/run-cache.html * http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/djbdns-problems.html#wrong-icann-root http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/djb... * http://cr.yp.to/djbdns/install.html http://cr.yp.to/djbdns/install.html I run server machines that have applications that repeatedly look up the same domain names again and again. Each runs a local dnscache instance, which ameliorates this very well.

TheRealDunkirk 11y ago
I guess this goes to show that you can be a full-fledged expert in one development "world," and miss easy things in another. I see this a lot in the apparent expectations of people because of their ingrained presumptions of the OS platform. This article is of interest to HN because Mr. Craver is on a leading edge of .NET development and deployment, and this is an insightful oversight. I spent 20 years getting deep with PHP, and then Rails, on Linux, where, IMO, doing CI builds with something like Jenkins or Heroku is pretty straightforward. For the past couple years, I've been doing .NET, and, while I never really stopped doing ".NET" since the VB 3.0 days, I've had a lot to learn to get into doing serious, enterprise-level stuff. I just took my first steps in setting up auto-building with Visual Studio Team Services, and my experience has left me really disappointed. Dealing with changing variable values per environment is really hacky, no matter which of a handful of tricks you want to try. So much so, I left the whole thing hanging, and have gone back to doing releases by hand. Skimming the article, and seeing discussion about this topic in the comments, leads me to conclude that my experience wasn't just limited by my ignorance, and that this is still an area that is underserved in the .NET world. You'd think someone would have neatly sorted this by now. I keep looking for the oversight in MY case, but I'm not finding it.
- insulanian 11y ago
  > gone back to doing releases by hand. Did you try Octopus Deploy (1) or Deployment Cockpit (2) [1] https://octopus.com https://octopus.com [2] http://deploymentcockpit.com http://deploymentcockpit.com
  - TheRealDunkirk 11y ago
    No. Thanks for the tip. I'm going to try to crack this nut again. I'll check them out.
Nick-Craver 11y ago
I don't believe your assessment is correct. I very specifically said built-in. This remains true. If curious, we're on CentOS 7 specifically. I didn't say there aren't any options, only that there aren't any built-in. What you described as alternatives are totally true, but they still aren't built-in. It's a manual/puppet/chef/etc. config everyone has to do. As for the applications - we have little direct input to TeamCity of Gitlab (the problem children here). And even if we did, I think we agree: the application level shouldn't cache anyway. That being said, we're looking at `dnscache` as one of a few solutions here. But the point remains: we have to do it.
- codemunkee 11y ago
  I too read that part of your post and paused. Your argument about it not being built into Linux is interesting because it gets down to what is Linux versus what is the distribution, etc. Which I don't think is worth getting into. The truth is I'm almost positive you rely on plenty of other core components not built into Linux proper. DNS caching is certainly available to you and if you don't have config mgmt or an immutable infrastructure model in place, I'd start considering it soon.
- JdeBP 11y ago
  You are employing a faulty concept of what constitutes built-in. This is not Windows, or one of the BSDs. You're using one of the Linux distributions where everything is made up of installing packages. There is no meaningful "built-in"/"not-built-in" difference between installing one of these DNS server packages from a CentOS 7 repository and installing any other CentOS packages from a CentOS 7 repository. > All software on a Red Hat Enterprise Linux system is divided into RPM packages which can be installed, upgraded, or removed. -- https://www.centos.org/docs/5/html/Deployment_Guide-en-US/pt-pkg-management.html https://www.centos.org/docs/5/html/Deployment_Guide-en-US/pt... A (very) quick check indicates that the CentOS 7 "main" and "updates" repositories have at least three of the DNS softwares that I mentioned. Ubuntu 16 is better endowed, and has all of them that I mentioned, and an additional "Debian fork of djbdns" that I did not, in Ubuntu's "main" and "universe" repositories.

by JdeBP 11y ago

TheRealDunkirk 11y ago

I guess this goes to show that you can be a full-fledged expert in one development "world," and miss easy things in another. I see this a lot in the apparent expectations of people because of their ingrained presumptions of the OS platform. This article is of interest to HN because Mr. Craver is on a leading edge of .NET development and deployment, and this is an insightful oversight. I spent 20 years getting deep with PHP, and then Rails, on Linux, where, IMO, doing CI builds with something like Jenkins or Heroku is pretty straightforward. For the past couple years, I've been doing .NET, and, while I never really stopped doing ".NET" since the VB 3.0 days, I've had a lot to learn to get into doing serious, enterprise-level stuff. I just took my first steps in setting up auto-building with Visual Studio Team Services, and my experience has left me really disappointed. Dealing with changing variable values per environment is really hacky, no matter which of a handful of tricks you want to try. So much so, I left the whole thing hanging, and have gone back to doing releases by hand. Skimming the article, and seeing discussion about this topic in the comments, leads me to conclude that my experience wasn't just limited by my ignorance, and that this is still an area that is underserved in the .NET world. You'd think someone would have neatly sorted this by now. I keep looking for the oversight in MY case, but I'm not finding it.

insulanian 11y ago
> gone back to doing releases by hand. Did you try Octopus Deploy (1) or Deployment Cockpit (2) [1] https://octopus.com https://octopus.com [2] http://deploymentcockpit.com http://deploymentcockpit.com
- TheRealDunkirk 11y ago
  No. Thanks for the tip. I'm going to try to crack this nut again. I'll check them out.

Nick-Craver 11y ago

I don't believe your assessment is correct. I very specifically said built-in. This remains true. If curious, we're on CentOS 7 specifically. I didn't say there aren't any options, only that there aren't any built-in. What you described as alternatives are totally true, but they still aren't built-in. It's a manual/puppet/chef/etc. config everyone has to do. As for the applications - we have little direct input to TeamCity of Gitlab (the problem children here). And even if we did, I think we agree: the application level shouldn't cache anyway. That being said, we're looking at `dnscache` as one of a few solutions here. But the point remains: we have to do it.

codemunkee 11y ago
I too read that part of your post and paused. Your argument about it not being built into Linux is interesting because it gets down to what is Linux versus what is the distribution, etc. Which I don't think is worth getting into. The truth is I'm almost positive you rely on plenty of other core components not built into Linux proper. DNS caching is certainly available to you and if you don't have config mgmt or an immutable infrastructure model in place, I'd start considering it soon.
JdeBP 11y ago
You are employing a faulty concept of what constitutes built-in. This is not Windows, or one of the BSDs. You're using one of the Linux distributions where everything is made up of installing packages. There is no meaningful "built-in"/"not-built-in" difference between installing one of these DNS server packages from a CentOS 7 repository and installing any other CentOS packages from a CentOS 7 repository. > All software on a Red Hat Enterprise Linux system is divided into RPM packages which can be installed, upgraded, or removed. -- https://www.centos.org/docs/5/html/Deployment_Guide-en-US/pt-pkg-management.html https://www.centos.org/docs/5/html/Deployment_Guide-en-US/pt... A (very) quick check indicates that the CentOS 7 "main" and "updates" repositories have at least three of the DNS softwares that I mentioned. Ubuntu 16 is better endowed, and has all of them that I mentioned, and an additional "Debian fork of djbdns" that I did not, in Ubuntu's "main" and "universe" repositories.