Re: Is it possible to move a zone between catalogs on the same secondary?

2023-04-20 Thread Petr Špaček 

On 19. 04. 23 19:23, Jan-Piet Mens wrote:

Any ideas?


is this the point at which I confess I've only now read about Change of
Ownership (coo) [1]?


Indeed. Chapter
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-catalog-zones#name-change-of-ownership-coo-pro
has an example how the process is supposed to work.

And yes, you can automate this with nsupdate to old and new catalog, 
just beware that you need to wait until the change is propagated to all 
secondaries before moving on. (AFAIK order of operations is important, 
do it exactly as specified.)


HTH.

Petr Špaček
Internet Systems Consortium



 -JP

[1] 
https://bind9.readthedocs.io/en/latest/chapter6.html#change-of-ownership-coo

--
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: Best practice MultiView

2023-04-20 Thread Petr Špaček 

On 19. 04. 23 23:01, Greg Choules via bind-users wrote:

Hi Jiaming.
Here's what I would do. I am assuming one nameserver for the public zone 
and one (different) nameserver for the internal zones. You would use 
more in practice but I'm keeping it simple, for illustration.


The external NS is reachable from anywhere in the Internet. If you host 
it in your own network, ideally do it on a public DMZ. It hosts one 
zone; example.com . The NS name is 
externalns.example.com .


The internal NS is *not* reachable from anywhere in the Internet, only 
to internal hosts and probably on a private address (depends on your 
internal addressing scheme). It hosts three zones; internal1.example.com 
, internal2.example.com 
, internal3.example.com 
. The name of the NS itself is 
internalns.internal1.example.com 



EXTERNAL NS
zone: example.com 
@ SOA
@ NS externalns
internal1 NS internalns.internal1
internal2 NS internalns.internal1
internal2 NS internalns.internal1
other records...


INTERNAL NS
zone internal1.example.com 
@ SOA
@ NS internalns
internalns A 192.168.1.1
other records

zone internal2.example.com 
@ SOA
@ NS internalns.internal1.example.com 
.

other records

zone internal3.example.com 
@ SOA
@ NS internalns.internal1.example.com 
.

other records


 From an Internet source, the only NS that can be reached is 
externalns.example.com . Queries could be 
made to it to learn that delegations exist for the internal zones and 
the name of the NS for those zones. However, they cannot resolve the IP 
address of internalns. Not that it would help anyway if it's 
192.168.something and/or your firewalls block incoming DNS.


It is not essential to have the delegations in externalns because 
internal clients do not use them anyway. However, it is recommend to 
have them because a) it is technically correct and b) it will be 
necessary for DNSSEC validation to work internally.


Let me add one thing:
Not having delegations is asking for problems _also_ because 
non-existence of a domain is/can be cached on several levels.


When a client moves from external to internal view it might still "not 
see" the internal domains because of the cache.


--
Petr Špaček
Internet Systems Consortium
--
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

Is it possible to upgrade bind from 9.11 to 9.18 directly?

2023-04-20 Thread Saleck 
Hi,

we are currently running several bind 9.11 servers on Debian buster machines. 
We would 
like to upgrade and wonder if we could skip version 9.16 altogether or if it's 
a necessary 
middle step.

We have read both

https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-911-to-916[1]

and

https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918[2]

and it looks like there should be nothing that would break (we use only text 
and raw zone 
file types) if we did the direct 9.11 to 9.18 upgrade. But better be safe then 
sorry. 
Therefore we are seeking advice. ;)

If it's possible, can anyone confirm zone transfers from master to slave would 
still work 
even if the servers ran different major versions? I know we won't be able to 
use TLS until 
both servers would run 9.18 but would the regular transfers still work?

It would help us a great deal if anyone could confirm this or (and) warn us if 
there is 
something that we are missing in our assessment.

Kind regards,
David Bruha


[1] https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-911-to-916
[2] 
https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918


signature.asc
Description: This is a digitally signed message part.
-- 
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

RHEL, Centos, Rocky, Fedora rpm 9.16.40

2023-04-20 Thread Carl Byington via bind-users 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

https://www.five-ten-sg.com/mapper/bind contains links to the source
rpm, and build instructions. This .src.rpm contains a .tar.gz file with
the ARM documentation, so the rpm rebuild process does not need sphinx-
build and associated dependencies.

-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCZEHCuxUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsHkpwCfYSw+dDbpRtPjGLWttQV9f/q2vrgA
oIpFLi3ouqws8qzO4L2wFySmg3Au
=jn/E
-END PGP SIGNATURE-



-- 
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