The most frustrating part about DNSSEC is that trying to pin down what it is and what it is not, what it is trying to do and what it is not is like trying to nail jello to a wall.
Whenever an issue is raised with the DNSSEC protocol, someone immediately shoots back the reply 'well we are not trying to solve that problem'. Which is of course really easy when there is no clear statement of what real world security issues that DNSSEC is trying to deal with.
Blocking one attack does not come close to justifying the cost of DNSSEC deployment.
Is DLV a part of DNSSEC or not? I am not sure.
DLV is presented as being a stopgap, an interim measure to go away with full DNSSEC deployment.
What I do know is that I want to use secure DNS in devices that are not capable of performing public key cryptography. And even if every end point device is capable of performing RSA2048 operations in acceptable time, I do not want to push my trust management criteria out to my network endpoints.
DNSSEC does not require you to use only ICANN's trust anchor. You can also use your enterprise trust anchor, so you can validate your enterprise DNS independently of any third party.On 28 Sep 2010, at 02:20, Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote:On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch <dot@xxxxxxxx> wrote:
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote:Why not?
>
> DNSSEC is a mechanism for establishing inter-domain trust. It is not an
> appropriate technology for intra-domain trust.
Because the root of trust for any enterprise is the enterprise itself. Not ICANN.(The keyassure work might make this approach to key distribution easier than running an enterprise X.509 CA. DNSSEC also has the advantage of a defined trust anchor rollover protocol.)
You can also use third party trust anchors such as the ISC's DLV.Tony.--
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf