On Sat, 15 Nov 2014 08:53:59 -0500 Sam Varshavchik <mr...@courier-mta.com> wrote:
> Making the rounds of various technical mailing lists yesterday, with a > subject that's typically a variation of "Just for yucks, and giggles" isa > link to a commit to systemd's git, adding DNS caching to systemd; in one, > huge 857 line glop. Here's its entire commit message: "resolved: add DNS > cache". > > And, it's beauty to read. Made me teary-eyed to know that systemd will ca > che my DNS queries. Not sure why systemd, all of a sudden, needs to make DNS > queries. But if it does, it's going to cache them now! Such a sight to behold > makes my heart skip a beat: now, not just bind, or pretty much eve > ry DNS server that automatically caches DNS for you – but so will sy > stemd! > > But, seriously folks, systemd's DNS caching achieves absolutely 100% nothing. > Really. Surprised? Well, you'll be shocked to know that the DNS server that > systemd queries for that DNS RR, such as the stock "bind", already > automatically caches all recursive DNS replies!! systemd's own caching > produces absolutely zero useful results. On the oft chance that i > t sends a query for a non-cached RR, the local DNS server will cache the > response, before returning it to systemd, and then use the cached respons > e for all future queries. That's what DNS servers do: provide caching for > local clients. It's inherent in DNS's design: DNS was explicitly designedto > use aggressive caching, it's an internet-wide, distributed, locally cache > d database. > > Isn't modern technology amazing? > > I'm willing to consider the possibility that I missed something obvious, some > obvious value-added result from caching DNS RRs directly by systemd, and I'll > stick around for someone to enlighten me; or if Occam's razor applies, and > the author of that commit had no idea that bind already automatically caches > DNS responses, and, more importantly, that its cachi > ng algorithms are a result of painful lessons learned from various DNS cache > poisoning attacks, that have circulated around the intertubes, for the la > st couple of years. > > The only possible use case for this kind of caching approach would be if: > > A) You do not have a local DNS server nearby; and you have non-negligible > latencies to whatever DNS server you use. > > B) Your queries tend to be for domains that your DNS servers are not > authoritative for, so they'll benefit from local caching. > > So, can someone explain to me how likely this is going to be the case ina > typical deployment scenario that systemd is targeted for; in an average > corporate environment where systemd's alleged benefits will supposedly sh > ine? > > I would guess that a typical systemd deployment, in a corporate/business > environment, will certainly have multiple, low-latency DNS servers nearby > , won't that be the case? And, if so, then this is just another potentially > exploitable security hole in systemd, nothing more. > > P.S. After I wrote the above, poking around, Google dumped this onto my > screen: > > http://seclists.org/oss-sec/2014/q4/592 > > Mental note to myself: go back and check the timestamp of the systemd git > commit – before, or after, this was disclosed… > When will be the kernel embeded in the systemd? BR, Bob -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
