Am 12.09.2019 um 17:39 schrieb Roberto Carna:
Hi people, is it possible to setup BIND in order to implement GSLB
(Global Service Load Balancing) between two sites ?
I need a near Active-Active scenario between two datacenters in
different locations, and I want to do this with an open source so
Gotcha :)
On Wed, Oct 2, 2019 at 10:41 PM Vadim Pavlov wrote:
> You didn’t get the sarcasm in the previous email :)
> The issue is that you can not 100% block DoH w/o blocking HTTPs. You may
> block well-known domains and IPs but there are many unknown and for
> targeted attacks new servers can
You didn’t get the sarcasm in the previous email :)
The issue is that you can not 100% block DoH w/o blocking HTTPs. You may block
well-known domains and IPs but there are many unknown and for targeted attacks
new servers can be created even behind legit (but compromised) websites.
Vadim
> On O
On Wed, 2 Oct 2019 at 18:04, Blason R wrote:
>
> Block 443? Not even possible since most of the portals/web servers now a
days works on TCP/443
>
Pretty sure that's what he meant when he said: "This method of controlling
DoH may have side-effects."
___
Block 443? Not even possible since most of the portals/web servers now a
days works on TCP/443
On Wed, Oct 2, 2019 at 6:57 PM Alan Clegg wrote:
> On 10/2/19 8:00 AM, Blason R wrote:
> > Hmm that is a good idea to block the DOH queries but what I understood
> > is blocking on perimeter level woul
If I'm reading this correctly, it looks like delegation DOES work from the
slave.
Looking at the zone file for sub.example.org. from the main DNS server, is
the delegation present for dyn.sub.example.org.? (e.g. is there a
dyn.sub.example.org. IN NS dynsub.example.org. in the zone file for
sub.exa
On 10/2/19 8:00 AM, Blason R wrote:
> Hmm that is a good idea to block the DOH queries but what I understood
> is blocking on perimeter level would be more appropriate.
To nullify the abilities of DoH, you can block port TCP/443.
That is pretty much guaranteed to keep DoH from working, but you ma
Hmm that is a good idea to block the DOH queries but what I understood is
blocking on perimeter level would be more appropriate.
On Wed, Oct 2, 2019 at 4:58 PM Daniel Stirnimann <
daniel.stirnim...@switch.ch> wrote:
> You cannot block DoH with RPZ but you can block bootstrapping DoH if the
> web
Hi all,
I have an internal domain with a subdomain that I now have being
dynamically updated (thanks).
For the purposes of documentation I shall use: sub.example.org
The main DNS server in the network (i.e. the one everyone queries) is set
as a slave to my server for the example.org domain.
Trans
Hi Blason,
depends on what you mean by “DoH”
You can disable the Mozilla automatic bootstrap with RPZ:
https://kb.isc.org/docs/using-response-policy-zones-to-disable-mozilla-doh-by-default
That’s the most lightweight option.
The most heavyweight would be a transparent MITM HTTPS proxy/firewal
You cannot block DoH with RPZ but you can block bootstrapping DoH if the
web browser is configured to use "normal" DNS to lookup the DoH
endpoint. See also:
https://github.com/bambenek/block-doh
Daniel
On 02.10.19 13:23, Blason R wrote:
> Hi Folks,
>
> Wondering if anyone has any clue or defini
Hi Folks,
Wondering if anyone has any clue or defining policies for blocking DoH [DND
Over HTTPS] traffic using bind RPZ feature?
Does anyone have any use case about it?
Thanks and Regards,
Blason R
___
Please visit https://lists.isc.org/mailman/listin
As promised...
I now have this close enough to working as makes no odds for me ;)
There were a few bumps along the way, in particular Jan-Piet Mens says in
this (rather old, but still top hit in google) blog post:
https://jpmens.net/2011/07/06/execute-a-script-when-isc-dhcp-hands-out-a-new-lease/
Hi John,
I came to similar example and wanted possible names also under developer
namespace. Something like dev1.user.example.org, you could add to zone
user.example.org:
dev1.user.example.org. IN NS dev1.example.org.
Then configure dev1 like Ondřej suggested, set dev1.example.org IP from
DHCP.
14 matches
Mail list logo
