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 <gregchoules+bindus...@googlemail.com>
Verzonden: Wednesday, April 19, 2023 11:01:00 PM
Aan: Jiaming Zhang <j.zh...@yiximeta.com>
CC: bind-users@lists.isc.org <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 
<j.zh...@yiximeta.com<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 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 
<gregchoules+bindus...@googlemail.com<mailto:gregchoules%2bbindus...@googlemail.com>>
Verzonden: Tuesday, April 18, 2023 2:51:05 PM
Aan: Jiaming Zhang <j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com>>
CC: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> 
<bind-users@lists.isc.org<mailto: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, AAAA, 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 
<j.zh...@yiximeta.com<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 
<gregchoules+bindus...@googlemail.com<mailto:gregchoules%2bbindus...@googlemail.com>>
Verzonden: Tuesday, April 18, 2023 2:10:49 PM
Aan: Jiaming Zhang <j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com>>
CC: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> 
<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 
<j.zh...@yiximeta.com<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 
<gregchoules+bindus...@googlemail.com<mailto:gregchoules%2bbindus...@googlemail.com>>
Verzonden: Monday, April 17, 2023 4:43:58 PM
Aan: Jiaming Zhang <j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com>>
CC: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> 
<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 
<j.zh...@yiximeta.com<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 <remote-servers> | 
<ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ]​, 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 { <ip of master>; };
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.
________________________________
Van: bind-users 
<bind-users-boun...@lists.isc.org<mailto:bind-users-boun...@lists.isc.org>> 
namens Nick Tait via bind-users 
<bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>>
Verzonden: maandag, april 17, 2023 1:03 PM
Aan: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> 
<bind-users@lists.isc.org<mailto: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<http://internal.example.com>" and 
"external.example.com<http://external.example.com>" (for clarity), and added 
the match-clients to it as follows:

view "internal" {
  match-clients { key "internal.example.com<http://internal.example.com>"; !key 
"external.example.com<http://external.example.com>"; internal-networks; };
  zone "example.com<http://example.com>" IN {
    # some other config, master zone
    allow-transfer { key "internal.example.com<http://internal.example.com>"; };
    notify yes;
  };
  # some more zone
};
view "external" {
  match-clients { key "external.example.com<http://external.example.com>"; !key 
"internal.example.com<http://internal.example.com>"; any; };
  zone "example.com<http://example.com>" IN {
    # some other config, master zone
    allow-transfer { key "external.example.com<http://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<http://internal.example.com>"; !key 
"external.example.com<http://external.example.com>"; internal-networks; };
  zone "example.com<http://example.com>" IN {
    # some other config, master zone
    allow-transfer { key "internal.example.com<http://internal.example.com>"; };
    notify explicit;
    also-notify { 192.0.2.1 key 
"internal.example.com<http://internal.example.com>"; };
  };
  # some more zone
};
view "external" {
  match-clients { key "external.example.com<http://external.example.com>"; !key 
"internal.example.com<http://internal.example.com>"; any; };
  zone "example.com<http://example.com>" IN {
    # some other config, master zone
    allow-transfer { key "external.example.com<http://external.example.com>"; };
    notify explicit;
    also-notify { 192.0.2.1 key 
"external.example.com<http://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 
<j.zh...@yiximeta.com><mailto:j.zh...@yiximeta.com> 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<http://example.com>" IN {
    # some other config, master zone
    allow-transfer { key key1; };
    notify yes;
  };
  # some more zone
}
view "external" {
  zone "example.com<http://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<http://ns1.example.com>` and 
`ns2.example.com<http://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<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.
--
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<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users


--
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<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
-- 
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

Reply via email to