On 2010-10-26 00:39, The Doctor wrote:
> My question is how can you detect if a DSN / Domain name
> has been 'poisoned'?
By using DNSSEC
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Zitat von The Doctor :
My question is how can you detect if a DSN / Domain name
has been 'poisoned'?
Compare what your cache deliver with results from other sites. To
prevent cache poison you might use DNSSEC if the zones which are
affected support it and at least use a recent Resolver wit
On 21.10.10 15:51, Martin McCormick wrote:
> The problem was that named.conf.keys was owned by root
> instead of bind. I have an #include statement in named.conf to
> read in the file so there is where the permission problem was
> and the log tells you quite nicely what line number in
> named
On 25.10.10 16:39, The Doctor wrote:
> My question is how can you detect if a DSN / Domain name
> has been 'poisoned'?
quitye hard if it's already been done. You can see what it contains and
compare it with what is should contain, but you never know if the incorrect
data didn't come from misconfig
Ah, the wonderful world of high stakes no-return upgrades!
I turned on a new installation of bind9.7.1 after
running it in slave mode for a few days and:
26-Oct-2010 07:30:46.497 zone 78.139.IN-ADDR.ARPA/IN: refresh:
skipping zone transfer as master 139.78.100.1#53 (source 0.0.0.0#0) is
On 10/26/2010 8:45 AM, Martin McCormick wrote:
> 26-Oct-2010 07:30:46.497 zone 78.139.IN-ADDR.ARPA/IN: refresh:
> skipping zone transfer as master 139.78.100.1#53 (source 0.0.0.0#0) is
> unreachable (cached)
Are you able to "dig @139.78.100.1 78.139.IN-ADDR.ARPA axfr" when logged
into the slave
Alan Clegg writes:
> Are you able to "dig @139.78.100.1 78.139.IN-ADDR.ARPA axfr" when logged
> into the slave?
No and your diagnosis was spot on.
> It seems that communications between the slave (which we don't know the
> IP address of) and the server at 139.78.100.1 is broken.
Oh, yes!
If we talk about checking after suspected poisoning, my best idea is:
dump the cache, then flush the cache and do the lookups again and
compare to the cache-dump. Any difference is suspicious and should be
looked closer upon.
The cure is BTW also to flush the cache of the fake info.
Remember tha
Dear List,
Is is possible to limit the number of recursion/queries per IP address.
there is some kind of virus thats bombarding my dns servers with a lot
of queries, i realize that when ever the total number of recursion
clients reach 1000 dns resolution stop working. i have increase the
recursive
What version of bind, on what OS?
There may be some things you can do with iptables to limit connections
http://www.debian-administration.org/articles/187
I don't recall seeing anything native to BIND that would allow for limits per
src.
t.
-Original Message-
From: bind-users-bounces+
On Tue, 2010-10-26 at 15:22 -0400, Todd Snyder wrote:
> What version of bind, on what OS?
>
I use Debian 5.0 with bind 9.6-ESV-R1 but also i thought that the OS
might have some security holes so i try FreeBSD 8.1 with BIND 9.7.1 but
still have ihave the same problems.
> here may be some things yo
iptables is available in most Linux distros and it is definitely better
to block things there than in BIND itself.
I don't know that BIND has a rate limiter. It DOES have a "blacklist"
option where you can completely block a site's access to it but as noted
above it is better to do it in iptables
12 matches
Mail list logo
