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