Multiple views (more than 2)
Marek Kozlowski
m.kozlowski at mini.pw.edu.pl
Tue Apr 15 07:14:38 UTC 2025
Sorry for numerous misspelled words. Too many spellcheckers active ;-)
BTW: mydomain-private1.zone (and mydomain-private2.zone respectively) on
the Primary look like:
;--------------------------------------------------------------------
$INCLUDE mydomain-public.zone
nfs IN A 192.168.127.1
printer IN A 192.168.1.1
ldap IN A 172.16.1.16
; etc
;--------------------------------------------------------------------
On 4/15/25 8:43 AM, Marek Kozlowski wrote:
> 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