Vulnerable DNS servers, RFC

[Brad Knowles]

At 11:24 AM +0200 2005-10-25, Florian Weimer wrote:

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

	ACLs aren't going to help you here.  No amount of wishing or 
praying is going to be able to make a single BIND process serve up 
multiple different configurations on a per-IP address basis.  For 
each BIND process, there is one and only one configuration file, and 
while ACLs can do a lot within that configuration file, they can't do 
what you're saying they can.

	But this has nothing to do with the network security settings at 
your firewall.


	If you want different configurations running on different IP 
addresses, that's not a problem.  Just run different copies of BIND 
with different configuration files and configured to listen to 
different IP addresses.

	Don't let yourself get bogged down in this mistaken believe that 
a single BIND process can do everything you ever wanted.

>>  	There's a certain amount of trust relationship, yes.  But it's
>>  minimal,
>
>  It may be minimal, but it's still quite significant.

	Not necessarily.  For one thing, the authoritative only server 
could use a separate recursive resolver, and not the same one that 
every one else uses -- perhaps a private recursive-only resolver that 
listens only to 127.0.0.1:53.  For another, you should minimize the 
amount of information on the external nameserver in your DMZ, and 
make sure that your internal recursive-only nameserver uses a 
different internal authoritative-only nameserver to serve up data for 
your own zones.

	Neither of these nameservers need necessarily have much of any 
trust relationship between them.


	And just because you don't have this configuration, you shouldn't 
be trying to force everyone else to run with the same broken 
configuration you've got.

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

	Well, ssh doesn't.  I mean, it might connect you to a given IP 
address based on the information from the DNS, but if you've got it 
configured correctly it will be checking crypto keys once it's 
connected, and if the name/ip is the same but the key isn't, then it 
will tell you.

	Do everything to your machines in the DMZ via crypto-aware 
applications like ssh, and potential weaknesses in the DNS should be 
less dangerous.

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

	Excuse me?  Which copy of BIND do you have that magically 
sanitizes everything it reads?  Where is the copy of BIND that has a 
"DWIM" button and knows what you really want as opposed to what you 
told it to do, and does the right thing?

	In authoritative-only mode, BIND does only what *YOU*, the DNS 
Administrator, tell it to do.  If you can't manage your data 
securely, then there is a real possibility that BIND may be serving 
out bogus data.  But there's absolutely nothing that BIND can do to 
fix this problem -- you've got to fix your data management 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.