Re: TR: Slave Zones for Bind 9.11

[Evan Hunt]

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 to understand.  But if you
had it like this:

view a {
   zone foo.com {
  type slave;
  masters { ... };
  file "filename";
  ...
   };
};

view b {
   zone foo.com {
   in-view a;
   };
   };

... then you'd have foo.com accessible within both views, and it will
be saved only once, in "filename".

> The goal to have two views is only to allow recursion on our internal ip’s.

If you don't have any zones that differ between your internal
and external views, then views are unnecessary. Just use
"allow-recursion { localnets; };" and external queries won't be
allowed to do recursion.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: TR: Slave Zones for Bind 9.11

[Nicolas Breuer]

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 two views is only to allow recursion on our internal ip’s.



> Le 17 juin 2018 à 21:04, Evan Hunt  a écrit :
> 
>> 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. There's a
> single copy of the zone in memory, and both views have pointers to it.
> You can still use the file option.
> 
> -- 
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: TR: Slave Zones for Bind 9.11

[Evan Hunt]

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. There's a
single copy of the zone in memory, and both views have pointers to it.
You can still use the file option.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Data exfiltration using DNS RPZ

[Grant Taylor via bind-users]

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 - [dns-operations] DNS RPS (response policy service) API
 - 
https://lists.dns-oarc.net/pipermail/dns-operations/2017-October/016860.html


I suspect that will give you a few threads to pull at.

I know that I've exchanged a few emails with Paul and he's always been 
quite helpful.  I beet he'd be happy to point you to his company's 
commercial product.




--
Grant. . . .
unix || die
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Data exfiltration using DNS RPZ

[Blason R]

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:
> > 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". Intermediate DNS servers do not
> validate
> > the records.
>
> You aren't talking about using the DNSSEC mechanisms to {in,ex}filtrate
> data as much as you are talking about {ab}using the resource records
> that DNSSEC uses as a vector to hide data.
>
> > So instead of "standard/usual" TXT records you can use DNSKEY to pass
> > data from a DNS remote server.
>
> ACK
>
> Thank you for the explanation.
>
>
>
> --
> Grant. . . .
> unix || die
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

TR: Slave Zones for Bind 9.11

[Nicolas Breuer]

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 zone to be transferred in the memory

The issue with that is if the primary goes down and if we restart the second 
DNS Server.
I want to write on disk but that will fail the sharing on the two views

Can we specify a dynamic file-naming ?
Is it the expected behavior ?

Thanks

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Data exfiltration using DNS RPZ

[Grant Taylor via bind-users]

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". Intermediate DNS servers do not validate 
the records.


You aren't talking about using the DNSSEC mechanisms to {in,ex}filtrate 
data as much as you are talking about {ab}using the resource records 
that DNSSEC uses as a vector to hide data.


So instead of "standard/usual" TXT records you can use DNSKEY to pass 
data from a DNS remote server.


ACK

Thank you for the explanation.



--
Grant. . . .
unix || die
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Data exfiltration using DNS RPZ

[Vadim Pavlov via bind-users]

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 "standard/usual" TXT records you can use DNSKEY to pass data from 
a DNS remote server.

Vadim
> On 17 Jun 2018, at 10:07, Grant Taylor via bind-users 
>  wrote:
> 
> 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 for infiltration or tunneling?
> 
> It is my understanding that DNSSEC is just a cryptographic hash that clients 
> can verify by calculating their own hash over the results for the same query. 
>  As such, nothing is actually hidden.  1) You know the outbound query, 2) you 
> know the inbound reply + DNSSEC signature, 3) you know the algorithm used to 
> generate the hash, and 4) you validate the DNSSEC signature.  So, what about 
> that is hidden?
> 
> I fail to see how DNSSEC can be a covert channel, even if there is 
> manipulation in what key is used.  Unless you're expiring & modifying the ZSK 
> about once a second so that you can change things and try to hide using 
> something like steganography.  Even then, I'm not sure how well that would 
> work.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Data exfiltration using DNS RPZ

[Grant Taylor via bind-users]

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 for infiltration or tunneling?


It is my understanding that DNSSEC is just a cryptographic hash that 
clients can verify by calculating their own hash over the results for 
the same query.  As such, nothing is actually hidden.  1) You know the 
outbound query, 2) you know the inbound reply + DNSSEC signature, 3) you 
know the algorithm used to generate the hash, and 4) you validate the 
DNSSEC signature.  So, what about that is hidden?


I fail to see how DNSSEC can be a covert channel, even if there is 
manipulation in what key is used.  Unless you're expiring & modifying 
the ZSK about once a second so that you can change things and try to 
hide using something like steganography.  Even then, I'm not sure how 
well that would work.




--
Grant. . . .
unix || die
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Data exfiltration using DNS RPZ

[Grant Taylor via bind-users]

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 I need to install any other third party tool like IDS to identify 
the the DNS beacon channels.


I don't think you need to replace BIND with another tool.

BIND has a relatively new feature called Response Policy *Service* that 
I think is well suited to this.


I think of BIND's RPS much like I do Sendmail's Milter or Cisco' WCCP, 
in that they provide a way for BIND (Sendmail, Cisco routers) to ask 
something else to do the filtering for them.


Queries come to BIND and it serves them mostly like normal with the 
exception being that it gives the RPS daemon an opportunity to do some 
more intelligent filtering.  The RPS daemon can (theoretically) do some 
analysis on the queries including number of queries (to a given 
(sub)domain), the length of the queries, the type and length of the 
reply, etc.


In short, RP*S* allows active processing to be done on the query.  Where 
as RP*Z* is only doing a simple textual match


BIND includes the RPS interface for other RPS daemons to interact with. 
I believe there is at least one commercial RPS daemon.  I'm not aware of 
any open source RPS daemons (yet).



Has anyone used DNS RPZ to block/detect data exfiltration?


I don't think that RPZ is a good candidate for this, given it's textual 
matching.  I do think that RPS will be a MUCH better match for this as 
it matures.




--
Grant. . . .
unix || die
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Data exfiltration using DNS RPZ

[Vadim Pavlov via bind-users]

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 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.
> 
> To really block this, I think you would need to actually verify the 
> correctness of the data.
> 
> On 17-06-2018 08.43, Blason R wrote:
>> 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?
>> 
>> 
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users 
>>  to unsubscribe from this 
>> list
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org 
>> https://lists.isc.org/mailman/listinfo/bind-users 
>> 
> 
> -- 
> Best regards
> 
> Sten Carlsen
> 
> No improvements come from shouting:
> 
> "MALE BOVINE MANURE!!!" 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Data exfiltration using DNS RPZ

[Vadim Pavlov via bind-users]

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 
Threat Insight).
+ do not forget that "qname-wait-recurse" should be switched off and a RPZ with 
such domains must be before (e.g. first) by order any zone which contains IP/NS 
based rules.

Vadim
> On 17 Jun 2018, at 08:43, Blason R  wrote:
> 
> 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?
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Data exfiltration using DNS RPZ

[Sten Carlsen]

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.

To really block this, I think you would need to actually verify the
correctness of the data.


On 17-06-2018 08.43, Blason R wrote:
> 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?
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Data exfiltration using DNS RPZ

[Blason R]

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?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users