subject:"Re\: Best practice MultiView"

Re: Best practice MultiView

2023-04-21 Thread Greg Choules via bind-users

Hi Jiaming.
You're welcome.

Personally I don't see why you want to obscure information about internal
zones, since they can't be reached from the Internet anyway.
Creating a dummy intermediate zone (an ENT - Empty Non-Terminal) may work,
but it seems to add complexity for no - or very little - benefit. Just my
2p.

Cheers, Greg

On Fri, 21 Apr 2023 at 15:41, Jiaming Zhang  wrote:

> Hi Greg,
>
> Thanks for the example given. I was trying to digest your answer, it seems
> it would be better to have intermediate subdomain for the purpose. So it
> will be site1.internal.example.com, site2.internal.example.com, etc. and
> thus only NS records of internal.example.com can be visible and not the
> actual internally operating site. Now it just a matter of migration from
> site_n.example.com to site_n.internal.example.com. (which I suppose is
> also better for DNSSEC)
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Wednesday, April 19, 2023 11:01:00 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> 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.
>
> Hope that helps.
> Greg
>
> On Wed, 19 Apr 2023 at 18:20, Jiaming Zhang  wrote:
>
> Dear Greg,
>
> That’s what I thought, of each individual zone must have NS record point
> to it. But my point is not hiding NS record (or which server handles it)
> from internal client but hiding which internal domain are we running from
> the external malicious client.
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j

Re: Best practice MultiView

2023-04-21 Thread Jiaming Zhang

Hi Greg,

Thanks for the example given. I was trying to digest your answer, it seems it 
would be better to have intermediate subdomain for the purpose. So it will be 
site1.internal.example.com, site2.internal.example.com, etc. and thus only NS 
records of internal.example.com can be visible and not the actual internally 
operating site. Now it just a matter of migration from site_n.example.com to 
site_n.internal.example.com. (which I suppose is also better for DNSSEC)

Kind regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.

Van: Greg Choules 
Verzonden: Wednesday, April 19, 2023 11:01:00 PM
Aan: Jiaming Zhang 
CC: bind-users@lists.isc.org 
Onderwerp: Re: Best practice MultiView

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<http://example.com>. The NS name is 
externalns.example.com<http://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<http://internal1.example.com>, 
internal2.example.com<http://internal2.example.com>, 
internal3.example.com<http://internal3.example.com>. The name of the NS itself 
is internalns.internal1.example.com<http://internalns.internal1.example.com>


EXTERNAL NS
zone: example.com<http://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<http://internal1.example.com>
@ SOA
@ NS internalns
internalns A 192.168.1.1
other records

zone internal2.example.com<http://internal2.example.com>
@ SOA
@ NS internalns.internal1.example.com<http://internalns.internal1.example.com>.
other records

zone internal3.example.com<http://internal3.example.com>
@ SOA
@ NS internalns.internal1.example.com<http://internalns.internal1.example.com>.
other records


From an Internet source, the only NS that can be reached is 
externalns.example.com<http://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.

Hope that helps.
Greg

On Wed, 19 Apr 2023 at 18:20, Jiaming Zhang 
mailto:j.zh...@yiximeta.com>> wrote:
Dear Greg,

That’s what I thought, of each individual zone must have NS record point to it. 
But my point is not hiding NS record (or which server handles it) from internal 
client but hiding which internal domain are we running from the external 
malicious client.

Kind regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com>
Website: yiximeta.com<http://yiximeta.com>

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of in

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

Re: Best practice MultiView

2023-04-19 Thread Greg Choules via bind-users

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.

Hope that helps.
Greg

On Wed, 19 Apr 2023 at 18:20, Jiaming Zhang  wrote:

