Vulnerable DNS servers, RFC

[Thomas Schulz]

In article <djkuf5$bl$1 at sf1.isc.org>,
Brad Knowles  <brad at stop.mail-abuse.org> wrote:
>At 11:05 AM +0200 2005-10-25, Florian Weimer wrote:
>
>>>  		1.  If you split the authoritative and recursive
>>>  		functions onto separate machines, then you can make
>>>  		the necessary network security settings so that
>>>  		incoming packets that are not a reply to a recent
>>>  		outgoing packet will be prevented from getting to the
>>>  		recursive server.
>>
>>  This is also possible if recursive and authoritative service runs on
>>  different IP addresses, but are served by the same named process.
>
>	They can't be served by the same process.  Each named process is 
>going to listen to one or more IP addresses (according to your 
>configuration), and is going to either act as a recursive-only 
>server, an authoritative-only server, or as a combined 
>recursive/authoritative server, according to the configuration.

Can't you do this with views?  Could you make one view authoritative-only
and another view recursive?  I know that you can give out different
authoritative data from different views and I thought that I had read
somewhere that views could also differ in whether recursion was allowed
or not.

>	If you want to run two copies of BIND listening to different 
>addresses, then you could have different configurations on them.  But 
>you can't have one copy of BIND listening to multiple IP addresses 
>with different configurations for each IP address.
>
>>>  		2.  If the recursive and authoritative functions are
>>>  		split onto separate machines, then if one should get
>>>  		compromised, then the other should still be reasonably
>>>  		secure.  If you've done your network security
>>>  		correctly, there should be no trust relationship
>>>  		between these machines,
>>
>>  But there is, and you can't avoid it.  The recursive resolver fetches
>>  data from the authoritative server.
>
>	There's a certain amount of trust relationship, yes.  But it's 
>minimal, and doesn't require that you have the same accounts, the 
>same user authentication database, etc....  Just because you've 
>managed to hack root password on one machine should not make the 
>other machine any more vulnerable than it was before.
>
>>>  	Right, but where would you get such unfiltered/untrusted content
>>>  onto your authoritative-only server, unless you caused it to be
>>>  loaded there?
>>
>>  Web-based DNS management with customer access, for example.  I believe
>>  everyone filters out-of-zone records these days, but it's hard to be
>>  sure.
>
>	That's a data management issue, and one you're responsible for 
>resolving.  There's nothing that BIND can do to help you with this 
>problem.
>
>-- 
>Brad Knowles, <brad at stop.mail-abuse.org>
>
>"Those who would give up essential Liberty, to purchase a little
>temporary Safety, deserve neither Liberty nor Safety."
>
>     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
>     Assembly to the Governor, November 11, 1755
>
>   SAGE member since 1995.  See <http://www.sage.org/> for more info.
>
>


-- 
Tom Schulz
schulz at adi.com