On 06/01/2015 10:57 PM, Andrew Lutomirski wrote:
This is glibc we're talking about, though. Have you tried to get
a
glibc bug fixed? It's not a pleasant experience.
It is possible, but it requires effort. Admittedly, sometimes that
effort appears disproportionate to what is being fixed.
In this particularly case, only *very* few people are familiar with
resolv/, and test coverage for that part is extremely poor.
For example, the bug I reported has a candidate patch. That patch
isn't applied, and the patch looks like the bug might be a security
issue. It's been in that state for months. This is not unusual for
glibc.
Can you explain why you think it is a security issue?
In any case, the impact from accidentally triggering this bug seems more
severe.
Anyway, even on a LAN, the overhead of a network round trip per
cacheable DNS query may be non-negligable for some use cases. A local
caching resolver fixes that, too.
Right, and it isolates resolvers from the impact of buggy application
which enter an infinite loop if a service becomes unavailable (i.e.,
they do a new DNS lookup for each refused TCP connection).
--
Florian Weimer / Red Hat Product Security