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
