forwarder is ignored when authoritative zone is added - comp.protocols.dns.bind

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
comp.protocols.dns.bind
Message from discussion forwarder is ignored when authoritative zone is added
Path: 6ni30210pbd.1!nntp.google.com!news.glorb.com!usenet.stanford.edu!not-for-mail
From: Sten Carlsen <st...@s-carlsen.dk>
Newsgroups: comp.protocols.dns.bind
Subject: Re: forwarder is ignored when authoritative zone is added
Date: Fri, 26 Oct 2012 13:22:07 +0200
Lines: 215
Approved: bind-us...@lists.isc.org
Message-ID: <mailman.524.1351250544.11945.bind-users@lists.isc.org>
References: <CADzB970O1MCLNAdPLroiJVhMoTGkFpwRoCHReRA6AY4NQAvBZQ@mail.gmail.com>
	<CAJga8ZvVxBEF39q=yuoy8j1RiXBjpbn8FC360eCtYx2swGtQnw@mail.gmail.com>
NNTP-Posting-Host: lists.isc.org
Mime-Version: 1.0
To: bind-us...@lists.isc.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
In-Reply-To: <CAJga8ZvVxBEF39q=yuoy8j1RiXBjpbn8FC360eCtYx2swGtQnw@mail.gmail.com>
Precedence: list
Content-Type: multipart/alternative;
	boundary="------------020401010303030608050600"

This is a multi-part message in MIME format.
--------------020401010303030608050600
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


On 26/10/12 12:56, Ben Croswell wrote:
>
> 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.
> I assume the logic is, why would I forward a subdomain I know doesn't
> exist.
>
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.
>
> -Ben Croswell
>
> On Oct 26, 2012 2:17 AM, "Frank Even" <lists+isc....@elitists.org
> <mailto:lists%2Bisc....@elitists.org>> wrote:
>
>     I've recently had an issue that I'm having some issues finding
>     information on solving.
>
>     I have internal DNS resolvers...they act as recursive name servers for
>     general internet queries, but we have forwarders explicitly defined
>     for specific internal zones being served by other name servers.
>
>     My configuration has one particular zone configured as such:
>
>     zone "internal.organization.com
>     <http://internal.organization.com>" IN { type forward; forward only;
>     forwarders {172.x.x.x; 172.x.x.x; }; };
>
>     I have our main zone, organization.com <http://organization.com>,
>     hosted in an external area
>     outside of a firewall with a wildcard record contained in it for
>     anything that is not explicitly defined.  I have some services that I
>     need to reach using names that are in this external zone internally.
>     What I'm trying to do is to slave the organization.com
>     <http://organization.com> zone to my
>     internal recursive resolver to mitigate any possible network issues.
>
>     So I setup the internal resolver as a slave for the
>     "organization.com <http://organization.com>"
>     zone and found that queries against "internal.organization.com
>     <http://internal.organization.com>" were
>     getting answered with the wildcard for the external
>     "organization.com <http://organization.com>"
>     zone.  I can't seem to figure out why the forwarders are getting
>     ignored.  Is it an order of precedence, say authoritative zones are
>     respected over forwarders...or something else??
>
>     Thanks for any assistance anyone can provide, or point me to some
>     documentation I'm missing,
>     Frank
>     _______________________________________________
>     Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>     unsubscribe from this list
>
>     bind-users mailing list
>     bind-us...@lists.isc.org <mailto:bind-us...@lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-us...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"


--------------020401010303030608050600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<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=yuoy8j1RiXBjpbn8FC360eCtYx2swGt...@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&nbsp; 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=yuoy8j1RiXBjpbn8FC360eCtYx2swGt...@mail.gmail.com"
      type="cite">
      <p>-Ben Croswell </p>
      <div class="gmail_quote">On Oct 26, 2012 2:17 AM, "Frank Even"
        &lt;<a moz-do-not-send="true"
          href="mailto:lists%2Bisc....@elitists.org">lists+isc....@elitists.org</a>&gt;
        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. &nbsp;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. &nbsp;I can't seem to figure out why the forwarders are
          getting<br>
          ignored. &nbsp;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-us...@lists.isc.org">bind-us...@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-us...@lists.isc.org">bind-us...@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>

--------------020401010303030608050600--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
