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 <j.zh...@yiximeta.com> 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 <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>
> *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. 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 <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 <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>
> *Verzonden:* Tuesday, April 18, 2023 2:51:05 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.
>
> 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> 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 <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>
> *Verzonden:* Tuesday, April 18, 2023 2:10:49 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.
> 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 <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 <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>
> *Verzonden:* Monday, April 17, 2023 4:43:58 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.
> 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 <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" 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 <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> namens Nick Tait via
> bind-users <bind-users@lists.isc.org>
> *Verzonden:* maandag, april 17, 2023 1:03 PM
> *Aan:* bind-users@lists.isc.org <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"; };
>     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 <j.zh...@yiximeta.com> 
> <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" 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 
> listbind-us...@lists.isc.orghttps://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
>
>
-- 
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