Re: Authority and forwarding, but not recursion/iteration

2021-03-16 Thread Fred Morris

Hammers and nails...

On Tue, 16 Mar 2021, Marki wrote:

On 3/13/2021 12:11 AM, Tony Finch wrote:

 Marki  wrote:

 But if you need granular filtering, that could become a lot of views...

 Yes, I think RPZ is really designed to be a ban hammer [...]


Standard DNS server software (not only Bind)


Is RPZ "standard" now? I know that the US Govt is now calling it "PDNS"...

does not provide for easy 
whitelist filtering, only blacklists seem to be "en vogue".


Not true at all. There are large cesspools of compute which I block by 
default and selectively whitelist into with RPZ.


This requires (and it should be SOP) two local RPZs, a whitelist followed 
by a blacklist. If it's in the whitelist it's shiny otherwise it gets 
filtered by the RPZ dedicated to replicating the coldest regions of 
interstellar space.


The cesspools in particular are handled via CNAME chains. That seems to be 
SOP, too. So images.example.com is a CNAME to random.cesspool-example.com. 
In the second list there is a catchall for *.cesspool-example.com which 
rewrites it all NXDOMAIN. Because I like example.com, I put a rule in the 
first list to leave *.example.com alone. (This does a really good job with 
third party cookies before they even get to the browser.)


In fact, this should be SOP: whenever you use cesspool compute or servers, 
CNAME it from your actual domain m'kay?


Granted there are some people who cleverly use random.cesspool-example.com 
in their dynamically generated pages. So clever. Ooops, not so much. In 
fact, this blocks stuff I never even thought of blocking but am glad I 
did!


