internal/external view problem

[/dev/rob0]

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: