came back) in irregular
intervals.
After downgrading to 9.4.3, the problems were resolved, works without any
hassles.
I did not try the latest 9.5.1 version, however.
Daniel Ryslink
On Fri, 26 Sep 2008, Bart Van den Broeck wrote:
Rune Rune wrote:
Hi, I have compiled and used 9.5 on
upgrading to 9.6.2-p1, these very records are rejected by
the nameserver:
29-Mar-2010 09:33:59.371 config: error: itar.key:3: configuring trusted
key for 'ARPA.': algorithm is unsupported
Evidently, the RSA/SHA-256 support was removed from p1, but why? (...
accident?).
Daniel Rysli
Hello,
I have the following zone definition included into named.conf:
zone "example.com" in {
type master;
file "master/example.com";
update-policy local;
auto-dnssec maintain;
key-directory "/etc/namedb/keys/";
masterfile-format text;
inline-signing yes;
};
Keys are ready in /etc/namedb/keys/,
Hello,
It may or may not be relevant, but it sounds similar to a problem we had
to solve a few months ago. Try the following query analysis - monitor
the number of recursive queries in a given moment, and when it exceeds a
certain threshold, send "rndc recursing" to Bind and have a look on the
Hello,
I am sorry, but since I got under pressure to stabilize our main
resolver operation, I had to downgrade to BIND 9.9.6 which effectively
solved the problem (i.e. even with max-cache-size set to 0 [unlimited],
the amount of memory allocated by named reaches certain maximum and
remains s
One more comment - ad process size, I did measure the process sizes via
'top', and the excessive memory was really and without a doubt allocated
by named. While the machine has only 2GB of RAM, top reported named has
allocated much more than that, swap was in use and free swap was
steadily dimi
Hello,
First, you have to tell us if you wish to run and maintain an
authoritative DNS server (meaning a server propagating authoritative
information about your domain names), or a recursive caching nameserver
(a DNS server performing recursive queries on behalf of other client
devices [phone
Hello
Investigate if it's not related to the problems with EDNS0 support and
the fallback mechanism in Bind, as described in this article:
https://kb.isc.org/article/AA-01219/
It's described as one of the outstanding issues of both the latest
versions of bind 9.9 and 9.10:
Refinements to E
Hello
What uncle Google found for me:
http://www.bind9.net/BIND-FAQ
Quote:
"Q:
Why do I get the following errors:
general: errno2result.c:109: unexpected error:
general: unable to convert errno to isc_result: 14: Bad address
client: UDP client handler shutting down due to fatal receive error:
.com
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Daniel Ryslink
Sent: Wednesday, February 11, 2015 3:33 PM
To: bind-users@lists.isc.org
Subject: Re: Getting Error || unable to convert errno to isc_result
Hello
What uncle
Prefered procedure:
1) Install the ports collection via "portsnap fetch" and then "portsnap
extract" (or "portsnap update" if already installed)
2) Go to /usr/ports/dns/bind99 and type "make install"
Please note that after installing, you will have two versions of BIND on
your system:
- the
ublika
Tel.:+420.226204627
daniel.rysl...@dialtelecom.cz
---
www.dialtelecom.cz
Dial Telecom, a.s.
Jednoduše se připojte
---
On 03/30/2015 05:13 PM, Mathieu Arnold wrote:
+--On 30 mars 2015 16:46:36 +0200 Daniel Rysl
The reasons why not to use nslookup are summarized here:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html
I have seen ISC developers discourage from using it in tihis mailing
list too.
As for the SERIAL in SOA, it's just a good practice, it gives you the
informati
13 matches
Mail list logo