There can also be issues with TTLs, where you had something in a compute 
cesspool blocked and then you created an exception for it, and it won't 
resolve until the TTL expires. I solve that locally by disabling local 
cache: all stub resolver queries (getaddrinfo() I'm looking at you!) get 
sent to the local recursive/caching resolver by disabling nscd or 
rewriting TTLs if necessary.


For extra credit you can hunt nameservers, although that's perhaps better 
handled in the mail filtering pipeline, which is where it really seems to 
matter.


--

Fred Morris

___
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: Authority and forwarding, but not recursion/iteration

2021-03-16 Thread Marki

On 3/13/2021 12:11 AM, Tony Finch wrote:

Marki  wrote:

But if you need granular filtering, that could become a lot of views...

Yes, I think RPZ is really designed to be a ban hammer for dealing with
abuse, rather than a general-purpose access control mechanism. If you need
to get really fancy then you should look at dnsdist which can be
programmed in Lua.

Tony.


Just posting this to give everyone my conclusions and how this turned out.

Standard DNS server software (not only Bind) does not provide for easy 
whitelist filtering, only blacklists seem to be "en vogue". Like 
trusting nearly everyone, except, oh well, what did they teach in 
security class? Never mind, we're currently rolling out dnsdist.


@Tony Your feedback has been very to the point, knowledgeable and 
fruitful. If you've got an Amazon wishlist (almost wrote whitelist lol) 
let me know :D

___
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: Authority and forwarding, but not recursion/iteration

2021-03-12 Thread Tony Finch
Marki  wrote:
>
> But if you need granular filtering, that could become a lot of views...

Yes, I think RPZ is really designed to be a ban hammer for dealing with
abuse, rather than a general-purpose access control mechanism. If you need
to get really fancy then you should look at dnsdist which can be
programmed in Lua.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Fitzroy: Westerly 4 to 6 in south, otherwise 7 to severe gale 9. Rough in
south, otherwise very rough or high. Showers, squally in north. Good,
occasionally poor.

___
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: Authority and forwarding, but not recursion/iteration

2021-03-10 Thread Marki

On 3/9/2021 10:21 PM, Tony Finch wrote:

Marki  wrote:

I'm not sure about the flexibility of RPZ; it doesn't seem that I can
have rules like "client 1.2.3.4 is allowed to look up example.com but
client 1.2.3.5 is not".

You can have multiple response-policy zones, which are matched in the
order they are listed in the configuration. You could perhaps have a zone
listed early that uses RPZ-CLIENT-IP triggers and a PASSTHRU policy for
non-sandboxed clients, then have a zone containing QNAME triggers (with
liberal use of wildcards) and PASSTHRU policy (again) for just the
permitted internal names, and finally a catch-all zone (wildcard to match
any qname) with an NXDOMAIN policy to deny external names for sandboxed
clients. (You can equally well combine the first two into a single zone,
depending on whether you want more single-purpose RPZs or fewer
multi-purpose ones.)


Probably the setup would be more straightforward if there was a view for 
sandboxed clients and one or more views for those that are not.


Concerning the non-sandboxed (or less-sandboxed view), I still fail to 
see how RPZ would allow me to define conditionals like "Host 1.2.3.4 is 
allowed to resolve example.com" (and nothing else). AFAICS you can 
either trigger on the client ip and allow (or deny) all names, or 
trigger on the name to be resolved and allow (or deny) for all clients, 
but not a combination thereof. You could create a view that matches 
1.2.3.4 and include an RPZ that allows to use example.com. But if you 
need granular filtering, that could become a lot of views...


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: Authority and forwarding, but not recursion/iteration

2021-03-09 Thread Tony Finch
Marki  wrote:
>
> Concerning static-stub: Using a (bogus) forwarder together with "forward
> first" (default) seems to work (Note: using "forward only" gives SERVFAIL).
> All outside requests get a SERVFAIL even with "forward first" but that's an
> esthetic problem.

Yes, SERVFAIL is ugly - I should have mentioned that.

> I'm not sure about the flexibility of RPZ; it doesn't seem that I can
> have rules like "client 1.2.3.4 is allowed to look up example.com but
> client 1.2.3.5 is not".

You can have multiple response-policy zones, which are matched in the
order they are listed in the configuration. You could perhaps have a zone
listed early that uses RPZ-CLIENT-IP triggers and a PASSTHRU policy for
non-sandboxed clients, then have a zone containing QNAME triggers (with
liberal use of wildcards) and PASSTHRU policy (again) for just the
permitted internal names, and finally a catch-all zone (wildcard to match
any qname) with an NXDOMAIN policy to deny external names for sandboxed
clients. (You can equally well combine the first two into a single zone,
depending on whether you want more single-purpose RPZs or fewer
multi-purpose ones.)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Forties, Cromarty, Forth: South or southeast 5 to 7, increasing gale 8 or
severe gale 9 for a time. Slight or moderate, becoming rough later,
occasionally very rough except in Forth. Rain. Good, becoming moderate or
poor for a time.

___
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: Authority and forwarding, but not recursion/iteration

2021-03-09 Thread Marki

On 3/9/2021 6:03 PM, Tony Finch wrote:

Marki  wrote:

I am seeking a combination of either a combined configuration on one, or a
config of several different DNS servers together to achieve the following:

* Some clients should be able to resolve authoritative local zones as well as
some forwarded zones.

* Other clients should be able to resolve all of that _plus_ be able to make
recursive queries to the internet (or use a global forwarder).

In my opinion, as a rule of thumb it's best to avoid per-zone forwarding
in BIND. (Microsoft DNS really encourages it, but be wary because it
doesn't mean the same thing there!)

It's helpful if you have a clear distinction between authoritative-only
nameservers on the one hand, and on the other hand recursive nameservers
that provide service to stub resolvers. It sounds like you want to provide
an internal-only sandbox to some recursive clients, but it's best to think
of it as a restricted recursive service, not a special kind of
authoritative service. Especially because stub clients expect to receive
fully-resolved answers, so if you point them at an authoritative-only
server you'll get obscure problems in cases like cross-zone CNAMEs.

[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion available). ]

When you need to tie authoritative zones together, use delegation records
pointing at your authoritative-only name servers. Then your recursive
servers can just follow delegations in the usual way without special
configuration. (If you are doing split DNS, this can get fiddly, which is
a good reason for keeping your split DNS as simple as possible.)

[ You can configure recursive servers to have their own authoritative
copies of your zones - it can be faster and more resilient - but you can
think of it as a shortcut or optimization, on top of the fundamental
auth/rec split. ]

Your question is now, how to provide a restricted recursive service?

The top-level setup is to have multiple views with match-clients clauses
to determine whether a client is in the sandbox view or not. Then the
question is how to configure the sandbox view.

I don't know of any particularly good ways in BIND :-) When you want
default-allow with a block list, then RPZ is ideal, but you are asking for
default-deny with an allow list.

You might be able to configure a dummy default forwarder, and tell BIND it
is bogus, something like this (which I have not tested!):

forwarders A.B.C.D;
server A.B.C.D {
bogus yes;
};

then have per-zone static-stub configuration for allowed zones, pointing
at working authoritative servers.

Alternatively it might be easier to make other software such as dnsdist do
what you want. Or, consider implementing the sandbox with firewalls at the
network level. (But are you sandboxing DNS because of worries about
data exfiltration?)

Tony.


You're right about the sandbox and exfiltration (C2 etc.). What can't go 
out, can't hurt. We don't need public DNS resolution on most client 
systems since all Internet access is filtered through an explicit proxy. 
Thus, why not just turn it off instead of trying to protect it using 
expensive appliances and whatnot.


Concerning static-stub: Using a (bogus) forwarder together with "forward 
first" (default) seems to work (Note: using "forward only" gives 
SERVFAIL). All outside requests get a SERVFAIL even with "forward first" 
but that's an esthetic problem. Another approach might be to disable 
forwarders altogether (make it fully recursive) and then use RPZ. This 
would however mean that stubs/forwarded zones would need to be 
whitelisted, which means one or two more lines of configuration (and a 
nice reply from the server).


