Forward First on Master Zone (bypass SOA)
kcd at chrysler.com
Thu Mar 28 21:12:26 UTC 2013
On 3/28/2013 3:28 PM, Ben-Eliezer, Tal (ITS) wrote:
> My organization is evaluating the use of split-view DNS in our
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users