<div dir="auto"><div>Are you loading the parent domain and trying to zone forward a child domain on the same DNS server? I.e. loading somedomain.local and trying to forward ab.somedomain.local<div dir="auto"><br></div><div dir="auto">If so an NS delegation is required in every instance I have done in my environment. The NS doesn't need to be "right" but it needs to exist. I don't know the internal BIND logic for that but I have always taken it as "I load the parent and I know the child doesn't exist because there isn't a delegation to make it exist so why would I forward something that doesn't exist".</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 1, 2022, 1:18 PM Gregory Sloop <<a href="mailto:gregs@sloop.net">gregs@sloop.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><p>Static-sub fixes the issue.</p><p> </p><p>Any idea why static-sub works when forwarder doesn't?</p><p> </p><p>(Again, the server is using recursion. Dig queries return the RA flag, so I know it's actually offering recursion in reality.)</p><p> </p><p>I can live with static-sub just fine, since it works - but I'd really love to understand why forwarder didn't - just so I can avoid getting bitten by it in some other situation.</p><p> </p><p>Thanks Andrej!</p><p>-Greg</p><p> <br>
</p><p><br></p><blockquote class="m_-2366519436659804232rt">Is static-stub something you are looking for?<br>
</blockquote><p><br></p><blockquote class="m_-2366519436659804232rt">Reference documentation:<br>
<a href="https://bind9.readthedocs.io/en/v9_18_0/reference.html?highlight=static-stub#zone-types" target="_blank" rel="noreferrer">https://bind9.readthedocs.io/en/v9_18_0/reference.html?highlight=static-stub#zone-types</a><br>
</blockquote><p><br></p><blockquote class="m_-2366519436659804232rt">And in human terms:<br>
<a href="https://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/" target="_blank" rel="noreferrer">https://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/</a><br>
</blockquote><p><br></p><blockquote class="m_-2366519436659804232rt">Ondrej<br>
--<br>
Ondřej Surý (He/Him)<br>
<a href="mailto:ondrej@isc.org" target="_blank" rel="noreferrer">ondrej@isc.org</a><br>
</blockquote><p><br></p><blockquote class="m_-2366519436659804232rt">My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.<br>
</blockquote><p><br></p><blockquote class="m_-2366519436659804232rt"><blockquote class="m_-2366519436659804232rt">On 28. 2. 2022, at 21:47, Gregory Sloop <<a href="mailto:gregs@sloop.net" target="_blank" rel="noreferrer">gregs@sloop.net</a>> wrote:<br>
<br>
So, I want to forward all queries for <br>
*.ab.somedomain.local to some other internal DNS servers.<br>
(Records in *.ab.somedomain.local actually are our active domain servers)<br>
<br>
(Yes, I know .local is reserved now, but we've been using it a long time and changing would be rather painful. Unless there's some horrible consequences, I think we'll just continue for now. We won't ever use mDNS.)<br>
<br>
zone "ab.somedomain.local" {<br>
type forward;<br>
forward only;<br>
forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };<br>
};<br>
<br>
But this doesn't appear to do what I want.<br>
<br>
If I add the above to my regular BIND servers configuration, it doesn't return results like it's forwarding them. (I get NXDOMAIN for abc.ab.somedomain.local.)<br>
<br>
If I do a dig @<a href="http://10.0.0.1" target="_blank" rel="noreferrer">10.0.0.1</a> abc.ab.somedomain.local from the BIND server, I get a proper result. (force dig to use the AD name servers directly, instead of relying on the forward.)<br>
<br>
(And yes the resolv.conf file has the ip addresses of the main internal BIND servers in it, and those only.)<br>
I've looked and while I think I'm doing it right, I'm not entirely sure.<br>
I figured before I beat my head against the wall for too long, I'd ask the real experts! :)<br>
<br>
<br>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank" rel="noreferrer">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" target="_blank" rel="noreferrer">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank" rel="noreferrer">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank" rel="noreferrer">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></blockquote><p><br></p><p></p><div class="m_-2366519436659804232email-signature"><br>
</div></div>-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank" rel="noreferrer">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div></div></div>