As you mentioned there would be other view(s) for clients that actually 
need public DNS. Correctly firewalling means blocking everything unless 
it is allowed (whitelisting principle). I'm not sure about the 
flexibility of RPZ; it doesn't seem that I can have rules like "client 
1.2.3.4 is allowed to look up example.com but client 1.2.3.5 is not".


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: Authority and forwarding, but not recursion/iteration

2021-03-09 Thread Tony Finch
Marki  wrote:
>
> I am seeking a combination of either a combined configuration on one, or a
> config of several different DNS servers together to achieve the following:
>
> * Some clients should be able to resolve authoritative local zones as well as
> some forwarded zones.
>
> * Other clients should be able to resolve all of that _plus_ be able to make
> recursive queries to the internet (or use a global forwarder).

In my opinion, as a rule of thumb it's best to avoid per-zone forwarding
in BIND. (Microsoft DNS really encourages it, but be wary because it
doesn't mean the same thing there!)

It's helpful if you have a clear distinction between authoritative-only
nameservers on the one hand, and on the other hand recursive nameservers
that provide service to stub resolvers. It sounds like you want to provide
an internal-only sandbox to some recursive clients, but it's best to think
of it as a restricted recursive service, not a special kind of
authoritative service. Especially because stub clients expect to receive
fully-resolved answers, so if you point them at an authoritative-only
server you'll get obscure problems in cases like cross-zone CNAMEs.

[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion available). ]

When you need to tie authoritative zones together, use delegation records
pointing at your authoritative-only name servers. Then your recursive
servers can just follow delegations in the usual way without special
configuration. (If you are doing split DNS, this can get fiddly, which is
a good reason for keeping your split DNS as simple as possible.)

[ You can configure recursive servers to have their own authoritative
copies of your zones - it can be faster and more resilient - but you can
think of it as a shortcut or optimization, on top of the fundamental
auth/rec split. ]

Your question is now, how to provide a restricted recursive service?

The top-level setup is to have multiple views with match-clients clauses
to determine whether a client is in the sandbox view or not. Then the
question is how to configure the sandbox view.

I don't know of any particularly good ways in BIND :-) When you want
default-allow with a block list, then RPZ is ideal, but you are asking for
default-deny with an allow list.

You might be able to configure a dummy default forwarder, and tell BIND it
is bogus, something like this (which I have not tested!):

forwarders A.B.C.D;
server A.B.C.D {
bogus yes;
};

then have per-zone static-stub configuration for allowed zones, pointing
at working authoritative servers.

