acl misunderstanding?

[Kevin Darcy]

Mipam wrote:

>On Wed, 4 Aug 2004, Bill Larson wrote:
>
>  
>
>>I'm really not sure what you are trying to accomplish here with the 
>>definition of your root/hints zone, but ...  (It looks like you are 
>>trying to stop people from outside your network from getting the root 
>>servers from your system.  But this won't stop it from serving "as dns 
>>for the whole world".)
>>
>>Take a look at the "Secure BIND Template" at 
>>http://www.cymru.com/Documents/secure-bind-template.html.  I believe 
>>that this will provide you with a very good starting point for 
>>configuring a good name server.
>>
>>On your firewall, be very careful with the configuration.  You may 
>>easily cause problems here that have nothing to do with your DNS 
>>server.  One point that I'm sure someone will tell you about is that 
>>DNS isn't necessarily limited to just UDP, TCP can also be used for DNS 
>>queries.  Trying to limit yourself to only UDP may cause definite 
>>problems.  I would suggest also opening up TCP also.  If you think that 
>>TCP is only used for zone transfers and want to block these, you can 
>>easily set up this blocking in the configuration and the "Secure BIND 
>>Template" explains how.
>>    
>>
>
>Thanks, i've read the template and see now how to stop being a dns for the 
>mass. Indeed, tcp port 53 is also valid but only for zone transfers but 
>not for queueries (or isnt this true??).
>
Nameservers should accept TCP queries.

>A second question would be: suppose i wish another server only as caching 
>nameserver for internal clients. I could only allow my internal network 
>for queueries. However, wouldnt it be more logical to only listen on 
>127.0.0.1 and ip_internal_nic so that named doesnt even listen on the 
>outside interface?
>
The template assumes you're going to serve DNS authoritatively to the 
Internet as well as recursively resolve Internet queries for internal 
clients. If you want _only_ to resolve DNS for your internal clients 
then, yeah, it makes perfect sense to only listen on the relevant 
network interfaces.

>Third question is: I noticed that in bind 9 named-xfer is gone.
>I guess i have to use dig instead? The thing is that i was able to specify 
>the serial in named-xfer. The advantage of this was that "If the SOA RR we 
>get from the primary server does not have a serial number higher than 
>this, the transfer will be aborted."
>Since dig doesnt have such a functionality a transfer is always done .. 
>:-(
>
If you're running named-xfer manually, why bother specifying a serial 
number? You can always interrupt (using ctrl-C or whatever your 
interrupt character is) if you don't want to watch the whole zone scroll 
by. Same with dig. If you're talking about the serial-number checks 
and/or zone transfers which are kicked off *automatically* by named, 
then again you don't need to worry about serial numbers since named will 
take care of the management of that for you (and will never transfer a 
zone if it thinks it already has an up-to-date version of that zone). So 
I guess I'm having trouble understanding why you think dig needs a 
"transfer zone only if serial number is less than X" feature. If this is 
for some sort of automated process and bandwidth is your concern, then 
perhaps your automated process should do the serial-number checking 
part, in order to avoid unnecessary transfers. Or, alternatively, use 
IXFR instead of AXFR, which is supported by both named and dig in modern 
versions of BIND.

- Kevin