> Has anyone else tried to communicate with TSIG using HMAC-SHA224 between
> BIND and other DNS implementations?
We've recently found out about an interoperability flaw affecting all the
HMAC-SHA* algorithms; it affects any key with a secret longer than the
digest length of the algorithm (which i
Greetings.
Has anyone else tried to communicate with TSIG using HMAC-SHA224 between
BIND and other DNS implementations?
I'm using Perl's Net::DNS and BIND 9.6.1p2 and I'm able to sign messages
with TSIG using HMAC-MD5, HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, and
HMAC-SHA512 successfully. But HM
On Fri, 8 Jan 2010, Chris Thompson wrote:
On Jan 8 2010, Rick Dicaire wrote:
Hi folks, whats the difference between recursion no; and
allow-recursion {none;};
Not a great deal, but "recursion no;" changes the default for
"empty-zones-enable" to "no", while "allow-recursion {none;};"
doesn't
Hi :)
While I agree with you that 4096 should be sufficient (what is your definition
of a highly loaded server?), there are a couple of situations where a server
might use more sockets than it would normally use:
1. DOS attack
2. Higher latency while trying to resolve recursion queries.
3. A se
On Jan 8 2010, Rick Dicaire wrote:
Hi folks, whats the difference between recursion no; and
allow-recursion {none;};
Not a great deal, but "recursion no;" changes the default for
"empty-zones-enable" to "no", while "allow-recursion {none;};"
doesn't do that. (Probably there are other niggling
Ok I think I've figured this out as I did a little test to change the IP
within the remote authoritative DNS server to 172.16.1.100.
of course there is no machine at that IP address within my networks but
there was some address confusion as the DNS server had the same IP
address as the rad
Ok I will try to explain with a diagram as I'm pretty certain that still
no one gets what I'm on about:
+-+
+-
At Tue, 5 Jan 2010 10:00:34 +0100,
Marinescu Paul dan wrote:
> bind (9.6.1-P2) dies when one tries to retrieve statistics via HTTP
> from the statistcs-channel feature if an underlying call to libxml
> fails (returns a NULL pointer) at statschannel.c:720 - writer =
> xmlNewTextWriterDoc(&doc, 0);
At Tue, 05 Jan 2010 08:24:16 +0100,
Dario Miculinic wrote:
> I dont't have the same core dump, but this is from one that happend yesterday:
Thanks, but unfortunately the detailed stack traces don't seem to
provide a useful hint for the race.
If you can help debug this further, could you apply t
9 matches
Mail list logo
