[166731] in North American Network Operators' Group
Re: Reverse DNS RFCs and Recommendations
daemon@ATHENA.MIT.EDU (Masataka Ohta)
Wed Nov 6 02:56:01 2013
Date: Wed, 06 Nov 2013 16:55:13 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
To: Mark Andrews <marka@isc.org>
In-Reply-To: <20131106013721.983D799806E@rock.dv.isc.org>
Cc: "nanog@nanog.org list" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>> 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.
Masataka Ohta
