Re: Forwarding zone, setup
Sending from the correct email alias this time! On Thu, 3 Mar 2022 at 09:53, Greg Choules 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 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 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
Re: Forwarding zone, setup
>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 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 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
Re: Forwarding zone, setup
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 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 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
>
--
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
Re: Forwarding zone, setup
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 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
Re: Forwarding zone, setup
This got held up in moderation. Let me repost it, from my regular mail client...
> You didn’t share much of your configuration except the one forwarded zone,
> not a lot to go on.
Fair enough. (I guess I thought you could just infer all the needed
information! Oops!)
Let me try Ondrej's static-sub and see if that makes a difference.
As for more detail.
Yeah, it's a recursive resolver, used internally only.
It's also authoritative for the somedomain.local zone.
I simply want(ed) to pass queries for *.ad.somedomain.local to another
server(s), so thought the forwarder setup was the right way to do that.
Sorry for being so lame in not providing enough detail - I think I just figured
I must be doing something terribly wrong and the forwarder setup must be wrong
in some obvious detail I wasn't seeing.
That doesn't appear to be the case, so we'll look again, try static-sub and
then re-group if it doesn't work.
Thanks all!
> But one thing to check, you do have recursion enabled on the server?
> On Mon, Feb 28, 2022 at 6:34 PM Gregory Sloop wrote:
>> Wow. I hate to be the guy who looks the gift horse in the mouth - but that
>> just seems "wrong." :)
>> (Not the answer, but that that would be the way BIND wants it done.)
>>
>> So, now I've got two sets of NS and glue records?
>> Please tell me that's not the way BIND insists you do this!
>>
>> I guess I should try it, but dang.
>> Does anyone know for sure?
>>
>>
>>> Add Delegating NS records:
>>> ab.somedomain.local 3600 NS server1.ab.somedomain.local
>>> .
>>> .
>>> .
>>> And glue records
>>> server1.ab.somedomain.local 3600 A 10.0.0.1
>>> .
>>> .
>>> And see if it works. It’s got something to do with the way the record is
>>> matched (or not) before the forward statement is hit.
>>> J
On Feb 28, 2022, at 3:47 PM, Gregory Sloop 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 NXOMAIN 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
--
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
Re: Forwarding zone, setup
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 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
Re: Forwarding zone, setup
On 3/1/22 5:35 AM, Matus UHLAR - fantomas wrote: you are right, forwarding queries requires recursion. Thank you for the confirmation Matus. :-) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: Forwarding zone, setup
On 2/28/22 1:47 PM, Gregory Sloop wrote: I figured before I beat my head against the wall for too long, I'd ask the real experts! :) On 28.02.22 22:27, Grant Taylor via bind-users wrote: I'm definitely not an expert. I don't even pretend to be one on T.V. But I do wonder what, if any, sort of restrictions you are placing on recursion on your system. It's my (mis)understanding that recursion has some effect on forwarding queries. My limited understanding is recursion is another way of saying if the server should chase the answer for you or not. If it doesn't have it in it's own data (authoritative and / or cache), then it's recursion setting comes into play. If I'm mistaken, please correct me. you are right, forwarding queries requires recursion. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Nothing is fool-proof to a talented fool. -- 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
Re: Forwarding zone, setup
On 2/28/22 1:47 PM, Gregory Sloop wrote: I figured before I beat my head against the wall for too long, I'd ask the real experts! :) I'm definitely not an expert. I don't even pretend to be one on T.V. But I do wonder what, if any, sort of restrictions you are placing on recursion on your system. It's my (mis)understanding that recursion has some effect on forwarding queries. My limited understanding is recursion is another way of saying if the server should chase the answer for you or not. If it doesn't have it in it's own data (authoritative and / or cache), then it's recursion setting comes into play. If I'm mistaken, please correct me. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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
Re: Forwarding zone, setup
You didn’t share much of your configuration except the one forwarded zone,
not a lot to go on.
But one thing to check, you do have recursion enabled on the server?
On Mon, Feb 28, 2022 at 6:34 PM Gregory Sloop wrote:
> Wow. I hate to be the guy who looks the gift horse in the mouth - but that
> just seems "wrong." :)
>
> (Not the answer, but that that would be the way BIND wants it done.)
>
>
>
> So, now I've got two sets of NS and glue records?
>
> Please tell me that's not the way BIND insists you do this!
>
>
>
> I guess I should try it, but dang.
>
> Does anyone know for sure?
>
>
>
>
>
>
> Add Delegating NS records:
>
> ab.somedomain.local 3600 NS server1.ab.somedomain.local
> .
> .
> .
>
>
> And glue records
>
> server1.ab.somedomain.local 3600 A 10.0.0.1
> .
> .
>
>
> And see if it works. It’s got something to do with the way the record is
> matched (or not) before the forward statement is hit.
>
> J
>
> On Feb 28, 2022, at 3:47 PM, Gregory Sloop 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 NXOMAIN 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
>
--
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
Re: Forwarding zone, setup
Wow. I hate to be the guy who looks the gift horse in the mouth - but that just
seems "wrong." :)
(Not the answer, but that that would be the way BIND wants it done.)
So, now I've got two sets of NS and glue records?
Please tell me that's not the way BIND insists you do this!
I guess I should try it, but dang.
Does anyone know for sure?
> Add Delegating NS records:
> ab.somedomain.local 3600 NS server1.ab.somedomain.local
> .
> .
> .
> And glue records
> server1.ab.somedomain.local 3600 A 10.0.0.1
> .
> .
> And see if it works. It’s got something to do with the way the record is
> matched (or not) before the forward statement is hit.
> J
>> On Feb 28, 2022, at 3:47 PM, Gregory Sloop 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 NXOMAIN 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
Re: Forwarding zone, setup
Add Delegating NS records:
ab.somedomain.local 3600 NS server1.ab.somedomain.local
.
.
.
And glue records
server1.ab.somedomain.local 3600 A 10.0.0.1
.
.
And see if it works. It’s got something to do with the way the record is
matched (or not) before the forward statement is hit.
J
> On Feb 28, 2022, at 3:47 PM, Gregory Sloop 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 NXOMAIN 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/
> 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
Re: forwarding zone setup from a BIND slave (without recursion?)
So why doesn’t it work to make your limited server authoritative for the root and only forward the zones you want? Anything that isn’t in a forwarded zone does not exist (except the root itself). On Sat, Apr 17, 2021 at 11:07 PM Marki wrote: > > On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote: > > > My situation is due to a security requirement. We have DNS servers at our > site running BIND that allow recursion, but I’ve been requested to set up > some additional DNS servers for another project that is expected to * > *only** access the data that we’re authoritative for. And of course …. > there’s a chance that it might need to look up one or two external zones. > Essentially, what I really need is a recursive whitelist that doesn’t tell > BIND what clients are allowed to do recursive lookups, but to limit BIND to > only allow recursive lookups on a very small list of allowed domains. > > > > I was trying to set up a forwarding zone to forward queries to our DNS > servers that do allow recursion, but as I discovered (and as was discussed > earlier in the thread), if recursion is not allowed, then forwarding is > also not allowed. I had tried setting the “allow-recursion” field to > “localhost” and setting up a forward zone to forward to 127.0.0.1, but that > didn’t work either. > > Hello, > > So they do _not_ only look up internal/authoritative zones, but external > ones as well. (It's always the exceptions that kill you.) > > I think we have previously established that there is not a good way to do > whitelisting using Bind, see the thread "Authority and forwarding, but not > recursion/iteration". > > If you can live with non-allowed zones returning SERVFAIL (instead of > NXDOMAIN for example), then using a recursive service with a bogus global > forwarder and static stubs pointing to the authoritative/non-recursive > service might do the trick. > > You might also be able to leverage RPZ if there are no complex conditions > associated to your rules (everyone will have the same white/blacklists). > You configure passthrough for the allowed zones and deny the rest. > > Alternatively, there is dnsdist which, while being a load-balancer, could > be considered the swiss army knife of DNS filtering. > > Finally, some firewalls like Fortigates provide a "DNS filter" that lets > you define custom white and blacklists. Palo Altos currently are not able > to whitelist AFAIK. > > Best regards, > > Marki > ___ > Please 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 > ___ Please 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
Re: forwarding zone setup from a BIND slave (without recursion?)
On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote: My situation is due to a security requirement. We have DNS servers at our site running BIND that allow recursion, but I’ve been requested to set up some additional DNS servers for another project that is expected to **only** access the data that we’re authoritative for. And of course …. there’s a chance that it might need to look up one or two external zones. Essentially, what I really need is a recursive whitelist that doesn’t tell BIND what clients are allowed to do recursive lookups, but to limit BIND to only allow recursive lookups on a very small list of allowed domains. I was trying to set up a forwarding zone to forward queries to our DNS servers that do allow recursion, but as I discovered (and as was discussed earlier in the thread), if recursion is not allowed, then forwarding is also not allowed. I had tried setting the “allow-recursion” field to “localhost” and setting up a forward zone to forward to 127.0.0.1, but that didn’t work either. Hello, So they do _not_ only look up internal/authoritative zones, but external ones as well. (It's always the exceptions that kill you.) I think we have previously established that there is not a good way to do whitelisting using Bind, see the thread "Authority and forwarding, but not recursion/iteration". If you can live with non-allowed zones returning SERVFAIL (instead of NXDOMAIN for example), then using a recursive service with a bogus global forwarder and static stubs pointing to the authoritative/non-recursive service might do the trick. You might also be able to leverage RPZ if there are no complex conditions associated to your rules (everyone will have the same white/blacklists). You configure passthrough for the allowed zones and deny the rest. Alternatively, there is dnsdist which, while being a load-balancer, could be considered the swiss army knife of DNS filtering. Finally, some firewalls like Fortigates provide a "DNS filter" that lets you define custom white and blacklists. Palo Altos currently are not able to whitelist AFAIK. Best regards, Marki ___ Please 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
Re: forwarding zone setup from a BIND slave (without recursion?)
I have been banging my head against the wall regarding this very topic and then
found this thread from last week. I’m also looking for a solution to this
problem, and wondered if anyone may have some suggestions (including potential
alternatives).
My situation is due to a security requirement. We have DNS servers at our site
running BIND that allow recursion, but I’ve been requested to set up some
additional DNS servers for another project that is expected to *only* access
the data that we’re authoritative for. And of course …. there’s a chance that
it might need to look up one or two external zones. Essentially, what I really
need is a recursive whitelist that doesn’t tell BIND what clients are allowed
to do recursive lookups, but to limit BIND to only allow recursive lookups on a
very small list of allowed domains.
I was trying to set up a forwarding zone to forward queries to our DNS servers
that do allow recursion, but as I discovered (and as was discussed earlier in
the thread), if recursion is not allowed, then forwarding is also not allowed.
I had tried setting the “allow-recursion” field to “localhost” and setting up a
forward zone to forward to 127.0.0.1, but that didn’t work either.
Is there any potential workaround for this, or do I just need to tell the
person who requested this that they can only get all or nothing for recursive
queries? We’re still running BIND 9.11, but I was wondering if there may be
new features in BIND 9.16 or 17 that I’m not aware of.
Thanks,
Brian
--
Brian Sebby (he/him/his) | Lead Systems Engineer
Email: se...@anl.gov<mailto:se...@anl.gov> | Information Technology
Infrastructure
Phone: +1 630.252.9935| Business Information Services
Cell: +1 630.921.4305| Argonne National Laboratory
From: bind-users on behalf of RK K
Date: Wednesday, April 7, 2021 at 7:40 PM
To: "bind-users@lists.isc.org"
Subject: Re: forwarding zone setup from a BIND slave (without recursion?)
Hello Marki, Matus,
Thank you for the insights on this topic.
Answering Marki's question about why the secondary-authoritative (slaves) are
used for lookups is some-what history and there was no need to be recursive
(until now) as all the queries are authoritatively answered or refused. May be
security is another reason.
Much appreciated your ideas
Thank you
Kind Regards
RK
On Wed, Apr 7, 2021 at 8:01 AM
mailto:bind-users-requ...@lists.isc.org>>
wrote:
Send bind-users mailing list submissions to
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org<mailto:bind-users-requ...@lists.isc.org>
You can reach the person managing the list at
bind-users-ow...@lists.isc.org<mailto:bind-users-ow...@lists.isc.org>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."
Today's Topics:
1. forwarding zone setup from a BIND slave (without recursion?)
(RK K)
2. Re: forwarding zone setup from a BIND slave (without
recursion?) (Matus UHLAR - fantomas)
3. Re: forwarding zone setup from a BIND slave (without
recursion?) (Marki)
--
Message: 1
Date: Tue, 6 Apr 2021 22:47:23 -0400
From: RK K mailto:rvk...@gmail.com>>
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: forwarding zone setup from a BIND slave (without recursion?)
Message-ID:
mailto:caotbjrubejlxc6-uff5kgkd_ignoytg_ku2pkdxbhpovyzs...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"
All,
We have a set of BIND primary servers (MASTERs) and a set of secondary
servers (slaves to the MASTERs).
The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *)
in the global options.
All the applications/systems do use secondary DNS servers for name
resolution.
Now there is a need to configure a forwarding zone in the "secondary DNS
servers" to an external DNS server.
In this scenario, in-order for the secondary server to forward the DNS
query to an external DNS server, is it required to enable the recursion in
the global options on the secondary servers?
Based on reference material, I did not see such a requirement. But my
observation is the query is not getting forwarded ( tried to check using
the packet trace)
When recursion is enabled, the query is getting forwarded.
The BIND version I am using is 9.11.2.x.
Appreciate your ideas and help.
Thank you
Kind Regards,
Ravi Kota
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/bind-users/attachments/20210406/15bb6cad/attachment-0001.ht
Re: forwarding zone setup from a BIND slave (without recursion?)
Mark Andrews wrote: > > On 8 Apr 2021, at 00:37, Tony Finch wrote: > > > > Forward zones require the upstream server to be recursive too. > > More correctly, the upstream server has to serve the entire namespace being > forwarded if it does not off recursion to the client for forwarding to > work. I thought forwarding expected the target server to resolve CNAMEs? If so, any out-of-zone CNAMEs in the target namespace would cause problems. Tony. -- f.anthony.n.finchhttps://dotat.at/ Cape Wrath to Rattray Head including Orkney: Southwesterly 6 to gale 8, occasionally 5 at first in east, then veering westerly or northwesterly 7 to severe gale 9 later. Moderate or rough, becoming very rough or high in north. Rain at times, squally snow showers later. Moderate or good, occasionally very poor later. ___ Please 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
Re: forwarding zone setup from a BIND slave (without recursion?)
Chuck, Tony, Thank you all for sharing the ideas.. very much appreciated. Thank you Kind Regards, Ravi Kota On Wed, Apr 7, 2021 at 7:25 PM wrote: > Send bind-users mailing list submissions to > bind-users@lists.isc.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.isc.org/mailman/listinfo/bind-users > or, via email, send a message with subject or body 'help' to > bind-users-requ...@lists.isc.org > > You can reach the person managing the list at > bind-users-ow...@lists.isc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bind-users digest..." > > > Today's Topics: > >1. Re: forwarding zone setup from a BIND slave (without > recursion?) (Chuck Aurora) >2. Re: forwarding zone setup from a BIND slave (without > recursion?) (Tony Finch) >3. Re: rndc stops listening (John Thurston) >4. Re: rndc stops listening (Ond?ej Sur?) >5. Re: forwarding zone setup from a BIND slave (without > recursion?) (Mark Andrews) > > > -- > > Message: 1 > Date: Wed, 07 Apr 2021 07:53:01 -0500 > From: Chuck Aurora > To: bind-users@lists.isc.org > Subject: Re: forwarding zone setup from a BIND slave (without > recursion?) > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 2021-04-07 03:59, Marki wrote: > > To elaborate a little bit on that... Indeed that is how it works, > > unfortunately. When you start using forwarders or stubs, recursion > > needs to be enabled because you're no longer looking for your own > > authoritative data only. > > A stub or static-stub zone would not require recursion. In that case > named is asking for authoritative data from upstream. But type > forward zones indeed cannot work if recursion is disabled. > > > What I've learned from this list is that you should split > > authoritative and recursive service. > > I would suggest that as a general best practice, but not an absolute > one. There's nothing wrong with having internal-only authoritative > zones on your recursive resolver. The potential problem comes when > you're a globally-published NS for your zones; having recursion > enabled can make you vulnerable to more possible attacks. > > I'd say it depends more who/what you are. Small-timers are not at so > much risk for this than large sites and ISPs. But there too, the > paranoid would go for two instances of named, authoritative and > recursive, on a small hosted server even where it's only offering > recursion to itself. > > > May I ask what is the reasoning behind your current setup (pointing > > your users to the non-recursive service)? What would you like to > > achieve? What would you like to prevent? > > Agreed, that is strange. It does not seem that an authoritative-only > named can be very useful for end users. > > > -- > > Message: 2 > Date: Wed, 7 Apr 2021 15:37:33 +0100 > From: Tony Finch > To: Chuck Aurora > Cc: bind-users@lists.isc.org > Subject: Re: forwarding zone setup from a BIND slave (without > recursion?) > Message-ID: > Content-Type: text/plain; charset=US-ASCII > > Chuck Aurora wrote: > > > > A stub or static-stub zone would not require recursion. In that case > > named is asking for authoritative data from upstream. But type > > forward zones indeed cannot work if recursion is disabled. > > Be careful in this kind of situation to be very clear about which client > or server is doing what: in this case, it isn't clear what doesn't require > recursion for stub or static stub. > > All three types of zone configuration (stub, static stub, and forward) > are only useful on a server that is providing recursive service. > > Forward zones require the upstream server to be recursive too. > > Stub and static-stub expect the upstream server to be authoritative; > the stub server list is a hint that gets replaced by the authoritative > server list from the zone (a bit like the root hints) whereas static-stub > only uses the configured upstream servers. > > > > What I've learned from this list is that you should split > > > authoritative and recursive service. > > > > I would suggest that as a general best practice, but not an absolute > > one. There's nothing wrong with having internal-only authoritative > > zones on your recursive resolver. The potential problem comes when > > you're a globally-published NS for your zones; having recursion > > enabled can make you vulnera
Re: forwarding zone setup from a BIND slave (without recursion?)
Hello Marki, Matus, Thank you for the insights on this topic. Answering Marki's question about why the secondary-authoritative (slaves) are used for lookups is some-what history and there was no need to be recursive (until now) as all the queries are authoritatively answered or refused. May be security is another reason. Much appreciated your ideas Thank you Kind Regards RK On Wed, Apr 7, 2021 at 8:01 AM wrote: > Send bind-users mailing list submissions to > bind-users@lists.isc.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.isc.org/mailman/listinfo/bind-users > or, via email, send a message with subject or body 'help' to > bind-users-requ...@lists.isc.org > > You can reach the person managing the list at > bind-users-ow...@lists.isc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bind-users digest..." > > > Today's Topics: > >1. forwarding zone setup from a BIND slave (without recursion?) > (RK K) >2. Re: forwarding zone setup from a BIND slave (without > recursion?) (Matus UHLAR - fantomas) >3. Re: forwarding zone setup from a BIND slave (without > recursion?) (Marki) > > > -- > > Message: 1 > Date: Tue, 6 Apr 2021 22:47:23 -0400 > From: RK K > To: bind-users@lists.isc.org > Subject: forwarding zone setup from a BIND slave (without recursion?) > Message-ID: > < > caotbjrubejlxc6-uff5kgkd_ignoytg_ku2pkdxbhpovyzs...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > All, > > We have a set of BIND primary servers (MASTERs) and a set of secondary > servers (slaves to the MASTERs). > The secondary BIND DNS servers disabled recursion ( with "*recursion no;" > *) > in the global options. > All the applications/systems do use secondary DNS servers for name > resolution. > > Now there is a need to configure a forwarding zone in the "secondary DNS > servers" to an external DNS server. > > In this scenario, in-order for the secondary server to forward the DNS > query to an external DNS server, is it required to enable the recursion in > the global options on the secondary servers? > Based on reference material, I did not see such a requirement. But my > observation is the query is not getting forwarded ( tried to check using > the packet trace) > When recursion is enabled, the query is getting forwarded. > > The BIND version I am using is 9.11.2.x. > > Appreciate your ideas and help. > > Thank you > Kind Regards, > Ravi Kota > -- next part -- > An HTML attachment was scrubbed... > URL: < > https://lists.isc.org/pipermail/bind-users/attachments/20210406/15bb6cad/attachment-0001.htm > > > > -- > > Message: 2 > Date: Wed, 7 Apr 2021 10:35:12 +0200 > From: Matus UHLAR - fantomas > To: bind-users@lists.isc.org > Subject: Re: forwarding zone setup from a BIND slave (without > recursion?) > Message-ID: <20210407083512.ga19...@fantomas.sk> > Content-Type: text/plain; charset=us-ascii; format=flowed > > On 06.04.21 22:47, RK K wrote: > >We have a set of BIND primary servers (MASTERs) and a set of secondary > >servers (slaves to the MASTERs). > >The secondary BIND DNS servers disabled recursion ( with "*recursion no;" > *) > >in the global options. > >All the applications/systems do use secondary DNS servers for name > >resolution. > > > >Now there is a need to configure a forwarding zone in the "secondary DNS > >servers" to an external DNS server. > > > >In this scenario, in-order for the secondary server to forward the DNS > >query to an external DNS server, is it required to enable the recursion in > >the global options on the secondary servers? > > yes. > > >Based on reference material, I did not see such a requirement. But my > >observation is the query is not getting forwarded ( tried to check using > >the packet trace) > >When recursion is enabled, the query is getting forwarded. > > > >The BIND version I am using is 9.11.2.x. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > It's now safe to throw off your computer. > > > -- > > Message: 3 > Date: Wed, 7 Apr 2021 10:59:30 +0200 > From: Marki > To: bind-users@lists.isc.org > Subj
Re: forwarding zone setup from a BIND slave (without recursion?)
> On 8 Apr 2021, at 00:37, Tony Finch wrote: > > Chuck Aurora wrote: >> >> A stub or static-stub zone would not require recursion. In that case >> named is asking for authoritative data from upstream. But type >> forward zones indeed cannot work if recursion is disabled. > > Be careful in this kind of situation to be very clear about which client > or server is doing what: in this case, it isn't clear what doesn't require > recursion for stub or static stub. > > All three types of zone configuration (stub, static stub, and forward) > are only useful on a server that is providing recursive service. > > Forward zones require the upstream server to be recursive too. More correctly, the upstream server has to serve the entire namespace being forwarded if it does not off recursion to the client for forwarding to work. > Stub and static-stub expect the upstream server to be authoritative; > the stub server list is a hint that gets replaced by the authoritative > server list from the zone (a bit like the root hints) whereas static-stub > only uses the configured upstream servers. > >>> What I've learned from this list is that you should split >>> authoritative and recursive service. >> >> I would suggest that as a general best practice, but not an absolute >> one. There's nothing wrong with having internal-only authoritative >> zones on your recursive resolver. The potential problem comes when >> you're a globally-published NS for your zones; having recursion >> enabled can make you vulnerable to more possible attacks. > > Right: the rule is that authoritative servers listed as targets of NS > records should be authoritative-only; it's OK if recursive servers have > authoritative copies of zones: it can make them more resilient to outages, > though it does slightly weird things to DNSSEC validation. > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4, > then southwest 4 to 6 later. Very rough at first in north, otherwise > moderate or rough. Snow showers, then rain for a time later. Good, > occasionally very poor at first. > > ___ > Please 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please 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
Re: forwarding zone setup from a BIND slave (without recursion?)
Chuck Aurora wrote: > > A stub or static-stub zone would not require recursion. In that case > named is asking for authoritative data from upstream. But type > forward zones indeed cannot work if recursion is disabled. Be careful in this kind of situation to be very clear about which client or server is doing what: in this case, it isn't clear what doesn't require recursion for stub or static stub. All three types of zone configuration (stub, static stub, and forward) are only useful on a server that is providing recursive service. Forward zones require the upstream server to be recursive too. Stub and static-stub expect the upstream server to be authoritative; the stub server list is a hint that gets replaced by the authoritative server list from the zone (a bit like the root hints) whereas static-stub only uses the configured upstream servers. > > What I've learned from this list is that you should split > > authoritative and recursive service. > > I would suggest that as a general best practice, but not an absolute > one. There's nothing wrong with having internal-only authoritative > zones on your recursive resolver. The potential problem comes when > you're a globally-published NS for your zones; having recursion > enabled can make you vulnerable to more possible attacks. Right: the rule is that authoritative servers listed as targets of NS records should be authoritative-only; it's OK if recursive servers have authoritative copies of zones: it can make them more resilient to outages, though it does slightly weird things to DNSSEC validation. Tony. -- f.anthony.n.finchhttps://dotat.at/ Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4, then southwest 4 to 6 later. Very rough at first in north, otherwise moderate or rough. Snow showers, then rain for a time later. Good, occasionally very poor at first. ___ Please 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
Re: forwarding zone setup from a BIND slave (without recursion?)
On 2021-04-07 03:59, Marki wrote: To elaborate a little bit on that... Indeed that is how it works, unfortunately. When you start using forwarders or stubs, recursion needs to be enabled because you're no longer looking for your own authoritative data only. A stub or static-stub zone would not require recursion. In that case named is asking for authoritative data from upstream. But type forward zones indeed cannot work if recursion is disabled. What I've learned from this list is that you should split authoritative and recursive service. I would suggest that as a general best practice, but not an absolute one. There's nothing wrong with having internal-only authoritative zones on your recursive resolver. The potential problem comes when you're a globally-published NS for your zones; having recursion enabled can make you vulnerable to more possible attacks. I'd say it depends more who/what you are. Small-timers are not at so much risk for this than large sites and ISPs. But there too, the paranoid would go for two instances of named, authoritative and recursive, on a small hosted server even where it's only offering recursion to itself. May I ask what is the reasoning behind your current setup (pointing your users to the non-recursive service)? What would you like to achieve? What would you like to prevent? Agreed, that is strange. It does not seem that an authoritative-only named can be very useful for end users. ___ Please 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
Re: forwarding zone setup from a BIND slave (without recursion?)
Hello, On 4/7/2021 10:35 AM, Matus UHLAR - fantomas wrote: On 06.04.21 22:47, RK K wrote: In this scenario, in-order for the secondary server to forward the DNS query to an external DNS server, is it required to enable the recursion in the global options on the secondary servers? yes. To elaborate a little bit on that... Indeed that is how it works, unfortunately. When you start using forwarders or stubs, recursion needs to be enabled because you're no longer looking for your own authoritative data only. What I've learned from this list is that you should split authoritative and recursive service. In other words, you need two types of servers: 1) A non-recursive one in the backend containing your authoritative zones only. This can be a hidden master setup, somewhat like what you are using now. 2) The one your users access has recursion enabled, and contains stubs to the authoritative service. Obviously, it can also contain stubs (or forwarders) to anywhere else. At the same time it is performing full recursive service unless you take authority for the root zone. May I ask what is the reasoning behind your current setup (pointing your users to the non-recursive service)? What would you like to achieve? What would you like to prevent? Bye, Marki ___ Please 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
Re: forwarding zone setup from a BIND slave (without recursion?)
On 06.04.21 22:47, RK K wrote: We have a set of BIND primary servers (MASTERs) and a set of secondary servers (slaves to the MASTERs). The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *) in the global options. All the applications/systems do use secondary DNS servers for name resolution. Now there is a need to configure a forwarding zone in the "secondary DNS servers" to an external DNS server. In this scenario, in-order for the secondary server to forward the DNS query to an external DNS server, is it required to enable the recursion in the global options on the secondary servers? yes. Based on reference material, I did not see such a requirement. But my observation is the query is not getting forwarded ( tried to check using the packet trace) When recursion is enabled, the query is getting forwarded. The BIND version I am using is 9.11.2.x. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer. ___ Please 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
