<div dir="ltr">Hi.<div>That KB article shows you how to use TSIG keys as a view selector for zone transfer.</div><div><br></div><div>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".</div><div><br></div><div>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.</div><div>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. </div><div>/soapbox</div><div><br></div><div>If you absolutely *must* do this, some actual examples would help please, rather than generalisations.</div><div><br></div><div>Cheers, Greg</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 14 Apr 2025 at 20:05, Marek Kozlowski <<a href="mailto:m.kozlowski@mini.pw.edu.pl">m.kozlowski@mini.pw.edu.pl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">:-)<br>
<br>
Till now I've been using sth. like this for a single private and a <br>
single public views:<br>
<br>
<a href="https://kb.isc.org/docs/aa-00851" rel="noreferrer" target="_blank">https://kb.isc.org/docs/aa-00851</a><br>
<br>
For my clients I provided information on all my resources and recursive <br>
resolution, for external ones - about my public hosts and no recursive <br>
resolution. Trivial.<br>
<br>
But there is a new concept:<br>
<br>
For some reasons (its not my decision) workstations cloned from a single <br>
image (precisely: a few images of Windows, Linux and other systems) <br>
connected to different subnets should refer to different hosts for <br>
numerous services based on their CIDR prefixes. Don't ask me why not use <br>
/etc/hosts nor distribute parameters via DHCP - it's not my decision. I <br>
am responsible, as a DNS server administrator, for providing different <br>
answers to queries about A records based on client's IP (CIDR prefix). <br>
That is what views can do.<br>
<br>
Defining views for a single DNS server itself is trivial. The problem is <br>
setting up zone transfers of different zone description files (from <br>
different views) between many name servers. In my case:<br>
<br>
Zone description files from public view should be transferred from <br>
Primary to all three Secondary DNS servers (I'm supervising only two of <br>
them). All zone description files from all private views should be <br>
transferred from my Primary to my (internal) Secondary (into respective <br>
views) and NOT to external secondaries.<br>
<br>
AFAIK such a configuration of view transfers requires TSIGs for avoiding <br>
zone transfer overwriting.<br>
<br>
Best regards,<br>
Marek<br>
<br>
On 4/14/25 5:27 PM, Greg Choules wrote:<br>
> Hi Marek.<br>
> Please can you show the config that used to work?<br>
> Please can you also explain why it is desired to create more views? <br>
> Maybe give an example of what you're trying to achieve.<br>
> <br>
> In general, matching views is done top down - test clients against the <br>
> criteria in the first view. If they don't match, try the next view etc.<br>
> <br>
> "match-clients" is used to test whether the source address of the client <br>
> falls within the range allowed by the address match list specified.<br>
> "match-destinations" is used to test the destination address the <br>
> incoming query was sent to. It is not unusual to have a server listen-on <br>
> several addresses, each for a different set of clients.<br>
> Both of the above can be used together to make view selection even <br>
> tighter - clients must match against both their source address AND the <br>
> address they sent the query to.<br>
> <br>
> Keys - as criteria for matching views - are typically used between <br>
> servers for zone transfers. For example if your primary server has <br>
> multiple views and secondary servers must be directed to a specific view <br>
> for a given zone, keys can be set up at both ends so that the secondary <br>
> includes the key for a zone when making its transfer request and the <br>
> primary uses that to select the correct zone from the appropriate view. <br>
> End clients/stub resolvers don't typically use keys.<br>
> <br>
> I hope this helps.<br>
> Cheers, Greg<br>
> <br>
> <br>
> On Mon, 14 Apr 2025 at 14:12, Marek Kozlowski <br>
> <<a href="mailto:m.kozlowski@mini.pw.edu.pl" target="_blank">m.kozlowski@mini.pw.edu.pl</a> <mailto:<a href="mailto:m.kozlowski@mini.pw.edu.pl" target="_blank">m.kozlowski@mini.pw.edu.pl</a>>> wrote:<br>
> <br>
>     :-)<br>
> <br>
>     There are 4 name servers for my domain: two internal ones (my CIDR,<br>
>     managed by me) and two external ones (foreign IP, I have no<br>
>     administrative privileges).<br>
> <br>
>     I've been using two views: the private one (for my clients, served<br>
>     by my<br>
>     servers) and a public one (for remote clients, served by all four name<br>
>     servers). It used to work :-)<br>
> <br>
>     Now it's desired to create multiple different private views served<br>
>     by my<br>
>     name servers (one view for clients from each subnet of my network)<br>
>     and a<br>
>     single public view (the same as till now) and I'm getting a bit<br>
>     confused<br>
>     with keys and "match-clients" directives...<br>
> <br>
>     Any example, link, general formula or some smart how-to, or anything<br>
>     welcome...<br>
> <br>
>     Thanks a lot!<br>
>     Best regards,<br>
>     Marek<br>
> <br>
>     -- <br>
>     Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> <https://<br>
>     <a href="http://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">lists.isc.org/mailman/listinfo/bind-users</a>> to unsubscribe from this list<br>
> <br>
>     ISC funds the development of this software with paid support<br>
>     subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> <https://<br>
>     <a href="http://www.isc.org/contact/" rel="noreferrer" target="_blank">www.isc.org/contact/</a>> for more information.<br>
> <br>
> <br>
>     bind-users mailing list<br>
>     <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a> <mailto:<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>><br>
>     <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> <https://<br>
>     <a href="http://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">lists.isc.org/mailman/listinfo/bind-users</a>><br>
> <br>
<br>
<br>
</blockquote></div>