Locus of control? Or that pesky old trust anchor?
Separable issues: where the validation computations are done, and
setting (and updating) the trust anchor. For computation, the
advantage of caching after validation in the (shared) recursive
resolver probably does not keep up with the performance improvements
of (end) hosts. Distributing trust anchors to hosts is another scale
step harder than maintaining them on (shared - validating) recursive
resolvers.
Speaking of the popularity of DHCP, that is all about distributing
current parameters to (end) hosts. If only there were a trustworthy
way to do that. DHCP could do that, except for the key distribution
problem (again). But some sort of key distribution is necessary to
protect the hop from a stub resolver and the recursive resolver also.
My guess is that the solutions for updating (end) host software will
get trustworthy enough to be used for DNSSEC trust anchors, and the
validation will end up in the (end) host. Until the host OS
manufacturers realize this is worth their while, validation in hand-
crafted recursive resolvers can get things started.
John
On 2009Apr23, at 1:37 PM, bmann...@vacation.karoshi.com wrote:
On Thu, Apr 23, 2009 at 12:52:37PM -0400, Edward Lewis wrote:
At 8:43 -0700 4/23/09, David Conrad wrote:
root servers). However the point is that you need to do the
validation
someplace you can talk securely to. The easiest answer is to
simply do the
validation on the same host.
I figure stub resolvers were needed when cpu/bandwidth/memory were
a bit
more expensive than now. It seems a shame to constrain our
architecture
to the '80s...
OTOH, for the one of the same reasons DHCP is so popular, that is
centralized local management, it is desirable (in some instances) to
have the validation done in the commons and not in end hosts.
locus of control.
i happen to agree w/ David here. there really is no serious
technical
hurdle for moving a full-bore DNS IMR into most platforms these days
(modulo the RFIDs and some of the IoT stuff).
the upsides are huge for mobility, ad-hoc, and temporally
disconnected
networks.
the downsides are the LEOS (protecting our security), and the
Shylocks
who need to collect what remains of the lunch money.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
