Authority and forwarding, but not recursion/iteration

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Authority and forwarding, but not recursion/iteration

Marki
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

Crist Clark
forward only;

On Fri, Mar 5, 2021 at 5:19 PM Marki <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

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 <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

Crist Clark
Where is it sending recursive queries if it owns the root?

On Sun, Mar 7, 2021 at 3:06 AM Marki <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

Tony Finch
In reply to this post by Marki
Marki <[hidden email]> 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.finch  <[hidden email]>  https://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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

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

> Marki <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

Tony Finch
Marki <[hidden email]> 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.finch  <[hidden email]>  https://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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

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

> Marki <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

Tony Finch
Marki <[hidden email]> 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.finch  <[hidden email]>  https://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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

Marki
On 3/13/2021 12:11 AM, Tony Finch wrote:
> Marki <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Authority and forwarding, but not recursion/iteration

Fred Morris
Hammers and nails...

On Tue, 16 Mar 2021, Marki wrote:
> On 3/13/2021 12:11 AM, Tony Finch wrote:
>>  Marki <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users