Reverse DNS RFCs and Recommendations

Wed Nov 6 08:30:38 UTC 2013

In message <5279F5E1.9030104 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> >> 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.
> 
> What?
> 
> Rfc3315 is explicit on it:
> 
>    18.2.8. Transmission of Reply Messages
> 
>    The Reply message MUST be unicast
>    through the interface on which the original message was received.

While IPv6 is unicast, IPv4 isn't and having a scheme that will work
for IPv4 as well as IPv6 is useful.  Also there is NO GUARANTEE that
the response can't be seen so you design the protocol to work when
it can be seen.

> >> 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.
> 
> And carrying TSIG key in DHCP reply is just secure from the both sides.

Not in the clear it isn't.

> 						Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org