date:20210309

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

broken trust chain with my DNS setup

2021-03-09 Thread Peter via bind-users


https://bridgemode.bounceme.net/DNS%20BIND%20setup2.txt

%ProgramFiles%\ISC BIND 9\bin run CMD rndc-confgen -a
folder managed-keys in ect

file rndc.conf in etc

include "C:\Program Files\ISC BIND 9\etc\rndc.key";

options {
default-key "rndc-key";
  default-server 127.0.0.1;
  default-port 953;
};

file named.root in etc
ftp.internic.net
file localhost in etc

$TTL 86400
@  IN  SOA   @  root (
 0   ; Serial
 8H  ; Refresh
 15M ; Retry
 1W  ; Expire
 1D) ; Minimum TTL
   IN   NS   @
   IN   A127.0.0.1
   IN      ::1

file 127.0.0.zone in etc

$TTL3D
@   IN  SOA localhost. root.localhost. (
1   ; serial
8H  ; refresh
2H  ; retry
4W  ; expiry
1D ); minimum
 IN   NS  localhost.
1IN   PTR localhost.

Main PC file named.conf in ect

acl private { 192.168.255.54; };
acl loopbackPC { 127.0.0.1; };
acl PClooplookup { 192.168.255.53;  };
acl bogusnets { 0.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12;! 192.168.255.56;! 
192.168.255.55;! 192.168.255.54;! 192.168.255.53; 192.168.0.0/16; 
169.254.0.0/16; };
acl Rebinding { :::127.0.0.1/128; :::192.168.0.0/120; 
:::172.16.0.0/116; :::10.0.0.0/120; ::1/128; 127.0.0.0/24;0.0.0.0/8; 
10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; 169.254.0.0/16; };
options {
  version none;
  hostname none;
  server-id none;
  deny-answer-addresses { "Rebinding";} except-from { 
"private";"loopbackPC";"PClooplookup"; };
  directory "C:\Program Files\ISC BIND 9\etc";
  listen-on-v6 { ::1; };
  listen-on port 53 { 127.0.0.1; 192.168.255.56;192.168.255.55; };
  avoid-v4-udp-ports { 
53;67;68;69;533;445;500;135;137;138;139;546;547;1900;3702;4500;5000;5004;5005; 
};
  use-v4-udp-ports { range 1 65535; };
  avoid-v6-udp-ports { 
53;67;68;69;533;445;500;135;137;138;139;546;547;1900;3702;4500;5000;5004;5005; 
};
  use-v6-udp-ports { range 1 65535; };
  blackhole { bogusnets; };
//  dnssec-enable yes;
  managed-keys-directory "managed-keys";
  lame-ttl 0;
  max-recursion-depth 1000;
  max-recursion-queries 1000;
  resolver-query-timeout 3;
  querylog yes;
};
view private {
match-clients { private; };
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone
zone"localhost"   { type master; file "localhost";
};
// local reverse zone
zone"0.0.127.in-addr.arpa"{ type master; file "127.0.0.zone";
};
};
view loopbackPC {
match-clients { loopbackPC; };
forward only;
forwarders { 192.168.255.53; };
query-source address 192.168.255.56 port *;
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone
zone"localhost"   { type master; file "localhost";
};
// local reverse zone
zone"0.0.127.in-addr.arpa"{ type master; file "127.0.0.zone";
};
};
view PClooplookup {
match-clients { PClooplookup; };
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone
zone"localhost"   { type master; file "localhost";
};
// local reverse zone
zone"0.0.127.in-addr.arpa"{ type master; file "127.0.0.zone";
};
};

HTPC file named.conf in ect

acl lookup2backtoPC { 192.168.255.55; };
acl lookupbacktoPC { 192.168.255.56; };
acl bogusnets { 0.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12;!  192.168.255.56;! 
192.168.255.55;! 192.168.255.54;! 192.168.255.53; 192.168.0.0/16; 
169.254.0.0/16; };
acl Rebinding { ! 192.168.255.253; :::127.0.0.1/128; 
:::192.168.0.0/120; :::172.16.0.0/116; :::10.0.0.0/120; ::1/128; 
127.0.0.0/24;0.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; 
169.254.0.0/16; };
options {
  version none;
  hostname none;
  server-id none;
  deny-answer-addresses { "Rebinding";} except-from { lookupbacktoPC; 
lookup2backtoPC; };
  directory "C:\Program Files\ISC BIND 9\etc";
  listen-on-v6 { ::1; };
  listen-on port 53 { 127.0.0.1; 192.168.255.54;192.168.255.53; };
  avoid-v4-udp-ports { 
53;67;68;69;53;533;445;500;135;137;138;546;547;1900;3702;4500;5000;5004;5005; };
  use-v4-udp-ports { range 1 65535; };
  avoid-v6-udp-ports { 
53;67;68;69;53;533;445;500;135;137;138;546;547;1900;3702;4500;5000;5004;5005; };
  use-v6-udp-ports { range 1 65535; };
  blackhole { bogusnets; };
//  dnssec-enable yes;
  lame-ttl 0;
  max-recursion-depth 1000;
  max-recursion-queries 1000;
  resolver-query-timeout 3;
  managed-keys-directory "managed-keys";
  querylog yes;
};
view "lookupbacktoPC" {
match-clients { lookupbacktoPC;};
forward only;
forwarders  { 192.168.255.55; };
query-source address 192.168.255.53 port *;
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone

broken trust chain with my DNS setup

2021-03-09 Thread Peter via bind-users


Hi hope someone can help here is my setup on Bind 9.17.10.

https://bridgemode.bounceme.net/DNS%20BIND%20setup.html 



https://bridgemode.bounceme.net/DNS%20BIND%20setup2.txt

When working what happens is:

first lookup

Lookup by 127.0.0.1 on main PC then bind forwards to 192.168.255.53 from 
192.168.255.56 then HTPC by bind forwards to 192.168.255.55 from 
192.168.255.53 Main PC then does the recursion lookup in the given view/ACL


second lookup

Lookup by 192.168.255.53 on main PC from 192.168.255.55 then HTPC by 
bind forwards to 192.168.255.56 from 192.168.255.54 Main PC then does 
the recursion lookup in the given view/ACL


*issue*

What happens is this after many days of working fine:

querylog yes;

client @0227150F1FE8 127.0.0.1#55768 (community.zyxel.com): view 
loopbackPC: query failed (broken trust chain) for 
community.zyxel.com/IN/A at c:\builds\isc-private\bind9\lib\ns\query.c:7581


^This is from windows event viewer

Only way to fix is to restart bind on the main PC.

Thanks if you can help

___
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

Re: Authority and forwarding, but not recursion/iteration

Re: Authority and forwarding, but not recursion/iteration

broken trust chain with my DNS setup

broken trust chain with my DNS setup

5 matches

Site Navigation

Mail list logo

Footer information