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
