BIND 9 with views recursion issues

Tue Nov 14 20:26:12 UTC 2006

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.
>
> #####################################################################################