BIND 9.7.7, 9.8.4 and 9.9.2 have "improved" OpenSSL error logging.
Unfortunately, our logs are now filling up with "RSA_verify failed" messages.
How does one go about tracking down the source of these failures and correcting
them? (We are running OpenSSL 1.0.1c.)
__
On 20.09.12 19:49, Oscar Ricardo Silva wrote:
The current servers are configured to forward any queries for our
domain straight to our authoritative servers:
I've been reading about the new zone type: static-stub and believe
this may work better for us.
If I'm correct, it will send non-rec
> BIND 9.7.7, 9.8.4 and 9.9.2 have "improved" OpenSSL error logging.
> Unfortunately, our logs are now filling up with "RSA_verify failed"
> messages.
Yeah, oops, we made that one too noisy. You're not the first one
who's noticed. :/
> How does one go about tracking down the source of these fai
On Oct 10 2012, Evan Hunt wrote:
BIND 9.7.7, 9.8.4 and 9.9.2 have "improved" OpenSSL error logging.
Unfortunately, our logs are now filling up with "RSA_verify failed"
messages.
Yeah, oops, we made that one too noisy. You're not the first one
who's noticed. :/
Also, without any indication o
hi all...
# uname -a
NetBSD ns2. 5.1 NetBSD 5.1 ...
# named -v
BIND 9.5.2-P2
i get these in the log:
Oct 10 16:15:09 ns2 named[29914]: client 156.154.62.145#19443: query
(cache) 'domain.net//IN' denied
Oct 10 16:15:09 ns2 named[29914]: client 156.154.62.145#29333: query
(cache)
On 10/10/12 20:01, kalin wrote:
hi all...
# uname -a
NetBSD ns2. 5.1 NetBSD 5.1 ...
# named -v
BIND 9.5.2-P2
i get these in the log:
Oct 10 16:15:09 ns2 named[29914]: client 156.154.62.145#19443: query
(cache) 'domain.net//IN' denied
Oct 10 16:15:09 ns2 named[29914]: client 156
On 10/10/12 9:17 PM, Lyle Giese wrote:
On 10/10/12 20:01, kalin wrote:
hi all...
# uname -a
NetBSD ns2. 5.1 NetBSD 5.1 ...
# named -v
BIND 9.5.2-P2
i get these in the log:
Oct 10 16:15:09 ns2 named[29914]: client 156.154.62.145#19443: query
(cache) 'domain.net//IN' denied
Oct
You have all those allow-*, but in your previous email you have
"recursion no;" which you would have to change to "recursion yes;".
When you have done this, make sure to restrict it with the allow-recursion
so you do not have an open resolver.
-- Arni
- Original Message -
From: "kalin"
On 10/10/12 9:41 PM, Árni Birgisson wrote:
You have all those allow-*, but in your previous email you have
"recursion no;" which you would have to change to "recursion yes;".
When you have done this, make sure to restrict it with the allow-recursion
so you do not have an open resolver.
th
On 10/10/12 20:52, kalin wrote:
On 10/10/12 9:41 PM, Árni Birgisson wrote:
You have all those allow-*, but in your previous email you have
"recursion no;" which you would have to change to "recursion yes;".
When you have done this, make sure to restrict it with the
allow-recursion
so you
Make sure you are editing the named.conf named is using. Change
the version string, reload the server and check that the version
reported matches what is in named.conf.
If that doesn't identify/fix the problem post, to the list, the
complete named.conf along with any included files (x out the ts
On 10/10/12 10:17 PM, Lyle Giese wrote:
On 10/10/12 20:52, kalin wrote:
On 10/10/12 9:41 PM, Árni Birgisson wrote:
You have all those allow-*, but in your previous email you have
"recursion no;" which you would have to change to "recursion yes;".
When you have done this, make sure to
On Oct 10, 2012, at 7:22 PM, kalin wrote:
> if i add a zone record to the named.conf i'm editing and do a dig on it,
> locally i get it fine:
>
> $ dig @ns2. domain.com
>
> ; <<>> DiG 9.8.1-P1 <<>> @ns2. domain.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>
13 matches
Mail list logo
