bind secure architecture.

Kevin Darcy kcd at daimlerchrysler.com
Tue Aug 23 01:54:08 UTC 2005


Yeah, just make sure you use BIND 9.3.0 or later with this setup. As my 
recent findings indicate, earlier versions of BIND appear to have a bug 
wherein they can occasionally "poison" their own caches with NS records 
from the forwarders' responses (which point to external, possibly 
inaccessible nameservers), in the case where you have a CNAME record in 
an "external-only" zone, pointing to a name in a "schizophrenic" (used 
on both the inside and outside) stub zone. E.g. if 
www.example-external.com is a CNAME record pointing to 
www.example-schizo.com, and example-external.com is "external-only" (and 
thus resolved from the inside only via forwarding), and 
example-schizo.com is defined as "type stub" (i.e. used on both the 
inside and outside), and the nameserver happens to have no NS records 
for example-schizo.com at some particular point in time, then a query 
for www.example-external.com will cause the cache to get polluted with 
the *external* version of the example-schizo.com NS records reported by 
the forwarder, which may break the zone temporarily (until the bogus NS 
records time out). BIND 9.3.0 appears to fix this problem, although I 
can't find any specific mention of the bug or the fix in the CHANGES file.

Of course, if for some reason one cannot use 9.3.0 or above, a 
reasonable workaround -- providing one does not mind the wasteful 
zone-transfer traffic -- is to define the zones as "type slave" instead 
of "type stub". I suspect most of us who have been bitten by this bug -- 
all 3 of us :-) -- have probably just changed the stub definitions to 
slave definitions to work around the problem, and that's probably why it 
was never reported clearly as a bug to ISC...

                                                                         
                                                                     - Kevin

P.S. Although I've touched on it above, nothing in my "skeletal example" 
below supports the actual *hosting* of DNS data to the Internet. If you 
wanted to include that, I'd probably divide the config up into 3 
different views: 1) a "resolve_internal" view, which would be limited to 
clients in your internal address range, and allow them to resolve names 
within your internal-root-bounded namespace, 2) a "resolve_external" 
view, which would be limited to your proxy and perhaps a handful of 
other devices in your BGN (Border Gateway Network) and allow them to 
resolve Internet names and internal names under certain enumerated 
domains, and 3) a "hosting" view for serving DNS data to the Internet, 
which would be open to everyone, but would have recursion turned off, so 
no miscreant could use it to resolve names that weren't actually hosted 
authoritatively from that view. Really, though, from a security 
standpoint -- if nothing else -- at that point you should be considering 
splitting up the various nameserver functions among multiple boxes...

Vincent Blondel wrote:

>many thanks, I will try this as soon as possible.
>
>
>  
>
>>Vincent Blondel wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>We are currently using Bind on one FreeBSD 4.10 server. This server is directly used by internal users and internet clients.
>>>
>>>We decided recently to set up a real DMZ in our IT architecture. This is now done and we are already using an http proxy. Time is now
>>>to consider a complete new architecture for our Bind server.
>>>
>>>So I looked on the net for a complete secure and split ( internal , external ) architecture and have found that we coud mix next
>>>features :
>>>
>>>- internal root
>>>- split architecture could be done by the "VIEW" feature in BIND 9.x
>>>
>>>With such an architecture, we could complete configure all internal servers and subdomains for internal services and set up another
>>>configuration ( usual www, smtp, dns ) for specific external services.
>>>This configuration also involves that the internal root server has to forward the request on the net ( via our dmz gateway BIND
>>>Server
>>>)  for all domains we are not serving as SOA ( example google.com ).
>>>
>>>... and this is my specific problem, I don't immagine how I can configure this.
>>>
>>>So can somebody explain me how I can do it and/or eventually give me an example of configuration ???
>>>
>>>      
>>>
>>No, don't try to mix root server with forwarding. Configure an
>>"external" view on your internal nameserver, that forwards to the dmz
>>gateway BIND server. Have the web proxy's address be the only thing that
>>matches that view. If your web proxy is going to be handling internal as
>>well as external HTTP requests, then you may have to define the apex of
>>each domain you use internally as a "type stub". Optionally, if these
>>zones have any subzones, add a "forwarders { };" to inhibit the
>>forwarding of queries for any of their subzones. Basically, you're
>>"overriding" forwarding selectively for those parts of the namespace, in
>>this "external" view, and forcing the queries to be resolved internally.
>>
>>Skeletal example:
>>
>>view "external" {
>>    match-clients { web.proxy.add.ress; };
>>    forwarders { x.x.x.x; };
>>    forward only;
>>
>>    zone "example.com" {
>>       type stub;
>>       file "external/example.com";
>>       masters { y.y.y.y; }; /* my address */
>>       forwarders { };
>>    };
>>};
>>
>>view "internal" {
>>    match-clients { any; };
>>
>>    zone "." {
>>       type master;
>>       file "internal/root";
>>    };
>>
>>    zone "example.com" {
>>       type master;
>>       file "internal/example.com";
>>    };
>>};
>>
>>
>>
>>
>>
>>
>>
>>                                                                  - Kevin
>>
>>
>>
>>
>>    
>>
>
>
>
>
>
>  
>




More information about the bind-users mailing list