A thought regarding the pros and cons of DNSSEC that I don't recall being mentioned.
Was reverse-dns verification introduced in response to a lack of confidence in forward-dns ? This can cause much frustration, especially in smaller environments. If the implementation of DNSSEC allowed us to avoid using reverse-dns then perhaps that could be beneficial to many. nudge On Wed, Feb 29, 2012, at 11:53 AM, Mark Andrews wrote: > > In message <cb725c9f.24ec1%micho...@cisco.com>, michoski writes: > > > Doing DNSSEC verification in 2012 is lopsided the other way. You > > > cannot resolve the names you need sometimes. You're probably not > > > receiving any actual protection from spoofing. > > > > I feel similarly. I do see risk in the non DNSSEC world (thanks to Kaminsky > > and others), but not so common or devastating to justify the cost and > > associated risks of deployment today. I think the right tools (inline > > signing!) will reduce TCO and generally make more folks jump onboard. > > DNSSEC is also a enabling technology. SSH already takes advantage of it. > > The DANE working group of the IETF is defining how to authenticate CERTs > using the DNS associated with a DNS name which is a much more natural way > of doing this than using a CA. > > With DNSSEC it is possible to cryptographically secure SMTP and be able > to > detect m-i-m attacks. DNSSEC protects the MX records (explict or > implict). > This lets you securely know which machine you are supposed to be > connecting > to, by name, and hence which CERTs are valid with STARTTLS given that > name. > > Mark > -- > Mark Andrews, ISC _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
