On Wed, 2011-09-21 at 12:45 +0000, "Jóhann B. Guðmundsson" wrote:
> On 09/21/2011 10:21 AM, Adam Tkac wrote:
> > Another argument for enforcing DNSSEC is that in future (well, I believe
> > :) ) DNS will be used as storage for X.509 certs, SSHFP records and
> > other stuff. If we adopt "leisure" approach (automatic disabling of
> > DNSSEC or ability to "click" somewhere on the applet to disable DNSSEC)
> > then we can end in the same situation as we are currently with X.509
> > certs. Everyone will simply click on "disable DNSSEC" button or, when
> > MITM attack will be in progress, DNSSEC will be automatically disabled.
> > This will degrade DNSSEC benefits.
>
> Beside the obvious design flaws in dnssec and in the long run they only
> solve a part of the problem how can you even consider removing the
> ability for disabling dnssec when implementing and deploying and running
> dnssec increases the complexity times hundred and people and isp's alike
> cant even implement and properly run a simple dns server as it is now?
You probably did not understand the meaning of "removing the ability for
disabling dnssec" in the Adam's e-mail. It is not meant to disable the
ability to not use of dnssec completely but that it should not be
possible to simply click away any failures to verify dnssec for domains
that are marked as that they should be validated by dnssec. Simply if a
domain is marked as dnssec enabled in the parent record then it must
have correct dnssec entries or it should not be accepted. Domains that
are not marked as dnssec enabled (that should be the default for admins
that are unable or unwilling to use dnssec on their domains) are not
affected in any way.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
