Re: Multiple views (more than 2)

2025-04-14 Thread Greg Choules via bind-users 
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 
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:
>
> 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
> > 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  >

Re: Multiple views (more than 2)

2025-04-14 Thread Marek Kozlowski 

:-)

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 
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 
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 




--
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

Multiple views (more than 2)

2025-04-14 Thread Marek Kozlowski 

:-)

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 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

Re: Multiple views (more than 2)

2025-04-14 Thread Greg Choules via bind-users 
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 
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 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
>
-- 
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

Re: Grief after upgrade to macOS Sequioa 15.4

2025-04-14 Thread Marco Davids (SIDN) via bind-users 

For the record:

brew update
brew upgrade

now also does the trick.

--
Marco

On Fri, 4 Apr 2025 07:06:45 +0200 Daniel Stirnimann via bind-users wrote:


Hi Niall,

If you use brew, I solved it with this:

brew uninstall bind
brew cleanup
brew install libxml2
export LDFLAGS="-L/opt/homebrew/opt/libxml2/lib"
export CPPFLAGS="-I/opt/homebrew/opt/libxml2/include"
export PKG_CONFIG_PATH="/opt/homebrew/opt/libxml2/lib/pkgconfig"
brew install --build-from-source bind

Daniel


On 03.04.2025 20:48, Niall O'Reilly wrote:

I don't know whether this needs attention by Apple or by ISC.

Something in the depths seems to have been changed (by Apple)
in a way that gives dig (and perhaps other code using
libisc-9.20.7.dylib) indigestion during release of
resources before exiting.

Here's what I'm seeing:

|niall@m2a ~ % dig +short defo.ie 213.108.108.101 mem.c:367: INSIST(s 
>= size) failed, back trace 0 libisc-9.20.7.dylib 0x00010050bf3c 
default_callback + 72 1 libisc-9.20.7.dylib 0x00010050bed4 
isc_assertion_failed + 20 2 libisc-9.20.7.dylib 0x00010051fd30 
isc__mem_strdup + 0 3 libxml2.2.dylib 0x0001a7979764 
xmlCleanupCharEncodingHandlers + 96 4 libxml2.2.dylib 
0x0001a7997cac xmlCleanupParser + 36 5 libisc-9.20.7.dylib 
0x000100532688 isc__xml_shutdown + 12 6 libisc-9.20.7.dylib 
0x0001005198c0 isc__shutdown + 20 7 libsystem_c.dylib 
0x00019e239944 __cxa_finalize_ranges + 480 8 libsystem_c.dylib 
0x00019e239704 exit + 44 9 libdyld.dylib 0x00019e38bdc8 
_ZNK5dyld416LibSystemHelpers6getenvEPKc + 0 10 dyld 0x00019dfe2c60 
_ZNK5dyld423LibSystemHelpersWrapper4exitEi + 172 11 dyld 
0x00019dfe2b7c start + 6048 zsh: abort dig +short defo.ie 
niall@m2a ~ % |


/Niall


--
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