>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! :)
>>>>  

-- 
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

Reply via email to