Multiple views (more than 2)
Marek Kozlowski
m.kozlowski at mini.pw.edu.pl
Fri Apr 18 14:06:42 UTC 2025
:-)
It seems like finally I've created a working solution in my testing lab
(primary: 192.168.0.199, secondary: 192.168.0.193, external secondaries
require no special configuration). Any comments welcome!
///////////////////////////////////////////////////////////////////////
// /etc/named.conf on primary
///////////////////////////////////////////////////////////////////////
allow-recursion { 127.0.0.1; 192.168/16; 10/8; };
allow-transfer { 192.168.0.193; };
allow-update { none; };
version none;
hostname none;
server-id none;
masterfile-format text;
};
key "priv1" {
algorithm hmac-sha256;
secret "rbOo3g75nDsJebqsXmk7qgWwXs+UdkwCEaXIEFyPbyU=";
};
key "priv2" {
algorithm hmac-sha256;
secret "8YkpK1giWqnfpdBC9EwHah2QxUlS6v2KKCKehtcKWtg=";
};
key "pub" {
algorithm hmac-sha256;
secret "KOcn0wcqHciUumjU84glTP8UBgZaOuBczfeKnMK7gSk=";
};
view priv1 {
match-clients { !key priv2; !key pub; key priv1; 10.1/16; };
// also-notify { 192.168.1.193 key priv1; };
zone "dupabanana.pl" in {
type master;
file "dupa-priv1.zone";
};
};
view priv2 {
match-clients { !key priv1; !key pub; key priv2; 10.2/16; };
// also-notify { 192.168.1.193 key priv2; };
zone "dupabanana.pl" in {
type master;
file "dupa-priv2.zone";
};
};
view pub {
match-clients { any; };
// also-notify { 192.168.1.193 key pub; };
zone "dupabanana.pl" in {
type master;
file "dupa-pub.zone";
};
};
///////////////////////////////////////////////////////////////////////
// /etc/named.conf on secondary
///////////////////////////////////////////////////////////////////////
allow-recursion { 127.0.0.1; 192.168/16; 10/8; };
allow-transfer { none; };
allow-update { none; };
version none;
hostname none;
server-id none;
masterfile-format text;
};
key "priv1" {
algorithm hmac-sha256;
secret "rbOo3g75nDsJebqsXmk7qgWwXs+UdkwCEaXIEFyPbyU=";
};
key "priv2" {
algorithm hmac-sha256;
secret "8YkpK1giWqnfpdBC9EwHah2QxUlS6v2KKCKehtcKWtg=";
};
key "pub" {
algorithm hmac-sha256;
secret "KOcn0wcqHciUumjU84glTP8UBgZaOuBczfeKnMK7gSk=";
};
view priv1 {
match-clients { !key priv2; !key pub; key priv1; 10.1/16; };
zone "dupabanana.pl" in {
type slave;
masters { 192.168.0.199 key priv1; };
file "dupa-priv1.zone";
};
};
view priv2 {
match-clients { !key priv1; !key pub; key priv2; 10.2/16; };
zone "dupabanana.pl" in {
type slave;
masters { 192.168.0.199 key priv2; };
file "dupa-priv2.zone";
};
};
view pub {
match-clients { any; };
zone "dupabanana.pl" in {
type slave;
masters { 192.168.0.199 key pub; };
file "dupa-pub.zone";
};
};
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