<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFCC" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 26/10/12 12:56, Ben Croswell wrote:<br>
    </div>
    <blockquote
cite="mid:CAJga8ZvVxBEF39q=yuoy8j1RiXBjpbn8FC360eCtYx2swGtQnw@mail.gmail.com"
      type="cite">
      <p>The one thing I can think of off the top of my head is to
        ensure the child subdomain is properly delegated in the parent.
        If you try to zone level forward a child domain on a server that
        loads the parent it will ignore the forward if  it can see the
        child doesn't exist as a true delegation.<br>
        I assume the logic is, why would I forward a subdomain I know
        doesn't exist.</p>
    </blockquote>
    I should think that internal.org... is properly delegated, so the
    forward will not be concerned about a subdomain, only about the
    domain, that is actually forwarded. internal.org... will then be
    looked up in the normal recursive way, so another forward statement
    might solve this issue.<br>
    <blockquote
cite="mid:CAJga8ZvVxBEF39q=yuoy8j1RiXBjpbn8FC360eCtYx2swGtQnw@mail.gmail.com"
      type="cite">
      <p>-Ben Croswell </p>
      <div class="gmail_quote">On Oct 26, 2012 2:17 AM, "Frank Even"
        <<a moz-do-not-send="true"
          href="mailto:lists%2Bisc.org@elitists.org">lists+isc.org@elitists.org</a>>
        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          I've recently had an issue that I'm having some issues finding<br>
          information on solving.<br>
          <br>
          I have internal DNS resolvers...they act as recursive name
          servers for<br>
          general internet queries, but we have forwarders explicitly
          defined<br>
          for specific internal zones being served by other name
          servers.<br>
          <br>
          My configuration has one particular zone configured as such:<br>
          <br>
          zone "<a moz-do-not-send="true"
            href="http://internal.organization.com" target="_blank">internal.organization.com</a>"
          IN { type forward; forward only;<br>
          forwarders {172.x.x.x; 172.x.x.x; }; };<br>
          <br>
          I have our main zone, <a moz-do-not-send="true"
            href="http://organization.com" target="_blank">organization.com</a>,
          hosted in an external area<br>
          outside of a firewall with a wildcard record contained in it
          for<br>
          anything that is not explicitly defined.  I have some services
          that I<br>
          need to reach using names that are in this external zone
          internally.<br>
          What I'm trying to do is to slave the <a
            moz-do-not-send="true" href="http://organization.com"
            target="_blank">organization.com</a> zone to my<br>
          internal recursive resolver to mitigate any possible network
          issues.<br>
          <br>
          So I setup the internal resolver as a slave for the "<a
            moz-do-not-send="true" href="http://organization.com"
            target="_blank">organization.com</a>"<br>
          zone and found that queries against "<a moz-do-not-send="true"
            href="http://internal.organization.com" target="_blank">internal.organization.com</a>"
          were<br>
          getting answered with the wildcard for the external "<a
            moz-do-not-send="true" href="http://organization.com"
            target="_blank">organization.com</a>"<br>
          zone.  I can't seem to figure out why the forwarders are
          getting<br>
          ignored.  Is it an order of precedence, say authoritative
          zones are<br>
          respected over forwarders...or something else??<br>
          <br>
          Thanks for any assistance anyone can provide, or point me to
          some<br>
          documentation I'm missing,<br>
          Frank<br>
          _______________________________________________<br>
          Please visit <a moz-do-not-send="true"
            href="https://lists.isc.org/mailman/listinfo/bind-users"
            target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>
          to unsubscribe from this list<br>
          <br>
          bind-users mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
          <a moz-do-not-send="true"
            href="https://lists.isc.org/mailman/listinfo/bind-users"
            target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list

bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
</pre>
  </body>
</html>