Re: Antwort: Secure Bind DNS server problem

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@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@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@signal-iduna.de
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>--
>>Arthur Stephens
>>Senior Sales Technician
>>Ptera Wireless Internet
>>astephens@ptera.net
>>509-927-Ptera
>>
>>
>>
>>
>
>
>
>


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