<p>The thing that brings me back to a delegation issue is the statement of slaving an external version of the second level domain the internal DNS server. I know if I was splitting a domain I would not put internal only delegations external. </p>
<p>-Ben Croswell </p>
<div class="gmail_quote">On Oct 26, 2012 7:23 AM, "Sten Carlsen" <<a href="mailto:stenc@s-carlsen.dk">stenc@s-carlsen.dk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFCC" text="#000000">
<br>
<div>On 26/10/12 12:56, Ben Croswell wrote:<br>
</div>
<blockquote 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 type="cite">
<p>-Ben Croswell </p>
<div class="gmail_quote">On Oct 26, 2012 2:17 AM, "Frank Even"
<<a href="mailto:lists%2Bisc.org@elitists.org" target="_blank">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 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 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 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 href="http://organization.com" target="_blank">organization.com</a>"<br>
zone and found that queries against "<a href="http://internal.organization.com" target="_blank">internal.organization.com</a>"
were<br>
getting answered with the wildcard for the external "<a 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 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 href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a 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></fieldset>
<br>
<pre>_______________________________________________
Please visit <a 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
bind-users mailing list
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</blockquote>
<br>
<pre cols="72">--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
</pre>
</div>
<br>_______________________________________________<br>
Please visit <a 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 href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br></blockquote></div>