rDNS failed, DNSSEC?

nudge nudgemac at
Wed Feb 29 09:47:28 UTC 2012

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.


On Wed, Feb 29, 2012, at 11:53 AM, Mark Andrews wrote:
> In message <CB725C9F.24EC1%michoski at>, 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

More information about the bind-users mailing list