Rich,
I suggest the following
minimal-responses yes; - set this global
blackhole { address_match_list }; - use the address_match_list file on
your pf.conf (freebsd)
with this combo, your bind should refuse queries when it's out-of-zone.
additional-from-auth yes;
additional-from-cache no;
good
On 1 February 2013 18:42, John Wobus wrote:
> On a secondary, the zone files in different views, even if identical, need
> to be
> distinct.
>
> Also, if you're allowing dynamical updating and the views need to serve
> identical
> versions of the zone, then you need to arrange things so the zone i
You can create 2 views "authorised" and "everyone else" which both
reference the same domain zone files so you dont need to duplicate the
zones.
On a secondary, the zone files in different views, even if identical,
need to be
distinct.
Also, if you're allowing dynamical updating and the view
As we've already pointed out it is something in the way your system is
configured (you're doing everything in global options instead of using
views to separate the different "classes" of users) and that you are
running both authoritative and caching functions on the same server.
You can create 2 v
The spoofed ip's are coming from the outside world as real legitimate IP's.
They are not coming internally and then heading outwards. We have to allow
port 53 traffic from the internet because we publish a dozen domains or so,
and also cache for our customers. The question is why does the server
re
You should be complying with BCP 38 [http://tools.ietf.org/html/bcp38]
for Inbound Network Filtering which will reduce a lot of unwanted
packets getting into your network.
Our inbound (Cisco) ACL looks like the following and I check up on the
bogon addresses
[http://www.team-cymru.org/Services/Bog
Hi, Richard,
I reject spoofed IPs more or less like this:
# Do some checks for obviously spoofed IP's
$IPT -t nat -A PREROUTING -i $INET_IFACE -s 127.0.0.0/8 -j DROP
$IPT -t nat -A PREROUTING -i $INET_IFACE -s 10.0.0.0/8 -j DROP
$IPT -t nat -A PREROUTING -i $INET_IFACE -s 172.16.0.0/12 -j DROP
$
On 1/31/13 7:05 PM, rich carroll wrote:
>
> antispoof log quick for em0 inet
>
> but that did not trigger on any of the requests.
This leads to nowhere in your specific case, check 'pfctl -sr' and the
docs[1] to learn how this rule expands.
[1] http://www.openbsd.org/faq/pf/filter.html#antispoof
Currently the box is running packet filter on freebsd.
I added:
antispoof log quick for em0 inet
but that did not trigger on any of the requests.
I am going to mess with views some time today, but if that doesn't stop
responses to requests from the outside, other then our domains, we will
move
One very simple question - do you filter spoofed IPs
at your firewalls?
And, BTW, a lot of other must be stuff, like ports 135-139 ...
(but that's another story)
Personally I reject spoofed IPs even without logging.
They are more then likely spoofed IP's and
someone is using our servers to atta
I think this is one of those reasons why mixing caching/recursion with
authoritative is bad.
I think the option needed is 'additional-from-cache no;', but its only
effective if 'recursion no' is done in global options ... or in a view?
Hmm, wonder if view is the answerperhaps try somethin
I'm not entirely sure about the "allow-query { any; };" option you
have configured in the main options section, by default bind allows
queries from all anyway, try removing this and see if that fixes the
issue, it could be having that set is somehow overriding some of the
other statements.
Steve
_
In message
, rich carroll writes:
>
> acl "trusted" {
> xxx.xxx.xxx.0/20;
> xxx.xxx.xxx.0/23;
> xxx.xxx.xxx.0/22;
> xx.xxx.xxx.0/23;
> xx.xxx.xxx.0/23;
> xx.xxx.xxx.0/23;
> x.xx.xxx.0/21;
> x.xx.xx.0/24;
> xxx.xxx.xxx.0/24;
> localhost;
> l
acl "trusted" {
xxx.xxx.xxx.0/20;
xxx.xxx.xxx.0/23;
xxx.xxx.xxx.0/22;
xx.xxx.xxx.0/23;
xx.xxx.xxx.0/23;
xx.xxx.xxx.0/23;
x.xx.xxx.0/21;
x.xx.xx.0/24;
xxx.xxx.xxx.0/24;
localhost;
localnets;
};
options {
// Relative to the chroot director
So the response you received wasn't recursed ";; WARNING: recursion
requested but not available", so at least that ACL is holding up, but
it could be that the response you got is still being served from your
DNS server's cache. Can you share the exact configuration statements
you have implemented f
Currently our ISP's bind9 server is experiencing a lot of traffic. It looks
like we are being used to attack ip addresses. We do have our own domains
that host as well as resolving for our customers.
I have an acl for our subnets and we allow-recursion and allow-query-cache
for those subnets. The
16 matches
Mail list logo
