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