:-)
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
mailto:m.kozlow...@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
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:
