<div dir="ltr">Sending from the correct email alias this time!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 3 Mar 2022 at 09:53, Greg Choules <<a href="mailto:gregchoules@googlemail.com">gregchoules@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Greg.<div>Basically, you can't forward out of authority. If server A is authoritative for "<a href="http://example.com" target="_blank">example.com</a>" it is authoritative for that and everything below that, ad infinitum, unless you tell it otherwise.</div><div>There is an implicit hierarchy as to how queries are dealt with. It arises because BIND can be both recursive AND authoritative simultaneously, so there has to be some way to choose how to go about responding to incoming queries. Using dynamic routeing as an analogy, it's a bit like BGP needing to choose which is the best prefix by running through its decision algorithm.</div><div>In BIND, authority trumps all; there is nothing higher. Next comes forwarding.</div><div><br></div><div>BIND isn't the only DNS server software that does this, by the way. Microsoft's AD DNS role does too because it can be both recursive and authoritative simultaneously.</div><div><br></div><div>As already mentioned, the trick (if this is really what you need to do in the first place) is to 'give away' the slice of your namespace that you want to forward. i.e. to convince the server it is not authoritative for it anymore. Hence you need to delegate (say) "<a href="http://notmine.example.com" target="_blank">notmine.example.com</a>" by adding some (or even one) NS records for it in "<a href="http://example.com" target="_blank">example.com</a>". The slight headspin is, it doesn't matter what those NS records are because they will never be used. It is the act of delegation that is the important thing, not where it is delegated to.</div><div><br></div><div>What I used to do was add (e.g.) "notmine NS x." and then create the forward zone (or in MS speak, Conditional Forwarder). As long as, having created the delegation, the only choice the server now has is to forward that name, life is good. Therefore you MUST also have "forward only". The server must not be allowed to try and recurse, or it would then need to resolve "x.", which will fail.</div><div><br></div><div>However, having said all this, if you know what are the names and addresses of the MS DNS server hosting "ab.somedomain.local" (i'll keep it zipped on the use of .local - Microsoft!), why not just delegate to them directly? Then you don't need a forward zone at all. I have found from bitter experience that forwarding, although (usually) easy to get working can lead you into a warren of problems down the line. So I tended to avoid it wherever possible.</div><div><br></div><div>I hope that helps.</div><div>Greg</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 1 Mar 2022 at 18:53, Gregory Sloop <<a href="mailto:gregs@sloop.net" target="_blank">gregs@sloop.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><p>>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</p><p> </p><p>Yup, exactly.</p><p> </p><p>That solution was suggested by Jeff Sumner yesterday, but it seemed a little nuts to me (BIND behaving that way) - though your explanation makes that behavior seem less crazy.</p><p>If I get a chance, I'll perhaps try that, just to see if it fixes it - though someone at ISC might save me the work, confirming the behavior. (please do!)</p><p> </p><p>And, if that's the case, then static-sub is the far superior option - since it's much more simple and straight-forward.</p><p> </p><p>Consider it solved. </p><p>If ISC can confirm that behavior for forwarding a child domain when the server is also auth for the parent zone, that would be very nice!</p><p> </p><p>Thanks to everyone, again, for the help!</p><p> </p><p> <br>
</p><p><br></p><p></p><blockquote><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 class="gmail_attr" dir="ltr">On Tue, Mar 1, 2022, 1:18 PM Gregory Sloop <<a href="mailto:gregs@sloop.net" target="_blank">gregs@sloop.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>Is static-stub something you are looking for?<br>
</blockquote><p><br></p><blockquote>Reference documentation:<br>
<a href="https://bind9.readthedocs.io/en/v9_18_0/reference.html?highlight=static-stub#zone-types" rel="noreferrer" target="_blank">https://bind9.readthedocs.io/en/v9_18_0/reference.html?highlight=static-stub#zone-types</a><br>
</blockquote><p><br></p><blockquote>And in human terms:<br>
<a href="https://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/" rel="noreferrer" target="_blank">https://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/</a><br>
</blockquote><p><br></p><blockquote>Ondrej<br>
--<br>
Ondřej Surý (He/Him)<br>
<a href="mailto:ondrej@isc.org" rel="noreferrer" target="_blank">ondrej@isc.org</a><br>
</blockquote><p><br></p><blockquote>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><blockquote>On 28. 2. 2022, at 21:47, Gregory Sloop <<a href="mailto:gregs@sloop.net" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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" rel="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" 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" rel="noreferrer" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></blockquote><p><br></p><p></p><div><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" rel="noreferrer" target="_blank">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>
</blockquote><br>
<div>-- <br>
Gregory Sloop, Principal: Sloop Network & Computer Consulting<br>
Voice: 503.251.0452 x121<br>
EMail: <a href="mailto:gregs@sloop.net" target="_blank">gregs@sloop.net</a><br>
<a href="http://www.sloop.net" target="_blank">http://www.sloop.net</a><br>
---<br>
</div></div>-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="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" 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">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>
</blockquote></div>