Alternatively it might be easier to make other software such as dnsdist do
what you want. Or, consider implementing the sandbox with firewalls at the
network level. (But are you sandboxing DNS because of worries about
data exfiltration?)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Irish Sea: South or southwest 4 to 6, increasing 7 to severe gale 9 for a
time. Slight or moderate, becoming rough or very rough for a time. Rain.
Moderate occasionally poor.

___
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: Authority and forwarding, but not recursion/iteration

2021-03-07 Thread Crist Clark
Where is it sending recursive queries if it owns the root?

On Sun, Mar 7, 2021 at 3:06 AM Marki  wrote:

> I tried that. When you configure no global forwarders it's going to
> recurse because recursion needs to be enabled for the individual forwarded
> zones to work. You'd have to specify a fake global forwarder which looks
> like a hack.
>
>
> On March 7, 2021 10:09:49 AM GMT+01:00, Crist Clark <
> cjc+bind-us...@pumpky.net> wrote:
>>
>> Two views. The view that does not do internet DNS claims authority for
>> the root and does not global forward. The entire DNS is just the zones
>> defined in the view, which can be authoritative or forwarded. The other
>> view has the global forward-only to upstream resolvers.
>>
>> On Sat, Mar 6, 2021 at 3:34 PM Marki  wrote:
>>
>>> I'm not sure:
>>>
>>> > Some clients should be able to resolve authoritative local zones as
>>> well as some forwarded zones.
>>>
>>> And only that. "forward only;" doesn't cut it, in case you mean the
>>> global option. That would still forward everything else somewhere else. The
>>> requirement is to _only_ resolve local stuff for some clients.
>>> On 3/6/2021 8:48 PM, Crist Clark wrote:
>>>
>>> forward only;
>>>
>>> On Fri, Mar 5, 2021 at 5:19 PM Marki  wrote:
>>>
 Hello,

 I am seeking a combination of either a combined configuration on one,
 or
 a config of several different DNS servers together to achieve the
 following:
 * Some clients should be able to resolve authoritative local zones as
 well as some forwarded zones.
 * Other clients should be able to resolve all of that _plus_ be able to
 make recursive queries to the internet (or use a global forwarder).
 All hosts use the same DNS servers, this should not be made about the
 clients but rather be configurable on the server.

 Now the problems are the following:
 * Since I need forwarders I can't turn off recursion.
 * Since I can't turn off recursion I can't prevent it to go and try to
 resolve from root DNS.

 How do I do one (local authority and forwarders) but not the other
 (iterative lookups on the Internet)?

 Thanks,

 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
>>>
>> ___
> 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: Authority and forwarding, but not recursion/iteration

2021-03-07 Thread Marki
I tried that. When you configure no global forwarders it's going to recurse 
because recursion needs to be enabled for the individual forwarded zones to 
work. You'd have to specify a fake global forwarder which looks like a hack.

On March 7, 2021 10:09:49 AM GMT+01:00, Crist Clark  
wrote:
>Two views. The view that does not do internet DNS claims authority for
>the
>root and does not global forward. The entire DNS is just the zones
>defined
>in the view, which can be authoritative or forwarded. The other view
>has
>the global forward-only to upstream resolvers.
>
>On Sat, Mar 6, 2021 at 3:34 PM Marki  wrote:
>
>> I'm not sure:
>>
>> > Some clients should be able to resolve authoritative local zones as
>well
>> as some forwarded zones.
>>
>> And only that. "forward only;" doesn't cut it, in case you mean the
>global
>> option. That would still forward everything else somewhere else. The
>> requirement is to _only_ resolve local stuff for some clients.
>> On 3/6/2021 8:48 PM, Crist Clark wrote:
>>
>> forward only;
>>
>> On Fri, Mar 5, 2021 at 5:19 PM Marki 
>wrote:
>>
>>> Hello,
>>>
>>> I am seeking a combination of either a combined configuration on
>one, or
>>> a config of several different DNS servers together to achieve the
>>> following:
>>> * Some clients should be able to resolve authoritative local zones
>as
>>> well as some forwarded zones.
>>> * Other clients should be able to resolve all of that _plus_ be able
>to
>>> make recursive queries to the internet (or use a global forwarder).
>>> All hosts use the same DNS servers, this should not be made about
>the
>>> clients but rather be configurable on the server.
>>>
>>> Now the problems are the following:
>>> * Since I need forwarders I can't turn off recursion.
>>> * Since I can't turn off recursion I can't prevent it to go and try
>to
>>> resolve from root DNS.
>>>
>>> How do I do one (local authority and forwarders) but not the other
>>> (iterative lookups on the Internet)?
>>>
>>> Thanks,
>>>
>>> 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
>>
___
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: Authority and forwarding, but not recursion/iteration

