[Dnssec-trigger] c-ares + DANE

[Tomas Hozza]

----- Original Message -----
> On 12.6.2014 15:07, Simo Sorce wrote:
> > On Thu, 2014-06-12 at 14:43 +0200, Nikos Mavrogiannopoulos wrote:
> >> On Thu, 2014-06-12 at 14:29 +0200, Petr Spacek wrote:
> >>
> >>> Short answer: "containers"
> >>> Long answer: I certain cases (Docker et al.) we want to have one
> >>> system-wide
> >>> validating resolver running on host and use it from all running docker
> >>> containers.
> >>> It is not desirable to have hundred instances of validating resolver
> >>> (unbound)
> >>> for hundred of containers just because glibc/random other library cannot
> >>> be
> >>> configured to trust AD bits from address different than 127.0.0.1.
> >>
> >> Ok. I've sent the e-mail.
> >>
> >>> Also, dnsmasq and similar crap cannot be reasonably trusted for DNSSEC
> >>> validation even if it is running on 127.0.0.1 so in some cases you may
> >>> want to
> >>> let the list empty.
> >>
> >> Why dnsmasq cannot be trusted for validation? I guess its dnssec
> >> implementation is new, but is there something inherently wrong there?
> 
> Thozza can tell you horribly stories about dnsmasq ...

Well, to make the long story short, dnsmasq used to reuse the client query
packet for the answer, before it implemented DNSSEC. So if the AD bit
was set in the client query, it was also set in the reply, even though
dnsmasq did not do any validation. It just blindly copied all flags
from the query to the answer.

> AFAIK it is light years from being good-enough for any crypto-related
> operation. Also, old versions handled AD bit in a very funky (i.e.
> non-standard and insecure) way.

I would say that it is not well tested enough, not that it is broken.
For example, the 2.69 (2014-04-09) version already supported DNSSEC.
However there were so many issues, that a new version 2.70 (2014-04-24)
was released, which included also some issues that needed to be fixed ASAP
(it segfaulted in some situations, etc.) so the last version was released
2.71 (2014-05-20). The last version seems to be "stable enough" to be
used with DNSSEC.

> Local library cannot know if local resolver is new (hopefully fixed) dnsmasq
> or old one (insecure). That is another reason why local resolver cannot be
> trusted implicitly.

So exactly because of that the administrator should be given the chance to
configure if he trusts the locally running resolver enough to do the DNSSEC
validation and consider its result as trustworthy. The library can not know
which version of dnsmasq is running on the system.

> --
> Petr^2 Spacek
> 

Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com