On May 5, 2009, at 10:11 PM, YAO Jiankang wrote:
thanks for your information.
so we can say that in the current practise, the (validating )
resolvers are not run by local host or machine.
I don't think we can say a lot about current practice, and we
definitely can't say this. There is at least one open-source DNSSEC
validating stub resolver, and I would argue that it's the right
solution. I don't know what percentage of DNSSEC nodes are secured
using a validating stub resolver, nor how many are secured using a
validating cache. The state of the art right now is that the root
zone isn't signed, and most TLDs aren't signed. So I think mostly
people simply are not using DNSSEC in day-to-day practice yet. So we
shouldn't take what is being done now as a guide for what should be
done.
so if we can say if dnssec is not supported by tsig or ipsec, it is
still not safe since the client and the recursive resolver are not
secured ?
A validating cache does provide security against cache poisoning
attacks, which is an important attack vector. However, if you have
not cryptographically secured the connection between the stub resolver
and the validating cache, your only protection against in-path attacks
is whatever controls you have in place to isolate end nodes from each
other and keep routers from being hacked. So I would say that you
don't have a complete security solution if you do not have a secured
link between the client and the validating cache. But you do gain
some benefit from having a validating cache, even if the link to your
stub resolver is not cryptographically secure.
maybe it is less pressing,
but if the security problems occure "in the same LAN", it will be
more serious for the local users than the problem in the global
internet, and impact all the users "in the same LAN".
Yup. This is why I'm inclined to argue that best practice is to
validate on the end node.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
