On 19/04/2025 02:06, Marek Kozlowski wrote:
view pub {
match-clients { any; };
Hi Marek.
What you have created looks great, and looks like it will work fine. I
have one minor suggestion though: For consistency with your other views,
and to eliminate the possibility of accidentally
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
sin
in-public.zone";
};
};
3. Now imagine that in addition to that Primary NS I have my own
Secondary NS that uses the same configuration (three views) and two
external Secondary NS, not managed by me that should use only mydomain-
public.zone for all queries. The problem is ho
match clients { any; };
zone "mydomain" in {
type master;
file "mydomain-public.zone";
};
};
3. Now imagine that in addition to that Primary NS I have my own
Secondary NS that uses the same configuration (three views) and two
exter
> :-)
>
> 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 a
:-)
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. Tr
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
:-)
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, serv
On 10/21/2024 9:35 AM, Bowie Bailey via bind-users wrote:
On 10/18/2024 6:19 PM, Nick Tait via bind-users wrote:
On 19/10/2024 05:50, Bowie Bailey via bind-users wrote:
On 10/18/2024 12:07 PM, Bob Harold wrote:
On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users
wrote:
The seco
On 10/18/2024 6:19 PM, Nick Tait via bind-users wrote:
On 19/10/2024 05:50, Bowie Bailey via bind-users wrote:
On 10/18/2024 12:07 PM, Bob Harold wrote:
On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users
wrote:
The first issue is that my server uses a few views to give
Bowie Bailey via bind-users wrote:
> The first issue is that my server uses a few views to give different IPs
> based on which network the request comes from. I found that if I point
the
> zones in the different views to the same key directory, there are no
errors
You can’t do this. The signatures are unique per zone and thus the files need
to be unique as well. Just write a small provisioning on your side that
duplicates the files.
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligate
rst issue is that my server uses a few views to give
different IPs
based on which network the request comes from. I found that if I
point
the zones in the different views to the same key directory, there
are no
errors and all views return the same keys when I test wi
an into a couple of issues.
>>
>> I am using the recommended setup with the "dnssec-policy default" and
>> "inline-signing yes".
>>
>> The first issue is that my server uses a few views to give different IPs
>> based on which network
ned. However, after
>>> doing a bit more testing I ran into a couple of issues.
>>>
>>> I am using the recommended setup with the "dnssec-policy default" and
>>> "inline-signing yes".
>>>
>>> The first issue is that my ser
the keys are being returned. However, after
doing a bit more testing I ran into a couple of issues.
I am using the recommended setup with the "dnssec-policy default" and
"inline-signing yes".
The first issue is that my server uses a few views to give
differ
being returned. However, after
> doing a bit more testing I ran into a couple of issues.
>
> I am using the recommended setup with the "dnssec-policy default" and
> "inline-signing yes".
>
> The first issue is that my server uses a few views to give different IP
setup with the "dnssec-policy default" and
"inline-signing yes".
The first issue is that my server uses a few views to give different IPs
based on which network the request comes from. I found that if I point
the zones in the different views to the same key directory, ther
lexible as possible for
individual corporate customers. Nowadays loading zones with millions of
rpz domains with ixfr takes a long time on platinum-xeon on a single
view where bind 9.18* is not very responsive. Yes this deserves a single
lab test for e.g. 2 or 3 views and see if loading time varie
On 25. 08. 24 9:20, Greg Choules via bind-users wrote:
Regarding view selection, I don't know exactly how the code works or how
efficient it is. But certainly I have seen some configs with a lot of
views and they seem to function OK.
Views are matched one by one, you can have a lo
Hi Grant.
That doesn't work for zones that then get used in a `response-policy`
block. In this case you *must* define a zone §each time; so one (or up to
64) per view/instance of `response-policy`. Test it on your laptop/in a VM.
What this does mean is that (if you are using views) you *
On 8/24/24 07:37, Carlos Horowicz via bind-users wrote:
2. if RPZ records are held in memory, why would an RPZ zone need to be
stored n times if there are n orthogonal views ? That is, why the more
views the more memory needed. Maybe you meant the qpcache, to store
different answers, though I
although
a hardware implementation could probably cost under a hundred dollars,
it may sound rather like a sledgehammer to crack this particular nut.
I wondered to myself if there might be any mileage in using something
like Docker to provide per-client resolver instances instead of using
multiple BIN
Hi Greg,
thanks for your insights.
Ok so the limit of 64 response policy zones applies to one view.
I wonder, assuming the views are orthogonal (no overlapping of CIDRs, as
in an ISP assigning CIDRs to local loops):
1. is there an algorithm in bind9 or out there that quickly maps a
client
Hi Carlos.
If you have enough RAM it should be possible to create multiple views, each
with a zone (primary or secondary, up to you) that contains the RPZ data
for that view and a response-policy that uses that zone.
The limit on number of zones is per response-policy block. But if you're
the case that I start treating provisioned CIDRs from customers as a base
for views, does bind9.18.* support a huge number of views with different rpz
zones activated per view ?
I recall having read in the documentation about a limitation of 64 rpz zones in total, is
this a number that can be
the case that I start treating provisioned CIDRs from customers as
a base for views, does bind9.18.* support a huge number of views with
different rpz zones activated per view ?
I recall having read in the documentation about a limitation of 64 rpz
zones in total, is this a number that can be
out paying the overhead of
loading multiple times the same RPZ. With 8 different RPZ, there are 256
combinations (views) and the memory overhead would be RPZx128!
I wonder about librpz and dnsrps. The source is quite difficult and
opaque, and I see no documentation anywhere beside a passing
02:38, Jesus Cea wrote:
>
> My RPZ zones are quite big, and I would like to be able to reuse them in
> several views sharing the memory instead of independent data structures.
>
> I thought that zone "in-view" would work, but it doesn't.
>
> I am doing s
My RPZ zones are quite big, and I would like to be able to reuse them in
several views sharing the memory instead of independent data structures.
I thought that zone "in-view" would work, but it doesn't.
I am doing something like:
"""
view honeypot {
match-cl
On 15. 05. 24 17:21, Peter Carlson wrote:
As I understand it bind_dlz does not support multiple views, I have to
following scenario and am trying to figure out how to configure it:
* Internal (192.168.10.0/24)
o resolve internal domain xyz.com
o resolve internal samba domain
As I understand it bind_dlz does not support multiple views, I have to
following scenario and am trying to figure out how to configure it:
* Internal (192.168.10.0/24)
o resolve internal domain xyz.com
o resolve internal samba domain xyz.lab
o resolve single address xyz.3cx.us
Hello,
How can I configure BIND9 to reply to requests from DNS-over-HTTPS with
view A, and if the requests is from normal DNS on port 53, reply with
view B?
Example:
client 192.168.1.5 requests A record test.example.com with DNS over
HTTPS, BIND should reply with view A
client 192.168.1.5
Thanks all for the responses and guidance.
This is just me doing some tweaky things with a few local bind servers with
systems on multiple vlans trying to properly resolve traversing multiple
subnets and thinking I could leverage views for something it wasn't meant
for [but I think would be
Hi.
Ah, I got the networks the wrong way round.
Sorry, it wasn't until I saw Sten's response that it occurred to me that
not everyone knows how views work. Indeed a query will be tested against
each view, top down. If it satisfies the criteria for a view (either/both
match-clients
On 6/29/23 6:44 AM, Matus UHLAR - fantomas wrote:
bind has "sortlist" statement that could do what you want. It will
provide all IPs but sorted differently.
+1 to "sortlist". I couldn't remember the exact nomenclature nor how it
was used.
Otherwise, you can s
-policy {
grant ddns-key wildcard *.20.32.10.in-addr.arpa PTR;
};
};
zone "30.32.10.in-addr.arpa" {
type master;
forwarders {};
file "/var/lib/bind/db.30.32.10.in-addr.arpa";
update-policy {
grant ddns-key wildcard *.30.32.10.in-addr.arpa PTR;
};
};
I now realize
Hi Ubence.
That is starting to get complex!
Firstly, yes BIND parses views top down, so order matters.
Secondly, most specific domain wins (like more specific routes).
I now see that you have created three levels of zones:
domain.com
lab.domain.com
system.lab.domain.com
This config looks like
{ any; }.
Please remember that ONLY ONE view is matched. Your main view is only used if
none of the other views match.
>
> What I didn't mention in my original post was that I have other subnets
> configured for this remote host through vlans with different IP addresses.
>
st through vlans with different IP addresses.
That's why there are so many other views. I was hoping the match-clients
per each view would return the appropriate IP address per subnet making the
request.
include "/etc/bind/rndc.key";
include "/etc/bind/ddns-key.key";
view
wise, you can set up multiple views with different versions of the same
zone, configured to provide different verision according to source IP.
This is much harder to set up.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail adverti
Hi Ubence.
Firstly, may we see your configs please. It's impossible to say exactly
what's going on from a human description.
Secondly, views and different answers. Yes it *is* entirely possible to use
views to provide answers based on client IP - `match-clients. I would start
wit
ause the domain
name lab.domain.com is a higher priority than domain.com even with the
system.lab tacked onto the primary domain.
I started dabbling with views and tried to set up specific views that would
return a fully qualified hostname as a domain based on what network the
request came from. If t
Hi Carsten.I've been running split views with a DNSSEC zone using dnssec-policy
for at least a couple of years.I'm using a CSK (i.e. combined KSK+ZSK) and
haven't yet worked out the best way to automate key rollover wrt DS in parent
zone, so my key rollovers are manual currentl
Hi Carsten,
We did have some bugs in the past when it comes to sharing keys with
dnssec-policy among different views. But the last one is from a year ago
(fixed in 9.16.19).
So while I don't have experience myself with a similar setup, we did
have some bug reports that used dnssec-p
Hi,
(please do not start a discussion on the usefulness of views. I'm not in favor
of views, but sometimes I have to work with them).
I have a client that runs a split horizon (internal / external view of the same
domain namespace) setup with BIND 9 on Linux.
Both the internal and ext
Hi E R.
My short answer would be, don't configure views unless you have a good use
case for them. For example you are running resolvers that have two
different kinds of clients that need to be handled differently - one client
set needs RPZ, the other doesn't. Or something like that.
New to BIND and just starting to read the 5th edition from O'Reilly after
watching some videos online while it made its way to me. I am trying to
understand why the view statement appears to be included by default in most
Linux distributions if best practice says you should have separate servers
f
; key-directory to be different.
>
> Best regards,
>
> Matthijs
>
>
>
> On 07-09-2022 15:19, Josef Vybíhal wrote:
> > Hello all,
> > I am consolidating our old split DNS consisting of internal and
> > external dedicated servers(VMs) into one primary serve
al and
external dedicated servers(VMs) into one primary server with views
(there will be secondaries, but they are not important to the
question). The old previous configuration is using inline-signing and
auto-dnssec. I will be switching to dnssec-policy with csk. This is
fine.
My question is what woul
Hello all,
I am consolidating our old split DNS consisting of internal and
external dedicated servers(VMs) into one primary server with views
(there will be secondaries, but they are not important to the
question). The old previous configuration is using inline-signing and
auto-dnssec. I will be
Jiri Hromadka wrote:
>
> Is there any way to reuse already loaded rpz zone in memory for other
> views ? I know in-view is not an option for rpz, using one master /
> slave zones has same memory effect.
Yeah, in-view would be perfect, if only :-)
You might try setting up a view th
Hi,
I’ve read many archived mails here and I haven’t found solution / answer, so
let me ask you guys.
I’m running Bind 9.11+ and using views for around 10 clients on single server,
all clients has different settings and everything was working great, until
we’ve decided to implement RPZ for
Well! That was the quickest & simplest WORKING solution I have ever
received from a mailing list! Thank you!
On 2021-07-05 17:55, Mark Andrews wrote:
If you want the content to be the same in both views and to be dynamically
updatable then use
view view1 {
zone example
If you want the content to be the same in both views and to be dynamically
updatable then use
view view1 {
zone example.com {
type primary;
[ allow-update / update-policy ] { … };
…
};
};
view view2 {
zone example.com { in
Currently running Bind v9.11.4:
Several years ago, I implemented multiple VIEWs using (almost) the exact
example in the Reference Manual. However, I wanted the
"example-internal.db" and "example-external.db" to be the same file.
This worked until I wanted to have &quo
Hi Graham,
On 2/29/20 5:27 PM, Graham Clinch wrote:
> How does the new-in-9.16 dnssec-policy interact with views - in
> particular for key generation/rollover?
>
> For example, we have a zone defined in multiple views with different
> contents (and thus not suitable for in-view),
How does the new-in-9.16 dnssec-policy interact with views - in
particular for key generation/rollover?
For example, we have a zone defined in multiple views with different
contents (and thus not suitable for in-view), being signed by the same
set of keys (currently maintained by dnssec
to resolve the same name
(let's call it "gateway") to the address of their interface on Router.
So that is, hosts on Network 1 want a query of "gateway." to resolve
to 192.168.1.254 and hosts on Network 2 want a query of "gateway." to
resolve to 192.168.2.254.
olve the same name
> (let's call it "gateway") to the address of their interface on Router.
> So that is, hosts on Network 1 want a query of "gateway." to resolve to
> 192.168.1.254 and hosts on Network 2 want a query of "gateway." to
> resolve to
m.
> What I am looking for is a way to save the duplicate copying of Network
> 3 resources to the views for Network 1 and Network 2. This is where
> the term "overlay" comes in. What I'd like to do is reference a single
> copy of data from Network 3 in Network 1 and 2
to resolve to
192.168.1.254 and hosts on Network 2 want a query of "gateway." to
resolve to 192.168.2.254.
So this is currently all achievable through "views" in BIND 9, but
requires that the zone data for each view be 98% duplicate (Network 3
resources) and continually copy-n-pas
Thanks a lot !!!
El jue., 15 ago. 2019 a las 13:09, Matus UHLAR - fantomas (<
uh...@fantomas.sk>) escribió:
> On 15.08.19 12:18, Roberto Carna wrote:
> >Dear, I have a BIND 9 working with two views.
> >
> >One view forwards two public domains to our resolver.
> >
On 15.08.19 12:18, Roberto Carna wrote:
Dear, I have a BIND 9 working with two views.
One view forwards two public domains to our resolver.
And I want the second view to forward any public domain to our resolver in
order to let navigate withouth restrictions.
what restricions and where are
Dear, I have a BIND 9 working with two views.
One view forwards two public domains to our resolver.
And I want the second view to forward any public domain to our resolver in
order to let navigate withouth restrictions.
I need something like this:
zone "ANY" {
ty
Dear people, finalla I could put to work my zone transfers.
I have review my config one more time and I am using one TSIG key for each
view.
Thanks a lot, regards!!!
El jue., 4 jul. 2019 a las 9:38, Tony Finch () escribió:
> Roberto Carna wrote:
> >
> > As I have shown above,
Roberto Carna wrote:
>
> As I have shown above, I use two views with a TSIG key for each view, but
> the zone transfer doesn't work.
The redacted config you posted did not consistently use key one in view
one and key two in view two. I don't know if your real config has the
Dear, thanks for your help.
As I have shown above, I use two views with a TSIG key for each view, but
the zone transfer doesn't work.
Please can you send me your Bind views configuration if you can, on master
and slave sides?
Thanks a lot again.
Regards!!!
El mié., 3 jul. 2019 a las
On 03/07/2019 22.14, Grant Taylor via bind-users wrote:
> On 7/3/19 2:04 PM, Lightner, Jeffrey wrote:
>> You have to use separate IPs for the separate views on the master and
>> the slave.
>
> I thought you could use different TSIG keys to identify different
> zones with
On 7/3/19 2:04 PM, Lightner, Jeffrey wrote:
You have to use separate IPs for the separate views on the master and
the slave.
I thought you could use different TSIG keys to identify different zones
with a single IP at each end.
Is that not the case?
--
Grant. . . .
unix || die
You have to use separate IPs for the separate views on the master and the slave.
Here we just put alias IPs on the primary interfaces and use those for the
second view.
From: bind-users On Behalf Of Roberto Carna
Sent: Wednesday, July 03, 2019 3:21 PM
To: ML BIND Users
Subject: Bind 9 with
Hi people, I have a master/slave Bind 9.10.3 servers configured with views
and TSIG keys on a Debian 9 host. But the transfer from master to slave is
refused in the slave side, there is no a descriptive error.
In both Views I have delegated the same two zones: black.com and white.com,
with
test).
Am I missing something here? Is it not possible to define multiple views with
different destination ports?
Stuart
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users
On 11/12/2018 04:57 AM, Sabri MJAHED (VINC) wrote:
Hi all,
Hi,
I want to have the same zone on multiple views, but i didn't find any
solution that ease the use of this.
I would think that the zone's "in-view" statement would do what you want.
I don't want to make
Sabri MJAHED (VINC) wrote:
>
> I dont have the -l option on the named-checkconf command.
>
> My version of bind is 9.11
Oh, it seems you need 9.12.
Your other option is to parse a zone list out of your other config files
with a bit of perl, which is what I did previously.
Tony.
--
f.anthony.n.
Hi Tony,
I dont have the -l option on the named-checkconf command.
My version of bind is 9.11
Sabri.
On 12/11/2018 13:09, Tony Finch wrote:
Sabri MJAHED (VINC) wrote:
I want to have the same zone on multiple views, but i didn't find any solution
that ease the use of this.
I have sc
BIND Users
Subject: TSIG error with BIND9 Views
Hi people, I've implemented a BIND9 service wit two views, and only one key for
TSIG.
The primary and secondary server start OK, but the transfer doesn't work
because in the bind.log from secondary server I can see "TSIG error".
Hi people, I've implemented a BIND9 service wit two views, and only one key
for TSIG.
The primary and secondary server start OK, but the transfer doesn't work
because in the bind.log from secondary server I can see "TSIG error".
Do I have to use one Key for the first view and
Sabri MJAHED (VINC) wrote:
> I want to have the same zone on multiple views, but i didn't find any solution
> that ease the use of this.
I have scripts that generate in-view configurations. In order to make
these scripts easier to write, I contributed the `named-checkconf -l`
fe
Hi all,
I've been working with bind for a bit of time, but here is a new problem.
I want to have the same zone on multiple views, but i didn't find any
solution that ease the use of this.
I don't want to make 3 file of zone conf with multiple in-view statements.
Here is the se
Okay,
I followed exactly like this -
https://kb.isc.org/article/AA-00851/0/Understanding-views-in-BIND-9-by-example.html
And it just worked. So I can do fine-tune now. Thanks guys.
Eoin
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Eoin Kim
Sent: Saturday, 9 December
Thanks guys. Let me play a bit and see how it goes. Cheers.
Eoin
From: Matthew Pounsett
Sent: Saturday, 9 December 2017 9:29 AM
To: Eoin Kim
Cc: Lightner, Jeffrey; bind-users@lists.isc.org
Subject: Re: [Question] zone transfer issue with multiple views
On 8
On 8 December 2017 at 17:37, Eoin Kim wrote:
> Hi,
>
>
> Thanks for your help. But is it possible to do it without additional IP
> address? I thought that I am not really bad with BIND but as soon as I
> started using views, I'm going nowhere [image: 😊]
>
>
> In
Hi,
Thanks for your help. But is it possible to do it without additional IP
address? I thought that I am not really bad with BIND but as soon as I started
using views, I'm going nowhere [😊]
I found related links:
*
https://kb.isc.org/article/AA-00851/0/Understanding-views-in-B
: RE: [Question] zone transfer issue with multiple views
When we did it here we setup separate notify-source and transfer-source within
the views on both the master and the slave.
view "internal" {
match-clients { internaldns; };
notify-source 10.9.9.8.;
transfer-source 10.9.9.8;
allo
When we did it here we setup separate notify-source and transfer-source within
the views on both the master and the slave.
view "internal" {
match-clients { internaldns; };
notify-source 10.9.9.8.;
transfer-source 10.9.9.8;
allow-transfer { dnsservers; };
...then our zones for int
Hi all,
I wonder if anyone can help me find the cause of the problem I am currently
having. I am testing BIND with two views - internal, external. Everything seems
okay except for one thing - zone transfer doesn't look happening for reverse
zone for external view. On my slave server, I ca
I think it's sorted, thanks all.
-Kevin
From: "Tony Finch"
To: bind-us...@isc.org
Sent: Wednesday, November 1, 2017 2:50:32 AM
Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
Mark Andrews wrote:
>
> More correctly _tcp.mail.thesandiego
Mark Andrews wrote:
>
> More correctly _tcp.mail.thesandiegos.com is delegated to
> ns1._tcp.mail.thesandiegos.com (75.149.33.153) but the machine is
> not configured to serve that zone.
This also explains the puzzling check-names problem earlier -
ns1._tcp.mail.thesandiegos.com is a host name (b
In message <1509508757.25100.19.ca...@ns.five-ten-sg.com>, Carl Byington writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Tue, 2017-10-31 at 17:16 -0700, Kevin via bind-users wrote:
> > $ dig TLSA _25._tcp.mail.thesandiegos.com @75.149.33.153 +dnssec
> > +short
> >
>
> > I'm r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2017-10-31 at 17:16 -0700, Kevin via bind-users wrote:
> $ dig TLSA _25._tcp.mail.thesandiegos.com @75.149.33.153 +dnssec
> +short
>
> I'm really at a loss as to what's going on inside of Bind.
dig TLSA _25._tcp.mail.thesandiegos.com @75.1
- Original Message -
> From: "Warren Kumari"
> To: "Kevin"
> Cc: "bind-users"
> Sent: Tuesday, October 31, 2017 12:47:06 PM
> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
> So, can you confirm that you a
uot;Kevin"
>> To: "Kevin"
>> Cc: "Warren Kumari" , "bind-users"
>>
>> Sent: Tuesday, October 31, 2017 12:33:56 PM
>> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
>
>> - Original Message
- Original Message -
> From: "Kevin"
> To: "Kevin"
> Cc: "Warren Kumari" , "bind-users"
>
> Sent: Tuesday, October 31, 2017 12:33:56 PM
> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
> --
- Original Message -
> From: "Kevin"
> To: "Warren Kumari"
> Cc: "Kevin" , "bind-users"
>
> Sent: Tuesday, October 31, 2017 12:18:41 PM
> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
> Fro
From: "Warren Kumari"
To: "Kevin"
Cc: "bind-users"
Sent: Tuesday, October 31, 2017 11:28:58 AM
Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users
wrote:
> I'm running int
On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users
wrote:
> I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a
> scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash
> script that executes the following nsupdate batch commands which are
> directed to
I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a
scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash
script that executes the following nsupdate batch commands which are directed
to a Bind "view" that is accessible from the wider internet:
server
On Tue, Jul 4, 2017 at 4:10 AM, Matthias Seitz
wrote:
> Hi,
>
> after a couple of test runs it looks like that multiple RPZs in multiple
> views works fine, example code snippet bellow (for better understanding)
>
> view "view1" {
> ...
>
> r
Hi,
after a couple of test runs it looks like that multiple RPZs in multiple
views works fine, example code snippet bellow (for better understanding)
view "view1" {
...
response-policy {
RPZ Feed 1
RPZ Feed 2
RPZ Feed 3
}; };
view "view2" {
1 - 100 of 534 matches
Mail list logo
