On Sun, Jun 17, 2018 at 07:10:11PM +, Nicolas Breuer wrote:
> I’m not using the in-view.
> So, per default this is copied into memory
> In case of failure of primary the slave can take the lead but in case of
> a reboot, the slave will not download the copy
I think I'd have to see your config
Hi Evan,
I’m not using the in-view.
So, per default this is copied into memory
In case of failure of primary the slave can take the lead but in case of a
reboot, the slave will not download the copy
If using file option, i should use in-view and then duplicate the zone files.
The goal to have
On Sun, Jun 17, 2018 at 05:32:34PM +, Nicolas Breuer wrote:
> I have removed the file option in the zone configuration and I can now share
> the same zone on the two views.
> I suspect the zone to be transferred in the memory
If you're using "in-view", the zone isn't transferred at all.
On 06/17/2018 11:48 AM, Blason R wrote:
Excellent Inputs guys and thanks a ton for your feedbacks.
You're welcome.
RPS is quite interesting and which one is commercial offering for
the same?
The best (read: quick) I have is Paul Vixie's email to OARC's
DNS-Operations mailing list.
Link
Excellent Inputs guys and thanks a ton for your feedbacks. RPS is quite
interesting and which one is commercial offering for the same?
On Sun, Jun 17, 2018 at 10:56 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 06/17/2018 11:18 AM, Vadim Pavlov via bind-users wrote:
> >
Hello All,
I have been migrated from Bind 9.8 to 9.11
Some big changes on the new version.
I have a zone file common for two views (one internal & one with recursion ON)
I have removed the file option in the zone configuration and I can now share
the same zone on the two views.
I suspect the
On 06/17/2018 11:18 AM, Vadim Pavlov via bind-users wrote:
Just to be more clear. DNSSEC records can contain any content and can
be used for infiltration/tunneling.
Ah. I think I see.
E.g. If you request DNSKEY record (you can encode your request in fqdn)
you will get it exactly "as is".
Just to be more clear. DNSSEC records can contain any content and can be used
for infiltration/tunneling.
E.g. If you request DNSKEY record (you can encode your request in fqdn) you
will get it exactly "as is". Intermediate DNS servers do not validate the
records.
So instead of
On 06/17/2018 10:52 AM, Vadim Pavlov via bind-users wrote:
DNSSEC can be used for infiltration/tunneling (when you get data from a
DNS servers) but there is a catch that such requests can be easily dropped.
Will you please elaborate and provide a high level overview of how
DNSSEC can be used
On 06/17/2018 09:43 AM, Blason R wrote:
Can someone please guide if DNS exfiltration techniques can be
identified using DNS RPZ?
I don't think that Response Policy *Zone* can do what you want to do.
(I've often wondered about this my self and have spent some time
thinking about it.)
Or do
DNSSEC can be used for infiltration/tunneling (when you get data from a DNS
servers) but there is a catch that such requests can be easily dropped.
Vadim
> On 17 Jun 2018, at 09:44, Sten Carlsen wrote:
>
> Interesting, the Dnssec records with their by definition random and large
> content
Hi,
RPZ is just a simple feature to block/log/redirect DNS requests. It doesn't
analyse DNS requests & responses and a client behaviour.
So RPZ can block a domain which used for DNS Exfil/Infil/Tunneling but to
detect Exfiltration you should to use 3rd party tools/software (e.g. Infoblox
Interesting, the Dnssec records with their by definition random and
large content seems to be the most interesting vehicle, at least at
first sight.
Will e.g. the google DNS server or any other resolver deliver and fetch
this data? At the moment I can't think of any reason it should not do so.
Hi Team,
Can someone please guide if DNS exfiltration techniques can be identified
using DNS RPZ? Or do I need to install any other third party tool like IDS
to identify the the DNS beacon channels.
Has anyone used DNS RPZ to block/detect data exfiltration?
14 matches
Mail list logo
