TR: Slave Zones for Bind 9.11

[Nicolas Breuer]

Hello All,

I have been migrated from Bind 9.8 to 9.11
Some big changes on the new version.

I have a zone file common for two views (one internal & one with recursion ON)
I have removed the file option in the zone configuration and I can now share the same zone on the two views.
I suspect the zone to be transferred in the memory

The issue with that is if the primary goes down and if we restart the second DNS Server.
I want to write on disk but that will fail the sharing on the two views

Can we specify a dynamic file-naming ?
Is it the expected behavior ?

Thanks

[Evan Hunt]

On Sun, Jun 17, 2018 at 05:32:34PM +0000, Nicolas Breuer wrote:
> I have removed the file option in the zone configuration and I can now share the same zone on the two views.
> I suspect the zone to be transferred in the memory

If you're using "in-view", the zone isn't transferred at all. There's a
single copy of the zone in memory, and both views have pointers to it.
You can still use the file option.

--
Evan Hunt -- ***@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Nicolas Breuer]

Hi Evan,

I’m not using the in-view.
So, per default this is copied into memory
In case of failure of primary the slave can take the lead but in case of a reboot, the slave will not download the copy

If using file option, i should use in-view and then duplicate the zone files.

The goal to have two views is only to allow recursion on our internal ip’s.



> Le 17 juin 2018 à 21:04, Evan Hunt <***@isc.org> a écrit :
>
>> On Sun, Jun 17, 2018 at 05:32:34PM +0000, Nicolas Breuer wrote:
>> I have removed the file option in the zone configuration and I can now share the same zone on the two views.
>> I suspect the zone to be transferred in the memory
>
> If you're using "in-view", the zone isn't transferred at all. There's a
> single copy of the zone in memory, and both views have pointers to it.
> You can still use the file option.
>
> --
> Evan Hunt -- ***@isc.org
> Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
h

[Evan Hunt]

On Sun, Jun 17, 2018 at 07:10:11PM +0000, Nicolas Breuer wrote:
> I’m not using the in-view.
> So, per default this is copied into memory
> In case of failure of primary the slave can take the lead but in case of
> a reboot, the slave will not download the copy

I think I'd have to see your config to understand. But if you
had it like this:

view a {
zone foo.com {
type slave;
masters { ... };
file "filename";
...
};
};

view b {
zone foo.com {
in-view a;
};
};

... then you'd have foo.com accessible within both views, and it will
be saved only once, in "filename".

> The goal to have two views is only to allow recursion on our internal ip’s.

If you don't have any zones that differ between your internal
and external views, then views are unnecessary. Just use
"allow-recursion { localnets; };" and external queries won't be
allowed to do recursion.

--
Evan Hunt -- ***@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-

[Nicolas Breuer]

1000x thanks Evan for your advises.

I will try to modify the configuration with the allow-recursion options.



-----Message d'origine-----
De : Evan Hunt [mailto:***@isc.org]
Envoyé : dimanche 17 juin 2018 22:59
À : Nicolas Breuer <***@belcenter.biz>
Cc : bind-***@lists.isc.org
Objet : Re: TR: Slave Zones for Bind 9.11

On Sun, Jun 17, 2018 at 07:10:11PM +0000, Nicolas Breuer wrote:
> I’m not using the in-view.
> So, per default this is copied into memory In case of failure of
> primary the slave can take the lead but in case of a reboot, the slave
> will not download the copy

I think I'd have to see your config to understand. But if you had it like this:

view a {
zone foo.com {
type slave;
masters { ... };
file "filename";
...
};
};

view b {
zone foo.com {
in-view a;
};
};

... then you'd have foo.com accessible within both views, and it will be saved only once, in "filename".

> The goal to have two views is only to allow recursion on our internal ip’s.

If you don't have any zones that differ between your internal and external views, then views are unnecessary. Just use "allow-recursion { localnets; };" and external queries won't be allowed to do recursion.

--
Evan Hunt -- ***@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-user

[Nicolas Breuer]

I have setup like this :



view "DNS" {



allow-recursion { acl-allow; };





zone "." {

type hint;

file "named.ca";

};



include "/etc/named/zones";



};



Seems working 😊





-----Message d'origine-----
De : Evan Hunt [mailto:***@isc.org]
Envoyé : dimanche 17 juin 2018 22:59
À : Nicolas Breuer <***@belcenter.biz>
Cc : bind-***@lists.isc.org
Objet : Re: TR: Slave Zones for Bind 9.11



On Sun, Jun 17, 2018 at 07:10:11PM +0000, Nicolas Breuer wrote:

> I’m not using the in-view.

> So, per default this is copied into memory In case of failure of

> primary the slave can take the lead but in case of a reboot, the slave

> will not download the copy



I think I'd have to see your config to understand. But if you had it like this:



view a {

zone foo.com {

type slave;

masters { ... };

file "filename";

...

};

};



view b {

zone foo.com {

in-view a;

};

};



... then you'd have foo.com accessible within both views, and it will be saved only once, in "filename".



> The goal to have two views is only to allow recursion on our internal ip’s.



If you don't have any zones that differ between your internal and external views, then views are unnecessary. Just use "allow-recursion { localnets; };" and external queries won't be allowed to do recursion.



--

Evan Hunt -- ***@isc.org<mailto:***@isc.org>

Internet Systems Consortium, Inc.