On Mon, Mar 20, 2017 at 05:44:27PM -0400, Steve Crocker wrote:
> > You should bear in mind that homenet is assuming the Internet of maybe
> > five years from now, more so than the Internet of now, although obviously
> > we'd like to get done sooner than that. So you should assume that stub
> > resolvers never, ever do anything so foolish as to trust a recursive
> > resolver to validate for them. And, indeed, as you say, any resolver that
> > doesn�t use the host's resolver configuration to figure out which resolver
> > to talk to isn't going to be able to resolve queries in the .homenet
> > domain.
>
> It is hard to predict how things are going to evolve. The idea that all
> stub resolvers will be validating everything they get is a nice goal, and
> I certainly wouldn�t want to choose a path that precludes that, but I
> think it�s prudent to also design for the present. Assume we�ll be
> somewhere along the path between here and there.
>From a system and software engineering perspective I continue to
be surprised at suggestions that stub resolvers are the *right*
place to do DNSSEC validation. As much as much as this may maximize
security, it is such poor separation of duties that I don't see it
being at all attractive in practice.
FWIW, when adding DANE support to Postfix, it was plainly obvious
that DNSSEC validation belongs in the local resolver, and Postfix
just needs to trust its "AD" bit. The only thing missing from the
traditional libresolv API is some way for the application to specify
the resolver address list from the application (as "127.0.0.1"
and/or "::1"). Some systems have a newer stub API (res_nquery,
...), but this API is not yet sufficiently universal.
Indeed, if it becomes important to be able to locally exclude
various namespaces from DNSSEC, this is far more easily done in a
local "unbound" and the like, than in the stub resolver.
So I am making a bold prediction that the maximally secure validating
stub resolvers are not likely to catch on. The necessary DNS
sophistication belongs squarely in a dedicated separate resolver.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
