On 3/28/2013 3:28 PM, Ben-Eliezer, Tal (ITS) wrote:
Hello,
My organization is evaluating the use of split-view DNS in our
environment.
One of the challenges I've yet to overcome in my trials, is the
ability to minimize the administrative overhead of maintaining two
copies of the zone.
Upon reviewing some of the BIND options, "forward first;" caught my
eye. Below is the description of this feature I found on Zytrax:
/"forward is only relevant in conjunction with a valid forwarders
statement. If set to 'only' the server will only forward queries, if
set to 'first' (default) it will send the queries to the forwarder and
if not answered will attempt to answer the query. This statement may
be used in a zone, view or a global options clause."/
//
If I understand this correctly, BIND should handle a query for
host.example.com by first passing it through the configured forwarder,
which should succeed (the record exists on the Internet).
However, I believe since this server is also authoritative for this
domain (the internal copy), and the record is not in this "view" of
the zone file, I receive an NXDOMAIN.
I've spent hours researching a way to accomplish this without any
luck. Is there any way to accomplish what I'm trying to do?
The forward-first/forward-only distinction doesn't help you here: as
already mentioned, if a BIND instance is authoritative for a zone, it
will never forward for it. "Forward first" only allows named to try
iterative resolution if it gets *no*response* from any of its forwarders
-- it has no bearing whatsoever on how it answers from authoritative
data. You need to bite the bullet and set up your maintenance processes
to duplicate the entries of the external-facing version of the zone into
the internal version, if they don't already exist there with different
values (aka "schizophrenic" DNS).
People that still manually update zone files have had some success with
$INCLUDE'ing the common entries into both versions of the zone. But,
always remember that BIND sees them as separate zones, so you need to be
careful about incrementing the serial numbers of *both* zones whenever
the include file changes. Obviously, this technique isn't going to work
with zones that are dynamicaly-updated, or where the zone files are
managed by some sort of maintenance system, unless it can be
tweaked/configured/enhanced to understand $INCLUDE files.
- Kevin
_______________________________________________
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
