Sending from the correct email alias this time! On Thu, 3 Mar 2022 at 09:53, Greg Choules <gregchou...@googlemail.com> wrote:
> Hi Greg. > Basically, you can't forward out of authority. If server A is > authoritative for "example.com" it is authoritative for that and > everything below that, ad infinitum, unless you tell it otherwise. > 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. > In BIND, authority trumps all; there is nothing higher. Next comes > forwarding. > > 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. > > 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) "notmine.example.com" by adding > some (or even one) NS records for it in "example.com". 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. > > 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. > > 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. > > I hope that helps. > Greg > > On Tue, 1 Mar 2022 at 18:53, Gregory Sloop <gr...@sloop.net> wrote: > >> >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 >> >> >> >> Yup, exactly. >> >> >> >> 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. >> >> 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!) >> >> >> >> And, if that's the case, then static-sub is the far superior option - >> since it's much more simple and straight-forward. >> >> >> >> Consider it solved. >> >> 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! >> >> >> >> Thanks to everyone, again, for the help! >> >> >> >> >> >> >> 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 >> >> 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". >> >> >> On Tue, Mar 1, 2022, 1:18 PM Gregory Sloop <gr...@sloop.net> wrote: >> >>> Static-sub fixes the issue. >>> >>> >>> >>> Any idea why static-sub works when forwarder doesn't? >>> >>> >>> >>> (Again, the server is using recursion. Dig queries return the RA flag, >>> so I know it's actually offering recursion in reality.) >>> >>> >>> >>> 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. >>> >>> >>> >>> Thanks Andrej! >>> >>> -Greg >>> >>> >>> >>> >>> Is static-stub something you are looking for? >>> >>> >>> Reference documentation: >>> >>> https://bind9.readthedocs.io/en/v9_18_0/reference.html?highlight=static-stub#zone-types >>> >>> >>> And in human terms: >>> https://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/ >>> >>> >>> Ondrej >>> -- >>> Ondřej Surý (He/Him) >>> ond...@isc.org >>> >>> >>> My working hours and your working hours may be different. Please do not >>> feel obligated to reply outside your normal working hours. >>> >>> >>> On 28. 2. 2022, at 21:47, Gregory Sloop <gr...@sloop.net> wrote: >>> >>> So, I want to forward all queries for >>> *.ab.somedomain.local to some other internal DNS servers. >>> (Records in *.ab.somedomain.local actually are our active domain servers) >>> >>> (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.) >>> >>> zone "ab.somedomain.local" { >>> type forward; >>> forward only; >>> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; }; >>> }; >>> >>> But this doesn't appear to do what I want. >>> >>> 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.) >>> >>> If I do a dig @10.0.0.1 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.) >>> >>> (And yes the resolv.conf file has the ip addresses of the main internal >>> BIND servers in it, and those only.) >>> I've looked and while I think I'm doing it right, I'm not entirely sure. >>> I figured before I beat my head against the wall for too long, I'd ask >>> the real experts! :) >>> >>> >>> -- >>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >>> from this list >>> >>> ISC funds the development of this software with paid support >>> subscriptions. Contact us at https://www.isc.org/contact/ for more >>> information. >>> >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> >>> >>> >>> -- >>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >>> from this list >>> >>> ISC funds the development of this software with paid support >>> subscriptions. Contact us at https://www.isc.org/contact/ for more >>> information. >>> >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> >> >> -- >> Gregory Sloop, Principal: Sloop Network & Computer Consulting >> Voice: 503.251.0452 x121 >> EMail: gr...@sloop.net >> http://www.sloop.net >> --- >> -- >> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >> from this list >> >> ISC funds the development of this software with paid support >> subscriptions. Contact us at https://www.isc.org/contact/ for more >> information. >> >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> >
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
