:-)
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:
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.kozlow...@mini.pw.edu.pl <mailto:m.kozlow...@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> 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/> for more information.
bind-users mailing list
bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users <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
