Antwort: Secure Bind DNS server problem

[Arthur Stephens]

Ok just double checked the order. I guess I was unclear in my presentation.
internal is configured before external view in my config file.
view "internal-in" in {
    // Our internal (trusted) view. We permit the internal networks
    // to freely access this view. We perform recursion for our
    // internal hosts, and retrieve data from the cache for them.

    match-clients { trusted; };
    recursion yes;
    additional-from-auth yes;
    additional-from-cache yes;

    
then...

// Create a view for external DNS clients.
view "external-in" in {
    // Our external (untrusted) view. We permit any client to access
    // portions of this view. We do not perform recursion or cache
    // access for hosts using this view.

    match-clients { any; };
    recursion no;
    additional-from-auth no;
    additional-from-cache no;

My first post has the complete config file at the bottom of the message.

David Botham wrote:

>bind-users-bounce at isc.org wrote on 04/19/2005 02:41:46 PM:
>  
>
>>But I thought that was why we had the external view which below says 
>>    
>>
>"any"
>  
>
>>...snip
>>// Create a view for external DNS clients.
>>    
>>
>
>The view "matching" is ordered.  That is to say, a client will be served 
>out of the first view they match.  With your external view matching "any" 
>before your internal view, no one will ever see your internal view....
>
>
>Dave...
>
>
>  
>
>>view "external-in" in {
>>    // Our external (untrusted) view. We permit any client to access
>>    // portions of this view. We do not perform recursion or cache
>>    // access for hosts using this view.
>>
>>    match-clients { any; };
>>    recursion no;
>>    additional-from-auth no;
>>    additional-from-cache no;
>>
>>... snip
>>
>>whereas the internal view says "trusted"
>>
>>... snip
>>view "internal-in" in {
>>    // Our internal (trusted) view. We permit the internal networks
>>    // to freely access this view. We perform recursion for our
>>    // internal hosts, and retrieve data from the cache for them.
>>
>>    match-clients { trusted; };
>>    recursion yes;
>>    additional-from-auth yes;
>>    additional-from-cache yes;
>>
>>... snip
>>
>>holger.honert at signal-iduna.de wrote:
>>
>>    
>>
>>>Hello Arthur,
>>>your log-file says 
>>>
>>>Apr 18 13:46:11 daffy named[24498]: client 71.4.246.96#32770: query 
>>>'ptera.net/IN' denied
>>>
>>>which is correctly handled due to your statement 
>>>
>>>allow-query {
>>>// Accept queries from our "trusted" ACL. We will
>>>// allow anyone to query our master zones below.
>>>// This prevents us from becoming a free DNS server
>>>// to the masses.
>>>trusted;
>>>};
>>>
>>>... snip
>>>
>>>acl "trusted" {
>>>
>>>
>>>// Place our internal and DMZ subnets in here so that
>>>// intranet and DMZ clients may send DNS queries. This
>>>// also prevents outside hosts from using our name server
>>>// as a resolver for other domains.
>>>216.229.171.0/24;
>>>69.28.32.0/20;
>>>localhost;
>>>};
>>>
>>>... snip
>>>
>>>you are allowing only queries clients listed in your acl.
>>>
>>>Maybe you check this out!
>>>
>>>Kind Regards/Freundlichen Gruß
>>>
>>>Holger Honert
>>>
>>>KOMN-97851
>>>
>>>SIGNAL IDUNA Gruppe
>>>Joseph-Scherer-Str. 3
>>>
>>>44139 Dortmund
>>>
>>>Phone: +49 231/135-4043
>>>FAX: +49 231/135-2959
>>>
>>>mailto: holger.honert at signal-iduna.de
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>-- 
>>Arthur Stephens
>>Senior Sales Technician
>>Ptera Wireless Internet
>>astephens at ptera.net
>>509-927-Ptera
>>
>>
>>    
>>
>
>
>  
>


-- 
Arthur Stephens
Senior Sales Technician
Ptera Wireless Internet
astephens at ptera.net
509-927-Ptera