Re: internal/external view problem
On Wed, Dec 14, 2016 at 07:52:58PM +0100, Per olof Ljungmark wrote:
> I am facing a problem internal/external views, I will do my best
> to describe it:
>
> An internal host needs to nsupdate an external view using a key,
> but cannot because it is part of the internal ip range, at least
> that is what I think.
>
> The acutal use is for Letsencrypt certs.
>
> Is there a way do this witjh views or should I use another form
> of access control? The host sending the update needs to be part
> of "internals" to be able to lookup general names of course.
>
> I suppose I could use allow-query and others instead?
>
> acl internals {
> 192.168.1.0/24;
> };
>
> view "internal" {
This view has no match-clients setting. Therefore no query will
reach it. I suppose you wanted "match-clients { internals; };"
> zone "internal.example.com" {
> recursion yes;
> type slave;
> file "slave/db.internal.example.com";
> masters {
> 192.168.1.1;
> };
> };
> };
>
> view "external" {
> match-clients { any; };
Here is where they will go.
> recursion no;
> allow-transfer { slaves; };
> zone "example.com" {
> type master;
> file "dynamic/db.example.com";
> allow-update{
> key rndc-key;
Don't reuse your rndc key for zone updates. Make and use a different
key.
If that's NOT your rndc key, give it a better name so someone coming
in will know what it is for.
You would also add an exclusion in your "internals" acl for this
update key:
acl internals { !key update-key; 192.168.1.0/24; };
This way, any query ("query" being a generic term including
nsupdates) signed by the update-key is not routed to your
"internal" view.
> };
> };
> };
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
internal/external view problem
Hi list,
I am facing a problem internal/external views, I will do my best to
describe it:
An internal host needs to nsupdate an external view using a key, but
cannot because it is part of the internal ip range, at least that is
what I think.
The acutal use is for Letsencrypt certs.
Is there a way do this witjh views or should I use another form of
access control? The host sending the update needs to be part of
"internals" to be able to lookup general names of course.
I suppose I could use allow-query and others instead?
acl internals {
192.168.1.0/24;
};
view "internal" {
zone "internal.example.com" {
recursion yes;
type slave;
file "slave/db.internal.example.com";
masters {
192.168.1.1;
};
};
};
view "external" {
match-clients { any; };
recursion no;
allow-transfer { slaves; };
zone "example.com" {
type master;
file "dynamic/db.example.com";
allow-update{
key rndc-key;
};
};
};
Thanks,
//per
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: view problem
If there are zones that both sets of clients should see, you have to duplicate them in both views. Overlapping views don't do this automatically. solved thanks your advice cheers! Pol ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: view problem
On Wed, 19 Oct 2016, Mark Andrews wrote: In message , Jay Ford writes: Right. "in-view" can be useful for this, as long as you only need to refer to previously defined views (i.e., it unfortunatley doesn't allow forward references). So put the zone in the first view. Updates, notifies and queries are delivered to the zone from all views the zone is in. Acls are all configurable on the zone level if you don't like the inherited acls from the first view. To get any order we need to configure all views without the in-view zones then go back and configure all the in-view zones. We then would need to go and configure all the automatic empty zones as they need to be aware of bottom of zone cuts. It's do able but it isn't high on the priority list. Understood. I didn't say it was unreasonable; just unfortunate. There are some configurations which would benefit from order-independent in-view references, but I understand that it's not trivial. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: view problem
In message , Jay Ford writes: > On Tue, 18 Oct 2016, Barry Margolin wrote: > > If there are zones that both sets of clients should see, you have to > > duplicate them in both views. Overlapping views don't do this > > automatically. > > Right. "in-view" can be useful for this, as long as you only need to refer > to previously defined views (i.e., it unfortunatley doesn't allow forward > references). So put the zone in the first view. Updates, notifies and queries are delivered to the zone from all views the zone is in. Acls are all configurable on the zone level if you don't like the inherited acls from the first view. To get any order we need to configure all views without the in-view zones then go back and configure all the in-view zones. We then would need to go and configure all the automatic empty zones as they need to be aware of bottom of zone cuts. It's do able but it isn't high on the priority list. Mark > > Jay Ford, Network Engineering Group, Information Technology Services > University of Iowa, Iowa City, IA 52242 > email: jay-f...@uiowa.edu, phone: 319-335- > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > 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 bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: view problem
On Tue, 18 Oct 2016, Barry Margolin wrote: If there are zones that both sets of clients should see, you have to duplicate them in both views. Overlapping views don't do this automatically. Right. "in-view" can be useful for this, as long as you only need to refer to previously defined views (i.e., it unfortunatley doesn't allow forward references). Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: view problem
In article , Pol Hallen wrote: > > Please be aware that only one view is visible for any client. > > mhmh... > > how I can solve my problem? > > all clients need to access to my zones but mobile clients (don't have > vpn client) needs to access to all zones exception vpn (but can use FQDN) > > any idea? If there are zones that both sets of clients should see, you have to duplicate them in both views. Overlapping views don't do this automatically. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: view problem
Please be aware that only one view is visible for any client. mhmh... how I can solve my problem? all clients need to access to my zones but mobile clients (don't have vpn client) needs to access to all zones exception vpn (but can use FQDN) any idea? thanks POl ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: view problem
Pol,
If your master server itself providing DNS service to clients, then you may try
something like this, (Else you may use the same order and forwarder on your
slave servers)
// vpn
view "vpn" {
match-clients { acl1; };
forward only;
forwarders { 127.0.0.1; };
zone "vpn_zone" {
type master;
file "/etc/bind/zones/vpn.db";
};
};
// zone1
view "internal_lan" {
match-clients { acl1; acl2; };
include "/etc/bind/named.conf.default-zones";
zone "zone1" {
type master;
file "/etc/bind/zones/zone1.db";
};
Thanks & Regards,
Hari Ganesh Ram Mohan
From: Sten Carlsen [mailto:st...@s-carlsen.dk]
Sent: Tuesday, October 18, 2016 2:37 PM
To: RAM MOHAN, Hari Ganesh
Cc: m...@fuckaround.org; bind-users@lists.isc.org
Subject: Re: view problem
Please be aware that only one view is visible for any client. You have acl1 in
both views indicating that you assume a host in acl1 can get info from both
views - this is not possible. The list is searched from the top of the file and
the first match, only the first, will be the DNS service available to the
client.
-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
On 18 Oct 2016, at 10.28, RAM MOHAN, Hari Ganesh
mailto:hari.rammo...@atos.net>> wrote:
View concept works in order, as you have internal_lan view first, acl1 users
are falling to this view and not able to find vpn_zone.
You may try swapping order,
// vpn
view "vpn" {
match-clients { acl1; };
zone "vpn_zone" {
type master;
file "/etc/bind/zones/vpn.db";
};
};
// zone1
view "internal_lan" {
match-clients { acl1; acl2; };
include "/etc/bind/named.conf.default-zones";
zone "zone1" {
type master;
file "/etc/bind/zones/zone1.db";
};
Thanks & Regards,
Hari Ganesh Ram Mohan
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Pol
Hallen
Sent: Tuesday, October 18, 2016 1:21 PM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: view problem
Hi all :-)
I've two zones: zone1 is an internal zone and another zone: vpn.
I need that acl1 can "see" internal vpn zone, the problem is that acl1 "see"
vpn zone as external zone because this zone is a FQDN, while should see vpn as
vpn.db.
192.168.1.0/24 are clients with also openvpn clients, while
192.168.2.0/24 are not vpn clients.
sorry but I can't simplify :-/
acl1 {192.168.1.0/24; };
acl2 {192.168.2.0/24; };
// zone1
view "internal_lan" {
match-clients { acl1; acl2; };
include "/etc/bind/named.conf.default-zones";
zone "zone1" {
type master;
file "/etc/bind/zones/zone1.db";
};
// vpn
view "vpn" {
match-clients { acl1; };
zone "vpn_zone" {
type master;
file "/etc/bind/zones/vpn.db";
};
};
Pol
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org<mailto: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
bind-users mailing list
bind-users@lists.isc.org<mailto: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
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: view problem
Please be aware that only one view is visible for any client. You have acl1 in
both views indicating that you assume a host in acl1 can get info from both
views - this is not possible. The list is searched from the top of the file and
the first match, only the first, will be the DNS service available to the
client.
-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
> On 18 Oct 2016, at 10.28, RAM MOHAN, Hari Ganesh
> wrote:
>
> View concept works in order, as you have internal_lan view first, acl1 users
> are falling to this view and not able to find vpn_zone.
>
> You may try swapping order,
>
> // vpn
> view "vpn" {
> match-clients { acl1; };
>
> zone "vpn_zone" {
> type master;
> file "/etc/bind/zones/vpn.db";
> };
>
> };
>
> // zone1
> view "internal_lan" {
> match-clients { acl1; acl2; };
> include "/etc/bind/named.conf.default-zones";
>
> zone "zone1" {
> type master;
> file "/etc/bind/zones/zone1.db";
> };
>
> Thanks & Regards,
>
> Hari Ganesh Ram Mohan
>
>
> -----Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Pol
> Hallen
> Sent: Tuesday, October 18, 2016 1:21 PM
> To: bind-users@lists.isc.org
> Subject: view problem
>
> Hi all :-)
>
> I've two zones: zone1 is an internal zone and another zone: vpn.
>
> I need that acl1 can "see" internal vpn zone, the problem is that acl1 "see"
> vpn zone as external zone because this zone is a FQDN, while should see vpn
> as vpn.db.
>
> 192.168.1.0/24 are clients with also openvpn clients, while
> 192.168.2.0/24 are not vpn clients.
>
> sorry but I can't simplify :-/
>
> acl1 {192.168.1.0/24; };
> acl2 {192.168.2.0/24; };
>
> // zone1
> view "internal_lan" {
> match-clients { acl1; acl2; };
> include "/etc/bind/named.conf.default-zones";
>
> zone "zone1" {
> type master;
> file "/etc/bind/zones/zone1.db";
> };
>
> // vpn
> view "vpn" {
> match-clients { acl1; };
>
> zone "vpn_zone" {
> type master;
> file "/etc/bind/zones/vpn.db";
> };
>
> };
>
>
> Pol
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> 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
>
> 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
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: view problem
View concept works in order, as you have internal_lan view first, acl1 users
are falling to this view and not able to find vpn_zone.
You may try swapping order,
// vpn
view "vpn" {
match-clients { acl1; };
zone "vpn_zone" {
type master;
file "/etc/bind/zones/vpn.db";
};
};
// zone1
view "internal_lan" {
match-clients { acl1; acl2; };
include "/etc/bind/named.conf.default-zones";
zone "zone1" {
type master;
file "/etc/bind/zones/zone1.db";
};
Thanks & Regards,
Hari Ganesh Ram Mohan
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Pol
Hallen
Sent: Tuesday, October 18, 2016 1:21 PM
To: bind-users@lists.isc.org
Subject: view problem
Hi all :-)
I've two zones: zone1 is an internal zone and another zone: vpn.
I need that acl1 can "see" internal vpn zone, the problem is that acl1 "see"
vpn zone as external zone because this zone is a FQDN, while should see vpn as
vpn.db.
192.168.1.0/24 are clients with also openvpn clients, while
192.168.2.0/24 are not vpn clients.
sorry but I can't simplify :-/
acl1 {192.168.1.0/24; };
acl2 {192.168.2.0/24; };
// zone1
view "internal_lan" {
match-clients { acl1; acl2; };
include "/etc/bind/named.conf.default-zones";
zone "zone1" {
type master;
file "/etc/bind/zones/zone1.db";
};
// vpn
view "vpn" {
match-clients { acl1; };
zone "vpn_zone" {
type master;
file "/etc/bind/zones/vpn.db";
};
};
Pol
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
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
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
view problem
Hi all :-)
I've two zones: zone1 is an internal zone and another zone: vpn.
I need that acl1 can "see" internal vpn zone, the problem is that acl1
"see" vpn zone as external zone because this zone is a FQDN, while
should see vpn as vpn.db.
192.168.1.0/24 are clients with also openvpn clients, while
192.168.2.0/24 are not vpn clients.
sorry but I can't simplify :-/
acl1 {192.168.1.0/24; };
acl2 {192.168.2.0/24; };
// zone1
view "internal_lan" {
match-clients { acl1; acl2; };
include "/etc/bind/named.conf.default-zones";
zone "zone1" {
type master;
file "/etc/bind/zones/zone1.db";
};
// vpn
view "vpn" {
match-clients { acl1; };
zone "vpn_zone" {
type master;
file "/etc/bind/zones/vpn.db";
};
};
Pol
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
