Re: Possible to condition a view based on the interface the query comes in on?
Thanks for the suggestions, folks. Using views with RPZs just gets problematic. Sharing vs forwarding: forwarding seems cleaner and although there are two copies of /BIND/ I don't know that that visibility really hurts anything. Plus that potentially allows the "rear view" resolver to live on a different machine. https://github.com/m3047/rear_view_rpz/blob/main/install/Optional_DNS_Service.md -- Fred Morris ___ Please 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: Possible to condition a view based on the interface the query comes in on?
On Thu, Nov 18, 2021 at 04:06:01PM -0800, Fred Morris wrote:
> Thanks for the encouragement folks, I forged ahead and I've got a
> different error now:
>
> "response-policy zone 'rpz1.m3047.net' for view standard is not a
> master or slave zone"
>
> That's the final denoument. There are several intermediate steps, such
> as moving all zone definitions into the views and converting all zone
> references in the second view to "in-view standard;" (where "standard"
> is the name of the first view).
>
> * There are a total of three RPZs.
> * Two are utilized in the first view. (actually this is a lie)
> * All three are utilized in the second view.
>
> and the "lie" is that the "unused" RPZ is dynamically updated in the
> first view (that's where update requests are sent); I suppose I could
> jigger that so that the updates happen in the second view. But the
> stopper is that error message, and that RPZ is common to both views.
>
> This is 9.12 FWIW.
(That's pretty outdated, BTW. End of life was 2.5 years ago.)
You can set things up so that one view will transfer a copy of a zone
from another, by using a TSIG key so that transfer requests from localhost
to localhost will be routed to the correct view:
key them-key { ... };
acl our-clients { ... };
view us {
match-clients { !key them-key; our-clients; };
zone example.com {
type secondary;
file "example-secondary.db";
primaries { 127.0.0.1 key them-key; };
};
};
view them {
match-clients { any; };
zone example.com {
type primary;
file "example-primary.db";
allow-transfer { localhost; };
};
};
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please 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: Possible to condition a view based on the interface the query comes in on?
Thanks for the encouragement folks, I forged ahead and I've got a different error now: "response-policy zone 'rpz1.m3047.net' for view standard is not a master or slave zone" That's the final denoument. There are several intermediate steps, such as moving all zone definitions into the views and converting all zone references in the second view to "in-view standard;" (where "standard" is the name of the first view). * There are a total of three RPZs. * Two are utilized in the first view. (actually this is a lie) * All three are utilized in the second view. and the "lie" is that the "unused" RPZ is dynamically updated in the first view (that's where update requests are sent); I suppose I could jigger that so that the updates happen in the second view. But the stopper is that error message, and that RPZ is common to both views. This is 9.12 FWIW. -- Fred Morris ___ Please 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: Possible to condition a view based on the interface the query comes in on?
Look in to "match-destination" in a view, i.e.
acl abcd.anycast {
10.10.10.1;
};
view "abcd" {
match-clients {
any;
};
match-destinations {
abcd.anycast;
};
...
};
The response-policy definition (and associated zone) can go into a view,
instead of global options.
Stuart
On 19/11/21, 7:40 am, "bind-users on behalf of Fred Morris"
wrote:
[You don't often get email from m3...@m3047.net. Learn why this is
important at http://aka.ms/LearnAboutSenderIdentification.]
Caution: This email is from an external sender. Please do not click links
or open attachments unless you recognize the sender and know the content is
safe. Forward suspicious emails to isitbad@.
I wanted to provide enhanced recursive DNS to (internal) clients on an
"opt in" basis, which is to say that clients could choose whether or not
to receive enhanced replies based on what they configured as their local
caching resolver. The enhanced services come in the form of a Response
Policy Zone (RPZ).
Didn't see any reason that it had to be separate instances of BIND,
thought maybe I could do it with views, but I've run into a couple of
roadblocks:
1. listen-on isn't supported in views.
2. internet wisdom augurs that response-policy isn't supported either.
Is there a way to do this or should I bite the bullet and run two copies
of BIND?
Thanks in advance...
--
Fred Morris
___
Please visit
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=04%7C01%7Cstuart%40registry.godaddy%7Cdad3a7b53cce4d00c11708d9aad39ccd%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637728648249954539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gjtq6vOlM%2BQIHcqfrVgJD%2Fzbjm3vLdF%2BKg74%2FtPQsuA%3D&reserved=0
to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.isc.org%2Fcontact%2F&data=04%7C01%7Cstuart%40registry.godaddy%7Cdad3a7b53cce4d00c11708d9aad39ccd%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637728648249954539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xptHiGDaNrn7P99mhYJrI%2Fbw2nAf%2FH7%2FJCRFUvabkrc%3D&reserved=0
for more information.
bind-users mailing list
bind-users@lists.isc.org
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=04%7C01%7Cstuart%40registry.godaddy%7Cdad3a7b53cce4d00c11708d9aad39ccd%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637728648249954539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gjtq6vOlM%2BQIHcqfrVgJD%2Fzbjm3vLdF%2BKg74%2FtPQsuA%3D&reserved=0
___
Please 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: Possible to condition a view based on the interface the query comes in on?
Fred Morris wrote: > > Didn't see any reason that it had to be separate instances of BIND, > thought maybe I could do it with views, but I've run into a couple of > roadblocks: > > 1. listen-on isn't supported in views. Right, listen-on is for the server as a whole. To control which view is used to answer a query based on the server address, use the `match-destinations` option. For details see https://bind9.readthedocs.io/en/v9_16_23/reference.html#view-statement-grammar > 2. internet wisdom augurs that response-policy isn't supported either. Don't believe everything you read on the internet :-) Yes, you can have different RPZ configurations in different views. Another trick that's useful for the kind of setup you are planning is to use the `attach-cache` option so that your views can share the same cache. This improves performance and reduces memory usage. It still works with differing RPZ policies because RPZ only affects the responses sent to clients; RPZ doesn't change how recursion works or what records are saved in the cache. Tony. -- f.anthony.n.finchhttps://dotat.at/ Fair Isle, Faeroes: Westerly or southwesterly 7 to severe gale 9, occasionally storm 10 for a time in Faeroes, decreasing 5 to 7 later. Rough or very rough, becoming high for a time. Occasional rain. Moderate, occasionally poor. ___ Please 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: Possible to condition a view based on the interface the query comes in on?
match-destinations ? --- >From an Android device, using BlueMail, which forces top-posting. On 18 Nov 2021, 20:40, at 20:40, Fred Morris wrote: >I wanted to provide enhanced recursive DNS to (internal) clients on an >"opt in" basis, which is to say that clients could choose whether or >not >to receive enhanced replies based on what they configured as their >local >caching resolver. The enhanced services come in the form of a Response >Policy Zone (RPZ). > >Didn't see any reason that it had to be separate instances of BIND, >thought maybe I could do it with views, but I've run into a couple of >roadblocks: > >1. listen-on isn't supported in views. >2. internet wisdom augurs that response-policy isn't supported either. > >Is there a way to do this or should I bite the bullet and run two >copies >of BIND? > >Thanks in advance... > >-- > >Fred Morris > > >___ >Please 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 ___ Please 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
Possible to condition a view based on the interface the query comes in on?
I wanted to provide enhanced recursive DNS to (internal) clients on an "opt in" basis, which is to say that clients could choose whether or not to receive enhanced replies based on what they configured as their local caching resolver. The enhanced services come in the form of a Response Policy Zone (RPZ). Didn't see any reason that it had to be separate instances of BIND, thought maybe I could do it with views, but I've run into a couple of roadblocks: 1. listen-on isn't supported in views. 2. internet wisdom augurs that response-policy isn't supported either. Is there a way to do this or should I bite the bullet and run two copies of BIND? Thanks in advance... -- Fred Morris ___ Please 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
