BIND 9 with views recursion issues

Tue Nov 14 21:00:30 UTC 2006

http://marc.theaimsgroup.com/?l=bind-users&m=111841272927117&w=2

On Tue, 2006-11-14 at 15:26, FredrichManey wrote:
> I dearly love helpful responses like these.
> 
> If you noticed, the statement about bind 9 and views was in quotes. As
> in
> I was quoting someone else's statement - fairly obviously the person
> that
> would be forcing me to go back to bind 8 because "well, it worked in 8
> so therefor the problem must be with 9".
> 
> Now, as to the "helpful" part of your message...
> 
> How exactly would the zone files in the external view of my named
> servers
> having internal data (which they don't, they are currently empty
> placeholders
> for future implementation of a hidden master configuration with the
> public
> nameservers outside the firewall as I stated in my original message) in
> them
> have any impact whatsoever on recursive resolution of third party
> zones?
> 
> I might see where that would be a problem _if_ I was a slave of those
> zones,
> but the only place any of those problem records exist on my servers is
> in
> their cache. I am not doing any sort of a zone transfer for those
> zones. On
> top of that, all of the queries for those problem zones are showing up
> (without
> any errors) in my query logs are being in the _internal_ view, so
> nothing that
> is in the external view zone files is going to matter to those queries
> anyway.
> 
> FWIW, both named-checkconf and named-checkzone are reporting _any_
> errors for my named.conf or for any of my zone files (internal or
> external).
> Nor am I finding _any_ errors, configuration or otherwise, in my logs.
> 
> This problem is turning into a real PITA and it only seems to affect
> BIND 9
> servers (our BIND 8 and Windows DNS servers are working fine). And from
> researching through the archives on groups.google.com I'm am not the
> only
> person experiencing this problem.
> 
> fpsm
> 
> On Nov 14, 2:34 pm, "Jeffrey Reasoner" <jeff.reaso... at mail.hccanet.org>
> wrote:
> > It is absolutely *not* true that Bind 9 doesn't work. It's also not
> > particularly *new*.
> > Your config is broken. Seems like testing prior to putting it into
> > production would have been wise.
> > However, that said, the problem is likely that you are using the same
> > address for your transfers. A your external_dns view zonefiles probably
> > have internal_dns data in them (if they populate at all). However this
> > isn't terribly useful since the addresses aren't publically routable.
> > Change the source IP of the transfers for the external view.
> > Searching the archives of this list will provide examples of what you
> > need.
> >
> >
> >
> > On Tue, 2006-11-14 at 10:31, FredrichManey wrote:
> > > All,
> >
> > > I'm experiencing an extremely frustrating issue involving recursion in
> > > a new BIND 9 installation.
> >
> > > Environment:
> > > 2 new Solaris 9 servers running bind 9.3.2 built from source. They are
> > > configure with two views - internal and external - and are in a dual
> > > master configuration. They are on RFC 1918 addresses behind a NAT
> > > firewall and should only be accessible from the internal network (the
> > > external view is being built with the intention of these machines
> > > becoming 'hidden masters' for the public name servers on the outside of
> > > the firewall).
> >
> > > Problem:
> > > When trying to resolve some specific zones that are not in the cache, I
> > > get server timeouts and non-existent zone responses. This does not
> > > happen for all non-cached zone, but it does happen for all look ups of
> > > the affected zones (tested using dig and nslookup, both locally and
> > > from remote clients).
> >
> > > Here's the relevant parts of my named.conf file:
> >
> > > // BIND Option Statements
> > > options {
> > >    version "You have been logged and reported.";
> > >    // All paths in this file are relative to this directory.
> > >    directory "/named/";
> > >    listen-on port 53 { any; };
> > >    listen-on-v6 { none; };
> > >    pid-file "var/named.pid";
> > >    statistics-file "var/statistics";
> > >    memstatistics-file "var/memstats";
> > >    dump-file "var/named.dump";
> > >    zone-statistics yes;
> > >    auth-nxdomain no;     # conform to RFC1035
> > > };
> >
> > > // Access Control Lists
> > > acl rfc_1918        { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
> > > acl private_dns     { 10.3.8.100; 10.3.8.101; };
> > > acl internal_dns    { 10.3.8.100; 10.3.8.101; };
> > > acl external_dns    { 74.128.1.70; 74.128.1.71; };
> >
> > > // snip logging configuration
> >
> > > // internal view for internal hosts on inside network and dmz
> > > view "internal" {
> > >    // any host that doesn't match here falls through to the external
> > > view
> > >    match-clients { "rfc_1918"; };
> > >    allow-query { "rfc_1918"; };
> > >    allow-recursion { "rfc_1918"; };
> > >    allow-transfer { "internal_dns"; };
> > >    notify-source 10.3.8.100 port 53;
> > >    query-source address 10.3.8.100 port 53;
> > >    transfer-source 10.3.8.100 port 53;
> >
> > >    zone "." {
> > >       type hint;
> > >       file "db/internal/named.root";
> > >    }
> > > // snip internal view master and slave zone configurations;
> > > };
> >
> > > // external view for external hosts and networks on the internet
> > > view "external" {
> > >    // any host that didn't match the internal view above
> > >    match-clients { any; };
> > >    allow-query { any; };
> > >    allow-recursion { none; };   # recursion disabled for external
> > > clients
> > >    allow-transfer { "external_dns"; };
> > >    notify-source 10.3.8.100 port 53;
> > >    query-source address 10.3.8.100 port 53;
> > >    transfer-source 10.3.8.100 port 53;
> >
> > >    zone "." {
> > >       type hint;
> > >       file "db/external/named.root";
> > >    };
> > > // snip external view master and slave zone configurations
> > > };
> >
> > > Any help would be greatly appreciated. This is impacting production and
> > > if I don't get resolved soon I'm going to be forced to go back Bind 8
> > > without views because "bind 9 doesn't work and we are only going there
> > > because it's the new thing".
> >
> > > fpsm#####################################################################################
> >
> > This email has been scanned by MailMarshal, an email content filter.
> >
> > #####################################################################################
> 
> 
#####################################################################################

This email has been scanned by MailMarshal, an email content filter. 

#####################################################################################