Multiple views (more than 2)
Marek Kozlowski
m.kozlowski at mini.pw.edu.pl
Tue Apr 15 06:43:07 UTC 2025
OK,
1. The sceniario:
For the clients: 192.168.1/24:
nfs.mydomain -> 192.168.127.1
printer.mydomain -> 192.168.1.1
ldap.mydomain -> 172.16.1.16
...
For the clients: 10/8:
nfs.mydomain -> 10.10.10.10
printer.mydomain -> 10.10.1.1
ldap.mydomain -> 172.16.1.17
...
For client with public IPs all obowe addresses should not be resolved.
2. A single server setup (fragments of the /etc/named.conf):
view private1 {
match clients { 192.168.1/24; };
zone "mydomain" in {
type master;
file "mydomain-private1.zone";
};
};
view private2 {
match clients { 10/8; };
zone "mydomain" in {
type master;
file "mydomain-private2.zone";
};
};
view public {
match clients { any; };
zone "mydomain" in {
type master;
file "mydomain-public.zone";
};
};
3. Now imagine that in addition to that Primary NS I have my own
Secondary NS that uses the same configuration (three views) and two
external Secondary NS, not managed by me that should use only
mydomain-public.zone for all queries. The problem is how to define zone
transfers (that my Secondary can distinguish there are three separate
zone description files for mydomain). AFAIK that's the point the TSIG
keys come into play..?
Best regards,
Marek
On 4/14/25 10:34 PM, Greg Choules wrote:
> Hi.
> That KB article shows you how to use TSIG keys as a view selector for
> zone transfer.
>
> If you want a single DNS server to give different answers to the same
> question based on client IP then you *could* (though I'm NOT
> recommending this, especially since it will be deprecated at some point)
> use "sortlist".
>
> Or you will have to have multiple versions of that name, each in a
> separate zone, each associated with a different view. Maintaining
> multiple versions will be a big overhead and, IMHO, this way madness lies.
> If it were my network I'd advise the team who designed this application
> to rethink their delivery mechanism. so that the requirement for
> one_name == multiple IPs goes away.
> /soapbox
>
> If you absolutely *must* do this, some actual examples would help
> please, rather than generalisations.
>
> Cheers, Greg
>
>
> On Mon, 14 Apr 2025 at 20:05, Marek Kozlowski
> <m.kozlowski at mini.pw.edu.pl <mailto:m.kozlowski at mini.pw.edu.pl>> wrote:
>
> :-)
>
> Till now I've been using sth. like this for a single private and a
> single public views:
>
> https://kb.isc.org/docs/aa-00851 <https://kb.isc.org/docs/aa-00851>
>
> For my clients I provided information on all my resources and recursive
> resolution, for external ones - about my public hosts and no recursive
> resolution. Trivial.
>
> But there is a new concept:
>
> For some reasons (its not my decision) workstations cloned from a
> single
> image (precisely: a few images of Windows, Linux and other systems)
> connected to different subnets should refer to different hosts for
> numerous services based on their CIDR prefixes. Don't ask me why not
> use
> /etc/hosts nor distribute parameters via DHCP - it's not my decision. I
> am responsible, as a DNS server administrator, for providing different
> answers to queries about A records based on client's IP (CIDR prefix).
> That is what views can do.
>
> Defining views for a single DNS server itself is trivial. The
> problem is
> setting up zone transfers of different zone description files (from
> different views) between many name servers. In my case:
>
> Zone description files from public view should be transferred from
> Primary to all three Secondary DNS servers (I'm supervising only two of
> them). All zone description files from all private views should be
> transferred from my Primary to my (internal) Secondary (into respective
> views) and NOT to external secondaries.
>
> AFAIK such a configuration of view transfers requires TSIGs for
> avoiding
> zone transfer overwriting.
>
> Best regards,
> Marek
>
> On 4/14/25 5:27 PM, Greg Choules wrote:
> > Hi Marek.
> > Please can you show the config that used to work?
> > Please can you also explain why it is desired to create more views?
> > Maybe give an example of what you're trying to achieve.
> >
> > In general, matching views is done top down - test clients
> against the
> > criteria in the first view. If they don't match, try the next
> view etc.
> >
> > "match-clients" is used to test whether the source address of the
> client
> > falls within the range allowed by the address match list specified.
> > "match-destinations" is used to test the destination address the
> > incoming query was sent to. It is not unusual to have a server
> listen-on
> > several addresses, each for a different set of clients.
> > Both of the above can be used together to make view selection even
> > tighter - clients must match against both their source address
> AND the
> > address they sent the query to.
> >
> > Keys - as criteria for matching views - are typically used between
> > servers for zone transfers. For example if your primary server has
> > multiple views and secondary servers must be directed to a
> specific view
> > for a given zone, keys can be set up at both ends so that the
> secondary
> > includes the key for a zone when making its transfer request and the
> > primary uses that to select the correct zone from the appropriate
> view.
> > End clients/stub resolvers don't typically use keys.
> >
> > I hope this helps.
> > Cheers, Greg
> >
> >
> > On Mon, 14 Apr 2025 at 14:12, Marek Kozlowski
> > <m.kozlowski at mini.pw.edu.pl <mailto:m.kozlowski at mini.pw.edu.pl>
> <mailto:m.kozlowski at mini.pw.edu.pl
> <mailto:m.kozlowski at mini.pw.edu.pl>>> wrote:
> >
> > :-)
> >
> > There are 4 name servers for my domain: two internal ones (my
> CIDR,
> > managed by me) and two external ones (foreign IP, I have no
> > administrative privileges).
> >
> > I've been using two views: the private one (for my clients,
> served
> > by my
> > servers) and a public one (for remote clients, served by all
> four name
> > servers). It used to work :-)
> >
> > Now it's desired to create multiple different private views
> served
> > by my
> > name servers (one view for clients from each subnet of my
> network)
> > and a
> > single public view (the same as till now) and I'm getting a bit
> > confused
> > with keys and "match-clients" directives...
> >
> > Any example, link, general formula or some smart how-to, or
> anything
> > welcome...
> >
> > Thanks a lot!
> > Best regards,
> > Marek
> >
> > --
> > Visit https://lists.isc.org/mailman/listinfo/bind-users
> <https://lists.isc.org/mailman/listinfo/bind-users> <https://
> > lists.isc.org/mailman/listinfo/bind-users <http://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/
> <https://www.isc.org/contact/> <https://
> > www.isc.org/contact/ <http://www.isc.org/contact/>> for more
> information.
> >
> >
> > bind-users mailing list
> > bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
> <mailto:bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>>
> > https://lists.isc.org/mailman/listinfo/bind-users <https://
> lists.isc.org/mailman/listinfo/bind-users> <https://
> > lists.isc.org/mailman/listinfo/bind-users <http://lists.isc.org/
> mailman/listinfo/bind-users>>
> >
>
>
More information about the bind-users
mailing list