Reverse DNS RFCs and Recommendations

Mark Andrews marka at isc.org
Wed Nov 6 01:37:21 UTC 2013


In message <527986A2.6010806 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Sander Steffann wrote:
> 
> >> Also remember that this thread is on secure rDNS by the ISP,
> >> which means you can't expect the ISP operate rDNS very securely
> >> even though the ISP operate rest of networking not very securely.
> > 
> > You're linking things together that are completely orthogonal...
> 
> You misunderstand very basic points on why forward and reverse
> DNS checking is useful.
> 
> If an attacker can snoop DHCP reply packet to a victim's CPE, the
> attacker can snoop any packet to a victim's server, which is
> already bad.

The DHCP reply packet is special as is is broadcasted.  The
unicast traffic isn't seen.

> Worse, the attacker can override a connection to the server by
> forging reply packets as if they are returned by the legitimate
> server with correct TCP sequence numbers etc, which is especially
> effective if combined with DOS attack to the legitimate server.
>
> 
> Thus, there is no point to make forward and reverse DNS secure.
> 
> That is, Mark's security model is broken only to introduce
> obscurity with worse security.

This is a about adding a delegation into the DNS securely so only
the machine that the prefix is delegated to and the ISP can update
it.  There are a number of reasons to want to do this securely from
both the ISP side and the customer side regardless of whether you
secure the DNS responses themselves.

> 						Masataka Ohta
> 
> PS
> 
> If the server and its clients share some secret for mutual
> authentication as protection against snooping, there is no
> point to make forward and reverse DNS secure.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org




More information about the NANOG mailing list