<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 3/28/2013 3:28 PM, Ben-Eliezer, Tal
      (ITS) wrote:<br>
    </div>
    <blockquote
cite="mid:9496BCDD18FE8B49BB984508D9C40CBE0452986F16@EXCNYSM95BABP.nysemail.nyenet"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hello,<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">My organization is evaluating the use of
          split-view DNS in our environment.<o:p></o:p></p>
        <p class="MsoNormal">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.<o:p></o:p></p>
        <p class="MsoNormal">Upon reviewing some of the BIND options,
          “forward first;” caught my eye. Below is the description of
          this feature I found on Zytrax:<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><i>“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.”<o:p></o:p></i></p>
        <p class="MsoNormal"><i><o:p> </o:p></i></p>
        <p class="MsoNormal">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).<o:p></o:p></p>
        <p class="MsoNormal">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.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">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?<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
    </blockquote>
    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).<br>
    <br>
    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.<br>
    <br>
                                                                       
                                                                       
                                                    - Kevin<br>
  </body>
</html>