2021-03-07 Thread Crist Clark
Two views. The view that does not do internet DNS claims authority for the
root and does not global forward. The entire DNS is just the zones defined
in the view, which can be authoritative or forwarded. The other view has
the global forward-only to upstream resolvers.

On Sat, Mar 6, 2021 at 3:34 PM Marki  wrote:

> I'm not sure:
>
> > Some clients should be able to resolve authoritative local zones as well
> as some forwarded zones.
>
> And only that. "forward only;" doesn't cut it, in case you mean the global
> option. That would still forward everything else somewhere else. The
> requirement is to _only_ resolve local stuff for some clients.
> On 3/6/2021 8:48 PM, Crist Clark wrote:
>
> forward only;
>
> On Fri, Mar 5, 2021 at 5:19 PM Marki  wrote:
>
>> Hello,
>>
>> I am seeking a combination of either a combined configuration on one, or
>> a config of several different DNS servers together to achieve the
>> following:
>> * Some clients should be able to resolve authoritative local zones as
>> well as some forwarded zones.
>> * Other clients should be able to resolve all of that _plus_ be able to
>> make recursive queries to the internet (or use a global forwarder).
>> All hosts use the same DNS servers, this should not be made about the
>> clients but rather be configurable on the server.
>>
>> Now the problems are the following:
>> * Since I need forwarders I can't turn off recursion.
>> * Since I can't turn off recursion I can't prevent it to go and try to
>> resolve from root DNS.
>>
>> How do I do one (local authority and forwarders) but not the other
>> (iterative lookups on the Internet)?
>>
>> Thanks,
>>
>> 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
>
___
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: Authority and forwarding, but not recursion/iteration

2021-03-06 Thread Marki

I'm not sure:

> Some clients should be able to resolve authoritative local zones as 
well as some forwarded zones.


And only that. "forward only;" doesn't cut it, in case you mean the 
global option. That would still forward everything else somewhere else. 
The requirement is to _only_ resolve local stuff for some clients.


On 3/6/2021 8:48 PM, Crist Clark wrote:

forward only;

On Fri, Mar 5, 2021 at 5:19 PM Marki > wrote:


Hello,

I am seeking a combination of either a combined configuration on
one, or
a config of several different DNS servers together to achieve the
following:
* Some clients should be able to resolve authoritative local zones as
well as some forwarded zones.
* Other clients should be able to resolve all of that _plus_ be
able to
make recursive queries to the internet (or use a global forwarder).
All hosts use the same DNS servers, this should not be made about the
clients but rather be configurable on the server.

Now the problems are the following:
* Since I need forwarders I can't turn off recursion.
* Since I can't turn off recursion I can't prevent it to go and
try to
resolve from root DNS.

How do I do one (local authority and forwarders) but not the other
(iterative lookups on the Internet)?

Thanks,

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: Authority and forwarding, but not recursion/iteration

2021-03-06 Thread Crist Clark
forward only;

On Fri, Mar 5, 2021 at 5:19 PM Marki  wrote:

> Hello,
>
> I am seeking a combination of either a combined configuration on one, or
> a config of several different DNS servers together to achieve the
> following:
> * Some clients should be able to resolve authoritative local zones as
> well as some forwarded zones.
> * Other clients should be able to resolve all of that _plus_ be able to
> make recursive queries to the internet (or use a global forwarder).
> All hosts use the same DNS servers, this should not be made about the
> clients but rather be configurable on the server.
>
> Now the problems are the following:
> * Since I need forwarders I can't turn off recursion.
> * Since I can't turn off recursion I can't prevent it to go and try to
> resolve from root DNS.
>
> How do I do one (local authority and forwarders) but not the other
> (iterative lookups on the Internet)?
>
> Thanks,
>
> 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