> Dear Greg,
>
> That’s what I thought, of each individual zone must have NS record point
> to it. But my point is not hiding NS record (or which server handles it)
> from internal client but hiding which internal domain are we running from
> the external malicious client.
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Tuesday, April 18, 2023 2:51:05 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> Hi Jiaming.
>
> Every zone *must* have one SOA record and at least one NS record. This is
> a requirement of the protocol.
> Internal clients will (probably) be making recursive queries to the
> internal DNS server for A, , MX, SRV records (maybe some more types as
> well). It is unlikely they will be making queries for NS records normally.
> But what if they do? Why does it matter if clients find out the NS names
> for the internal zones?
>
> Cheers, Greg
>
> On Tue, 18 Apr 2023 at 13:27, Jiaming Zhang  wrote:
>
> Dear Greg,
>
> I agree using child zones is a better idea, and I'm actually using this,
> what I want to hide is the NS records of the internal-only subdomains. OR
> is the NS record totally unnecessary if the DNS resolver has these
> individual zones (which I don't think so based on how DNS query works).
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan ve

Re: Best practice MultiView

2023-04-19 Thread Jiaming Zhang

Dear Greg,

That’s what I thought, of each individual zone must have NS record point to it. 
But my point is not hiding NS record (or which server handles it) from internal 
client but hiding which internal domain are we running from the external 
malicious client.

Kind regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.

Van: Greg Choules 
Verzonden: Tuesday, April 18, 2023 2:51:05 PM
Aan: Jiaming Zhang 
CC: bind-users@lists.isc.org 
Onderwerp: Re: Best practice MultiView

Hi Jiaming.

Every zone *must* have one SOA record and at least one NS record. This is a 
requirement of the protocol.
Internal clients will (probably) be making recursive queries to the internal 
DNS server for A, , MX, SRV records (maybe some more types as well). It is 
unlikely they will be making queries for NS records normally.
But what if they do? Why does it matter if clients find out the NS names for 
the internal zones?

Cheers, Greg

On Tue, 18 Apr 2023 at 13:27, Jiaming Zhang 
mailto:j.zh...@yiximeta.com>> wrote:
Dear Greg,

I agree using child zones is a better idea, and I'm actually using this, what I 
want to hide is the NS records of the internal-only subdomains. OR is the NS 
record totally unnecessary if the DNS resolver has these individual zones 
(which I don't think so based on how DNS query works).

Kind regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com>
Website: yiximeta.com<http://yiximeta.com>

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.

Van: Greg Choules 
mailto:gregchoules%2bbindus...@googlemail.com>>
Verzonden: Tuesday, April 18, 2023 2:10:49 PM
Aan: Jiaming Zhang mailto:j.zh...@yiximeta.com>>
CC: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> 
mailto:bind-users@lists.isc.org>>
Onderwerp: Re: Best practice MultiView

Hi Jiaming.
I had a similar requirement. Since there were not many (a few tens or at most a 
hundred) names that needed to be resolved differently locally my approach was 
to create a zone for each of them and to not have the parent zone at all. Each 
specific zone would contain a single A record (or maybe others) with the owner 
name being @ or tha name of the zone.
e.g.:
EXTERNAL zone
example.com<http://example.com>
INTERNAL zones
insite.example.com<http://insite.example.com>
   @ A 10.1.1.1
another.example.com<http://another.example.com>
   @ A 10.1.1.2
etc...
This way, the default is for all resolution to go externally, except the names 
you want to resolve internally with different answers.

Cheers, Greg

On Tue, 18 Apr 2023 at 12:59, Jiaming Zhang 
mailto:j.zh...@yiximeta.com>> wrote:
Dear Greg,

The initiative was that we have certain records that wish to be view only 
internally and may resolve to private address (e.g. insite A 10.1.1.1).

Kind Regards,
Jiaming Zhang

Yixi Met

Re: Best practice MultiView

2023-04-18 Thread Greg Choules via bind-users

Hi Jiaming.

Every zone *must* have one SOA record and at least one NS record. This is a
requirement of the protocol.
Internal clients will (probably) be making recursive queries to the
internal DNS server for A, , MX, SRV records (maybe some more types as
well). It is unlikely they will be making queries for NS records normally.
But what if they do? Why does it matter if clients find out the NS names
for the internal zones?

Cheers, Greg

On Tue, 18 Apr 2023 at 13:27, Jiaming Zhang  wrote:

> Dear Greg,
>
> I agree using child zones is a better idea, and I'm actually using this,
> what I want to hide is the NS records of the internal-only subdomains. OR
> is the NS record totally unnecessary if the DNS resolver has these
> individual zones (which I don't think so based on how DNS query works).
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Tuesday, April 18, 2023 2:10:49 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> Hi Jiaming.
> I had a similar requirement. Since there were not many (a few tens or at
> most a hundred) names that needed to be resolved differently locally my
> approach was to create a zone for each of them and to not have the parent
> zone at all. Each specific zone would contain a single A record (or maybe
> others) with the owner name being @ or tha name of the zone.
> e.g.:
> EXTERNAL zone
> example.com
> INTERNAL zones
> insite.example.com
>@ A 10.1.1.1
> another.example.com
>@ A 10.1.1.2
> etc...
> This way, the default is for all resolution to go externally, except the
> names you want to resolve internally with different answers.
>
> Cheers, Greg
>
> On Tue, 18 Apr 2023 at 12:59, Jiaming Zhang  wrote:
>
> Dear Greg,
>
> The initiative was that we have certain records that wish to be view only
> internally and may resolve to private address (e.g. insite A 10.1.1.1).
>
> Kind Regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Monday, April 17, 2023 4:43:58 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> Hi Jiaming.
> The arguments to "also-notify {...};" are explicit IP addresses.
>
> Why do you need it? Do you have some secondaries that are not listed as NS
> in

Re: Best practice MultiView

2023-04-18 Thread Jiaming Zhang

Dear Greg,

I agree using child zones is a better idea, and I'm actually using this, what I 
want to hide is the NS records of the internal-only subdomains. OR is the NS 
record totally unnecessary if the DNS resolver has these individual zones 
(which I don't think so based on how DNS query works).

Kind regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.

Van: Greg Choules 
Verzonden: Tuesday, April 18, 2023 2:10:49 PM
Aan: Jiaming Zhang 
CC: bind-users@lists.isc.org 
Onderwerp: Re: Best practice MultiView

Hi Jiaming.
I had a similar requirement. Since there were not many (a few tens or at most a 
hundred) names that needed to be resolved differently locally my approach was 
to create a zone for each of them and to not have the parent zone at all. Each 
specific zone would contain a single A record (or maybe others) with the owner 
name being @ or tha name of the zone.
e.g.:
EXTERNAL zone
example.com<http://example.com>
INTERNAL zones
insite.example.com<http://insite.example.com>
   @ A 10.1.1.1
another.example.com<http://another.example.com>
   @ A 10.1.1.2
etc...
This way, the default is for all resolution to go externally, except the names 
you want to resolve internally with different answers.

Cheers, Greg

On Tue, 18 Apr 2023 at 12:59, Jiaming Zhang 
mailto:j.zh...@yiximeta.com>> wrote:
Dear Greg,

The initiative was that we have certain records that wish to be view only 
internally and may resolve to private address (e.g. insite A 10.1.1.1).

Kind Regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com>
Website: yiximeta.com<http://yiximeta.com>

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.

Van: Greg Choules 
mailto:gregchoules%2bbindus...@googlemail.com>>
Verzonden: Monday, April 17, 2023 4:43:58 PM
Aan: Jiaming Zhang mailto:j.zh...@yiximeta.com>>
CC: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> 
mailto:bind-users@lists.isc.org>>
Onderwerp: Re: Best practice MultiView

Hi Jiaming.
The arguments to "also-notify {...};" are explicit IP addresses.

Why do you need it? Do you have some secondaries that are not listed as NS in 
zones?

Regarding views. Why would you have the same zone in an internal and external 
view? A few years ago, having to maintain multiple zones of the same name but 
different contents caused me problems daily. I would recommend having internal 
zones be proper delegations from external zones. e.g.:
external "example.com<http://example.com>"
internal "internal.example.com<http://internal.example.com>"

Cheers, Greg

On Mon, 17 Apr 2023 at 14:41, Jiaming Zhang 
mailto:j.zh...@yiximeta.com>> wrote:
Dear Nick,

Thanks for the reply. What was already set that I didn't include in my first 
mail was that both views on both servers have m

Re: Best practice MultiView

2023-04-18 Thread Jiaming Zhang

Dear Nick,

The slave config was amended from the master, I don’t need the slave to notify 
any other server. I’ll check if any other zones have similar residue left. 
Thanks for pointing out.

Kind regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.

Van: bind-users  namens Nick Tait via 
bind-users 
Verzonden: Monday, April 17, 2023 10:58:22 PM
Aan: bind-users@lists.isc.org 
Onderwerp: Re: Best practice MultiView

On 18/04/2023 1:40 am, Jiaming Zhang wrote:
However, I got a question on the syntax of also-notify, what I can see from 
bind9's user manual, the target of also-notify can be  | 
 [ port  ] |  [ port  ], does 
this means that I can use domain names of the server instead of IP? Both name 
server has IPv4 (single or multiple) and IPv6 glued with the domain name, and I 
was wondering if by setting domain name instead of IP, bind will intelligently 
find if it would need to communicate with which IP (like it currently do with 
notify yes). I asked because if by any chance for whatever reason sending 
notify was failed to a certain IP, it may look up any other available IP that 
is defined with the related domain name (at least from my observation).

As Greg said, it needs to be IP addresses, not host names. The documentation 
defines "" as follows:

A named list of one or more ip_addresses with optional tls_id, server_key, 
and/or port. A remote-servers list may include other remote-servers lists. See 
primaries block.

I was also confused what you exactly referred to with '"primaries" (or 
"masters" in old terminology) statement that includes the correct key name', I 
assume you mean I need to point which is the master and the keys to communicate 
with this specific master on the slave server. For the reference, I attached 
the related config on slave below.

```
zone "example.com" IN {
type slave;
masters { ; };
file "/path/to/file";
allow-query { any; };
notify yes; # will become "explicit"
};
```

What I was trying to say was the primaries/masters block above needs to include 
the key name. Also you may not even need your secondaries (slaves) to send 
notifies - unless you have a hierarchical structure where your secondaries need 
to notify downstream secondaries? e.g. In the simplest case you might have your 
secondaries using:

zone "example.com" IN {
type slave;
masters { 192.0.2.2 key "internal.example.com"; };
file "/path/to/file";
allow-query { any; };
notify no;
};

NB: In all my examples "192.0.2.2" is the primary (master) and "192.0.2.1" is 
the secondary (slave).

Nick.
-- 
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-18 Thread Greg Choules via bind-users

Hi Jiaming.
I had a similar requirement. Since there were not many (a few tens or at
most a hundred) names that needed to be resolved differently locally my
approach was to create a zone for each of them and to not have the parent
zone at all. Each specific zone would contain a single A record (or maybe
others) with the owner name being @ or tha name of the zone.
e.g.:
EXTERNAL zone
example.com
INTERNAL zones
insite.example.com
   @ A 10.1.1.1
another.example.com
   @ A 10.1.1.2
etc...
This way, the default is for all resolution to go externally, except the
names you want to resolve internally with different answers.

Cheers, Greg

On Tue, 18 Apr 2023 at 12:59, Jiaming Zhang  wrote:

> Dear Greg,
>
> The initiative was that we have certain records that wish to be view only
> internally and may resolve to private address (e.g. insite A 10.1.1.1).
>
> Kind Regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Monday, April 17, 2023 4:43:58 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> Hi Jiaming.
> The arguments to "also-notify {...};" are explicit IP addresses.
>
> Why do you need it? Do you have some secondaries that are not listed as NS
> in zones?
>
> Regarding views. Why would you have the same zone in an internal and
> external view? A few years ago, having to maintain multiple zones of the
> same name but different contents caused me problems daily. I would
> recommend having internal zones be proper delegations from external zones.
> e.g.:
> external "example.com"
> internal "internal.example.com"
>
> Cheers, Greg
>
> On Mon, 17 Apr 2023 at 14:41, Jiaming Zhang  wrote:
>
> Dear Nick,
>
> Thanks for the reply. What was already set that I didn't include in my
> first mail was that both views on both servers have match-clients set
> (for internal set to "localhost" and "localnets", and for external set to
> "any"), so I'll add the keys also to the match-clients.
>
> However, I got a question on the syntax of also-notify, what I can see
> from bind9's user manual, the target of also-notify can be 
> |  [ port  ] |  [ port  ],
> does this means that I can use domain names of the server instead of IP?
> Both name server has IPv4 (single or multiple) and IPv6 glued with the
> domain name, and I was wondering if by setting domain name instead of IP,
> bind will intelligently find if it would need to communicate with which IP
> (like it currently do with notify yes). I asked because if by any chance
> for whatever reason sending notify was failed to a certain IP, it may look
> up any other available IP that is defined with the related domain name (at
> least from my observation).
>
> I was also confused what you exactly referred to with '"primaries" (or
> "masters" in old terminology) statement that includes the correct key
> name', I assume you mean I need to point which is the master and the keys
> to communicate with this specific master on the slave server. For the
> reference, I attached the related config on slave below.
>
> ```
> zone "example.com" IN {
> type slave;
> masters { ; };
> file "/path/to/file";
> allow-query { any; };
> notify yes; # will become "explicit"
> };
> ```
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De infor

Re: Best practice MultiView

2023-04-18 Thread Jiaming Zhang

Dear Greg,

The initiative was that we have certain records that wish to be view only 
internally and may resolve to private address (e.g. insite A 10.1.1.1).

Kind Regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.

Van: Greg Choules 
Verzonden: Monday, April 17, 2023 4:43:58 PM
Aan: Jiaming Zhang 
CC: bind-users@lists.isc.org 
Onderwerp: Re: Best practice MultiView

Hi Jiaming.
The arguments to "also-notify {...};" are explicit IP addresses.

Why do you need it? Do you have some secondaries that are not listed as NS in 
zones?

Regarding views. Why would you have the same zone in an internal and external 
view? A few years ago, having to maintain multiple zones of the same name but 
different contents caused me problems daily. I would recommend having internal 
zones be proper delegations from external zones. e.g.:
external "example.com<http://example.com>"
internal "internal.example.com<http://internal.example.com>"

Cheers, Greg

On Mon, 17 Apr 2023 at 14:41, Jiaming Zhang 
mailto:j.zh...@yiximeta.com>> wrote:
Dear Nick,

Thanks for the reply. What was already set that I didn't include in my first 
mail was that both views on both servers have match-clients set (for internal 
set to "localhost" and "localnets", and for external set to "any"), so I'll add 
the keys also to the match-clients.

However, I got a question on the syntax of also-notify, what I can see from 
bind9's user manual, the target of also-notify can be  | 
 [ port  ] |  [ port  ], does 
this means that I can use domain names of the server instead of IP? Both name 
server has IPv4 (single or multiple) and IPv6 glued with the domain name, and I 
was wondering if by setting domain name instead of IP, bind will intelligently 
find if it would need to communicate with which IP (like it currently do with 
notify yes). I asked because if by any chance for whatever reason sending 
notify was failed to a certain IP, it may look up any other available IP that 
is defined with the related domain name (at least from my observation).

I was also confused what you exactly referred to with '"primaries" (or 
"masters" in old terminology) statement that includes the correct key name', I 
assume you mean I need to point which is the master and the keys to communicate 
with this specific master on the slave server. For the reference, I attached 
the related config on slave below.

```
zone "example.com<http://example.com>" IN {
type slave;
masters { ; };
file "/path/to/file";
allow-query { any; };
notify yes; # will become "explicit"
};
```

Kind regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com>
Website: yiximeta.com<http://yiximeta.com>

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.
___

Re: Best practice MultiView

2023-04-17 Thread Nick Tait via bind-users


On 18/04/2023 2:43 am, Greg Choules via bind-users wrote:
Why do you need it? Do you have some secondaries that are not listed 
as NS in zones?


The goal was to have the primary use a particular TSIG key when it sends 
out the NOTIFY messages to the secondaries, which is achieved by turning 
off the default notifies ("notify explicit"), and specifying the keys in 
an "also-notify" block.


Regarding views. Why would you have the same zone in an internal and 
external view? A few years ago, having to maintain multiple zones of 
the same name but different contents caused me problems daily. I would 
recommend having internal zones be proper delegations from external 
zones. e.g.:

external "example.com "
internal "internal.example.com "


I agree that having your internal infrastructure in a sub-zone is a good 
idea. But even if you do this there are valid reasons for having a 
split-view of the parent zone. One reason is so that you can include 
proper NS delegation records in the parent zone (e.g. in the internal 
view only). (I don't remember all the details, but I seem to recall that 
without these, if the parent zone is DNSSEC-signed and doesn't use the 
OPT-OUT feature, then a DNSSEC-validating resolver (e.g. running "delv" 
tool) would complain when querying names in the internal zone.)


Nick.
-- 
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-17 Thread Nick Tait via bind-users


On 18/04/2023 1:40 am, Jiaming Zhang wrote:
However, I got a question on the syntax of |also-notify|, what I can 
see from bind9's user manual, the target of |also-notify| can be 
| |  [ port  ] |  
[ port  ]|, does this means that I can use domain names of 
the server instead of IP? Both name server has IPv4 (single or 
multiple) and IPv6 glued with the domain name, and I was wondering if 
by setting domain name instead of IP, bind will intelligently find if 
it would need to communicate with which IP (like it currently do with 
|notify yes|). I asked because if by any chance for whatever reason 
sending notify was failed to a certain IP, it may look up any other 
available IP that is defined with the related domain name (at least 
from my observation).


As Greg said, it needs to be IP addresses, not host names. The 
documentation defines "" as follows:


    A named list of one or more ip_addresses with optional tls_id, server_key, 
and/or port. A remote-servers list may include other remote-servers lists. See 
primaries block.

I was also confused what you exactly referred to with '"primaries" (or 
"masters" in old terminology) statement that includes the correct key 
name', I assume you mean I need to point which is the master and the 
keys to communicate with this specific master on the slave server. For 
the reference, I attached the related config on slave below.


