Vulnerable DNS servers, RFC

Florian Weimer fw at deneb.enyo.de
Tue Oct 25 09:24:19 UTC 2005


* Brad Knowles:

> 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.

You wrote about "network security settings", and the surrounding bits
suggested that you were talking about firewalling, and not about BIND
ACL configuration.

>>>  		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,

It may be minimal, but it's still quite significant.

> 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.

But it is, if you use any protocol that implicitly trusts DNS (and who
doesn't?).

>>  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.

I think you are Wrong.  There could be an option to apply the filters
which are applied to zones received over the zone file transfer
protocol to those which are loaded from disk.  This is not strictly
necessary, of course, but BIND can actually help you to do something
about this problem.



More information about the bind-users mailing list