On 2015-01-04 19:30, Chris Vaughan wrote:
I have been given the task of implementing DMARC in our BIND servers due the
recommendation of a security audit on our systems.
Whenever I create the record in the forward server, and refresh the zone, it
comes out in the slave zone with escape
On 24/12/14 17:08, Frank Bulk wrote:
Except queries from 96.31.0.5 and 199.120.69.24 reliably return the
while queries from 96.31.0.20 do not. And we're all the same ISP, and in
the one case, from the same /24. I don't think Google is that granular. And
we do have good IPv6 connectivity.
At Sat, 3 Jan 2015 19:24:47 +0100,
Christian Kette wrote:
I have found a workaround.
I defined a different zone for every network
A simpler solution might be to use a sortlist.
From the ARM:
6.2.16.13 The sortlist Statement
The response to a DNS query may consist of multiple resource
Dave Warren da...@hireahit.com wrote:
http://www.dmarc.org/faq.html#s_12 has some information on what is happening
here.
There is a fix for this which will be in the next 9.9 and 9.10 versions of
BIND.
Hello Niall,
thank you for the advice.
I will stay with my solution.
Never touch a running system ;)
I would consider this topic as closed by now.
If anyone with a similar question needs my assistance, I would be glad to
help
Thanks!
2015-01-05 18:27 GMT+01:00 Christian Hain
Yes,
I have read that part of the FAQ, which concerns people asking whether they
need to add escape characters manually in the DMARC record.
I do not add these myself. As shown by my examples below, the entry in the
master zone is free of any escape characters. However, when an update is
Running BIND 9.10.1-P1 on Mac OS X 10.10.1. It’s been running fine - no
problems until this morning, when I got:
06-Jan-2015 01:33:33.356 transfer of 'rpz.spamhaus.org/IN/external' from
199.168.90.51#53: Transfer completed: 1 messages, 486 records, 11827 bytes,
0.292 secs (40503 bytes/sec)
Phil,
I'm embarrassed that I didn't check that file earlier. Yes, those four DNS
resolvers sitting behind the load-balancer use 96.31.0.20:
mail1:~# dig -t txt o-o.myaddr.l.google.com +short
96.31.0.20
mail1:~#
It's been many moons since that backlist has been brought up, and when I
opened a
We use sortlists quite effectively, but there are some caveats to that approach:
1) If you have clients using rogue resolvers without any sortlist
definitions, that will limit the effectiveness of the technique somewhat
2) You need some discipline to keep the sortlist definitions up-to-date as
9 matches
Mail list logo