```
zone "example.com" IN {
type slave;
masters { ; };
file "/path/to/file";
allow-query { any; };
notify yes; # will become "explicit"
};
```


What I was trying to say was the primaries/masters block above needs to 
include the key name. Also you may not even need your secondaries 
(slaves) to send notifies - unless you have a hierarchical structure 
where your secondaries need to notify downstream secondaries? e.g. In 
the simplest case you might have your secondaries using:


   zone "example.com" IN {
   type slave;
   masters { 192.0.2.2 key "internal.example.com"; };
   file "/path/to/file";
   allow-query { any; };
   notify no;
   };

NB: In all my examples "192.0.2.2" is the primary (master) and 
"192.0.2.1" is the secondary (slave).


Nick.
-- 
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-17 Thread Greg Choules via bind-users

Hi Jiaming.
The arguments to "also-notify {...};" are explicit IP addresses.

Why do you need it? Do you have some secondaries that are not listed as NS
in zones?

Regarding views. Why would you have the same zone in an internal and
external view? A few years ago, having to maintain multiple zones of the
same name but different contents caused me problems daily. I would
recommend having internal zones be proper delegations from external zones.
e.g.:
external "example.com"
internal "internal.example.com"

Cheers, Greg

On Mon, 17 Apr 2023 at 14:41, Jiaming Zhang  wrote:

