It should be possible to set up an authoritative-only name server so
that it does not recurse for anyone [except perhaps itself], but still
allow someone to get a full resolution of a name whose canonical name is
elsewhere.  IMHBUCO.

I started with this:

view all {
        match-clients { any; };
        allow-query { any; };
        allow-query-cache { any; };     // Only on those RHEL servers
                                        // which allowed it (*sigh*)
        allow-recursion { none; };

        zone "tld.example" {
                type master;

                file "data/zone.tld.example";
        };
};

zone.tld.example:
$TTL    3h
@       SOA     ...
@       NS      ns1.tld.example.
@       NS      ns2.tld.example.
sub     NS      ns1.sub.tld.example.
sub     NS      ns2.sub.tld.example.
ns1     A       ...
ns2     A       ...
ns1.sub A       ...
ns2.sub A       ...
target  CNAME   target.sub


In this case, trying to look up target.tld.example directly from
ns1.tld.example just gets you the CNAMEs but no A record.  Of course, I
says to myself, it is trying to do recursion, which is not allowed.  I
will fix it so that it does not have to do recursion, but to do
forwarding, which is an entirely completely and totally different
operation.  I added to the view:

        zone "sub.tld.example" {
                type "forward";
                forward only;
                forwarders { ns1.sub's IP; ns2.sub's IP; };
        };

Still not working.  Unless I allow recursion!  Which is SUPPOSED to be
an entirely etc.

Any ideas how to have a conceptually correct non-recursive authoritative
name server but still allow it to serve the A records?

Yes, I could have a slaved copy of the zone, but the master copy of the
zone is on an appliance, and one support person was horrified that I
used the GUI they supplied to do something else that BIND can do but
that is not part of the specific value-added software they supply.
(*sigh*)  I'd rather that recursion controls only control recursion.
And not forwarding - have separate forwarding controls, says I.


--
/*********************************************************************\
**
** Joe Yao                              j...@tux.org - Joseph S. D. Yao
**
\*********************************************************************/
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to