> Dear Nick,
>
> Thanks for the reply. What was already set that I didn't include in my
> first mail was that both views on both servers have match-clients set
> (for internal set to "localhost" and "localnets", and for external set to
> "any"), so I'll add the keys also to the match-clients.
>
> However, I got a question on the syntax of also-notify, what I can see
> from bind9's user manual, the target of also-notify can be 
> |  [ port  ] |  [ port  ],
> does this means that I can use domain names of the server instead of IP?
> Both name server has IPv4 (single or multiple) and IPv6 glued with the
> domain name, and I was wondering if by setting domain name instead of IP,
> bind will intelligently find if it would need to communicate with which IP
> (like it currently do with notify yes). I asked because if by any chance
> for whatever reason sending notify was failed to a certain IP, it may look
> up any other available IP that is defined with the related domain name (at
> least from my observation).
>
> I was also confused what you exactly referred to with '"primaries" (or
> "masters" in old terminology) statement that includes the correct key
> name', I assume you mean I need to point which is the master and the keys
> to communicate with this specific master on the slave server. For the
> reference, I attached the related config on slave below.
>
> ```
> zone "example.com" IN {
> type slave;
> masters { ; };
> file "/path/to/file";
> allow-query { any; };
> notify yes; # will become "explicit"
> };
> ```
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* bind-users  namens Nick Tait via
> bind-users 
> *Verzonden:* maandag, april 17, 2023 1:03 PM
> *Aan:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
>
> Hi Jiaming.
>
> You'll also need "match-clients" in the first view (at least), so that the
> correct view handles the zone transfer request. As well as specifying 'the
> right key' in match-clients, you'll probably also want to specify 'not the
> wrong key', otherwise you won't be able to query the view from any clients
> (e.g. on your internal network) that don't present any key in their
> request...
>
> I've taken your example, and changed the key names to "
> internal.example.com" and "external.example.com" (for clarity), and added
> the match-clients to it as follows:
>
> view "internal" {
>   match-clients { key "internal.example.com"; !key "external.example.com";
> internal-networks; };
>   zone "example.com" IN {
> # some other config, master zone
> allow-transfer { key "internal.example.com"; };
> notify yes;
>   };
>   # some more zone
> };
> view "external" {
>   match-clients { key "external.example.com"; !key "internal.ex

Re: Best practice MultiView

2023-04-17 Thread Jiaming Zhang

Dear Nick,

Thanks for the reply. What was already set that I didn't include in my first 
mail was that both views on both servers have match-clients set (for internal 
set to "localhost" and "localnets", and for external set to "any"), so I'll add 
the keys also to the match-clients.

However, I got a question on the syntax of also-notify, what I can see from 
bind9's user manual, the target of also-notify can be  | 
 [ port  ] |  [ port  ], does 
this means that I can use domain names of the server instead of IP? Both name 
server has IPv4 (single or multiple) and IPv6 glued with the domain name, and I 
was wondering if by setting domain name instead of IP, bind will intelligently 
find if it would need to communicate with which IP (like it currently do with 
notify yes). I asked because if by any chance for whatever reason sending 
notify was failed to a certain IP, it may look up any other available IP that 
is defined with the related domain name (at least from my observation).

I was also confused what you exactly referred to with '"primaries" (or 
"masters" in old terminology) statement that includes the correct key name', I 
assume you mean I need to point which is the master and the keys to communicate 
with this specific master on the slave server. For the reference, I attached 
the related config on slave below.

```
zone "example.com" IN {
type slave;
masters { ; };
file "/path/to/file";
allow-query { any; };
notify yes; # will become "explicit"
};
```

Kind regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register with number 
85744115.

Van: bind-users  namens Nick Tait via 
bind-users 
Verzonden: maandag, april 17, 2023 1:03 PM
Aan: bind-users@lists.isc.org 
Onderwerp: Re: Best practice MultiView


Hi Jiaming.

You'll also need "match-clients" in the first view (at least), so that the 
correct view handles the zone transfer request. As well as specifying 'the 
right key' in match-clients, you'll probably also want to specify 'not the 
wrong key', otherwise you won't be able to query the view from any clients 
(e.g. on your internal network) that don't present any key in their request...

I've taken your example, and changed the key names to "internal.example.com" 
and "external.example.com" (for clarity), and added the match-clients to it as 
follows:

view "internal" {
  match-clients { key "internal.example.com"; !key "external.example.com"; 
internal-networks; };
  zone "example.com" IN {
# some other config, master zone
allow-transfer { key "internal.example.com"; };
notify yes;
  };
  # some more zone
};
view "external" {
  match-clients { key "external.example.com"; !key "internal.example.com"; any; 
};
  zone "example.com" IN {
# some other config, master zone
allow-transfer { key "external.example.com"; };
notify yes;
  };
};

Note that I've included "internal-networks" in the internal view. This is 
simply to illustrate that you might also want the view to answer DNS requests 
from clients within your network.

There is one further improvement on the above, which is what Mark referred to 
below, which is where each view can include the respective key in NOTIFY 
messages. To do that, change "notify yes" to "notify explicit" and then use 
"also-notify" to specify the secondary servers along with the key to use. 
Applying this to the above you get something like:

view "internal" {
  match-clients { key "internal.example.com"; !key "external.example.com"; 
internal-networks; };
  zone "example.com" IN {
# some other config, master zone
allow-transfer { key "internal.example.com";

Re: Best practice MultiView

2023-04-17 Thread Nick Tait via bind-users


Hi Jiaming.

You'll also need "match-clients" in the first view (at least), so that 
the correct view handles the zone transfer request. As well as 
specifying 'the right key' in match-clients, you'll probably also want 
to specify 'not the wrong key', otherwise you won't be able to query the 
view from any clients (e.g. on your internal network) that don't present 
any key in their request...


I've taken your example, and changed the key names to 
"internal.example.com" and "external.example.com" (for clarity), and 
added the match-clients to it as follows:


   view "internal" {
  match-clients { key "internal.example.com"; !key
   "external.example.com"; internal-networks; };
  zone "example.com" IN {
    # some other config, master zone
    allow-transfer { key "internal.example.com"; };
    notify yes;
  };
  # some more zone
   };
   view "external" {
  match-clients { key "external.example.com"; !key
   "internal.example.com"; any; };
  zone "example.com" IN {
    # some other config, master zone
    allow-transfer { key "external.example.com"; };
    notify yes;
  };
   };

Note that I've included "internal-networks" in the internal view. This 
is simply to illustrate that you might also want the view to answer DNS 
requests from clients within your network.


There is one further improvement on the above, which is what Mark 
referred to below, which is where each view can include the respective 
key in NOTIFY messages. To do that, change "notify yes" to "notify 
explicit" and then use "also-notify" to specify the secondary servers 
along with the key to use. Applying this to the above you get something 
like:


   view "internal" {
  match-clients { key "internal.example.com"; !key
   "external.example.com"; internal-networks; };
  zone "example.com" IN {
    # some other config, master zone
    allow-transfer { key "internal.example.com"; };
    notify explicit;
    also-notify { 192.0.2.1 key "internal.example.com"; };
  };
  # some more zone
   };
   view "external" {
  match-clients { key "external.example.com"; !key
   "internal.example.com"; any; };
  zone "example.com" IN {
    # some other config, master zone
    allow-transfer { key "external.example.com"; };
    notify explicit;
    also-notify { 192.0.2.1 key "external.example.com"; };
  };
   };

The secondary server would need a similar match-clients set-up so that 
it associated the notify with the correct view (based on key). And as 
I'm sure you know it would also need a "primaries" (or "masters" in old 
terminology) statement that includes the correct key name.


Nick.


On 17/04/23 22:12, Mark Andrews wrote:

You use keys as well when sending notify to select which view processes the 
notify


On 17 Apr 2023, at 18:44, Jiaming Zhang  wrote:

Dear community,

I was wondering if notifying and updating zones in different view (say "internal" and 
"external") between bind servers via different key is a good practice. I got a sample 
zone/config like below:
```
view "internal" {   zone "example.com" IN {
 # some other config, master zone
 allow-transfer { key key1; };
 notify yes;
   };
   # some more zone
}
view "external" {
   zone "example.com" IN {
 # some other config, master zone
 allow-transfer { key key2; };
 notify yes;
   };
}
```
where both zones have the same name server (e.g. `ns1.example.com` and `ns2.example.com`). What I'm trying to archive 
is that and update on zones in "internal" view does not contaminate zones in "external" view, or 
vice versa. I was wondering if using different key to limit update is a good practice, since I'm expecting 
"external" view on slave server will also receive notify upon update on "internal" zone at master, 
but just unable to query update due to incorrect key.

Kind Regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email:j.zh...@yiximeta.com
Website: yiximeta.com

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register

Re: Best practice MultiView

2023-04-17 Thread Mark Andrews

You use keys as well when sending notify to select which view processes the 
notify

> On 17 Apr 2023, at 18:44, Jiaming Zhang  wrote:
> 
> Dear community,
> 
> I was wondering if notifying and updating zones in different view (say 
> "internal" and "external") between bind servers via different key is a good 
> practice. I got a sample zone/config like below: 
> ```
> view "internal" {   zone "example.com" IN {
> # some other config, master zone
> allow-transfer { key key1; };
> notify yes;
>   };
>   # some more zone
> }
> view "external" {
>   zone "example.com" IN {
> # some other config, master zone
> allow-transfer { key key2; };
> notify yes;
>   };
> }
> ```
> where both zones have the same name server (e.g. `ns1.example.com` and 
> `ns2.example.com`). What I'm trying to archive is that and update on zones in 
> "internal" view does not contaminate zones in "external" view, or vice versa. 
> I was wondering if using different key to limit update is a good practice, 
> since I'm expecting "external" view on slave server will also receive notify 
> upon update on "internal" zone at master, but just unable to query update due 
> to incorrect key.
> 
> Kind Regards, 
> Jiaming Zhang
> 
> Yixi Meta
> Tel: +31 (6) 12 98 08 07
> Email: j.zh...@yiximeta.com
> Website: yiximeta.com 
> 
> De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. 
> Aan dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u 
> deze e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
> afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze 
> e-mail of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
> schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
> bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
> 
> The content of this message is intended solely for the addressee. No rights 
> can be derived from this message or its attachments. If you are not the 
> intended recipient, we kindly request you to delete the message and inform 
> the sender. It is strictly prohibited to disclose, copy or distribute this 
> email or the information inside it, without a written consent from the 
> sender. Yixi Meta is registered with the Dutch Chamber of Commerce trade 
> register with number 85744115.
> -- 
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

Re: Best practice MultiView

16 matches

Site Navigation

Mail list logo

Footer information