On 22.11.11 12:58, Binu B Nair wrote:
I am facing a very strange problem.
On sending a DNS query for sabb...@direct.telstra.net I do not get a
DNS response from the resolver. It shows a SERVEFAIL error.
maybe because it's not valid domain name, because of the @ character.
However on
Since quite a few years, I habitually run 'make test' after building
BIND
from sources. I'me seiing a failure with 9.8.1-P1, and wonder whether
anyone else is also.
Relevant log fragment is shown below.
/Niall
S:xfer:Tue Nov 22 11:12:07 GMT 2011
Hello,
I'm looking at a BIND installation with a largish number of views, each
of which allow recursion and contain a couple of RPZ zones. Each view
has a `match-clients{}' option limiting access to the view to a very
small number of addresses. (Typically the single address of a client
with a
On 22/11/11 12:42, Jan-Piet Mens wrote:
Maybe I'm dreaming along the lines of a BIND zone updatable via DDNS,
that I can use to configure ACL content ... ;-)
I've wondered about that before. Seems it would be useful for a bunch of
things.
___
Jan-Piet Mens jpmens@gmail.com wrote:
Any ideas or suggestions?
Not a practical one, but there are moves towards a standard nameserver
control protocol:
http://tools.ietf.org/html/rfc6168
http://tools.ietf.org/html/draft-dickinson-dnsop-nameserver-control
On 22.11.11 13:42, Jan-Piet Mens wrote:
I'm looking at a BIND installation with a largish number of views, each
of which allow recursion and contain a couple of RPZ zones. Each view
has a `match-clients{}' option limiting access to the view to a very
small number of addresses. (Typically the
On 11/22/2011 2:30 AM, Binu B Nair wrote:
On attempting to clear cache using “rndc flush”, this does not work.
However a named restart clears the cache. What could be the problem? Am
I doing something wrong or have I understoos the “rndc flush” incorrectly?
What makes you think that rndc
afaik your client can identify itself by TSIG instead of IP address.
of course, this requires tyour client to support TSIG ...
Unfortunately the clients are dumb stub resolvers (Linux, Mac, Windows),
so TSIG is not an option.
-JP
___
Please
When bind 9.9.0b2 starts up, the syslog shows the following messages:
Nov 22 10:18:19 nstest2 named[17190]: using default UDP/IPv6 port range: [1024,
65535]
Nov 22 10:18:19 nstest2 named[17190]: listening on IPv6 interfaces, port 53
Nov 22 10:18:19 nstest2 named[17190]: socket.c:5728: unexpected
I have opened up a Bug ticket with ISC on this - #26676, but I just wanted to
make sure that I'm not doing anything wrong that may be causing the issue.
Has anyone been able to get inline-signing to work on a static master zone
using an authoritative server?
When we manually change the Master
22-Nov-2011 11:25:28.320 general: notice: all zones loaded
22-Nov-2011 11:25:28.320 general: notice: running
This looks to me as though you've cycled the server, which isn't
currently allowed. Evan pointed out recently here that it can actually
corrupt the zone...
My experience is that, after
On Tuesday 22 November 2011 05:24:14 Niall O'Reilly wrote:
Since quite a few years, I habitually run 'make test' after
building BIND from sources. I'me seiing a failure with 9.8.1-P1,
and wonder whether anyone else is also.
Is this a manifestation of the same issue as brought up last
Jan-Piet you get the Gold Star!!! You totally got it right!
If I specify a rndc reload, the journal files never get updated and Bind
loads the outdated signed file. However, if I specify an rndc reload
ualbanytest.org - the changes get picked up and a journal file is created for
the unsigned
Sorry if I used the expression bug down as it not mean necessarily
that this it is a bug in anyway but probably a configuration issue.
Original Message
Subject: DNSSEC bug down issue, Servers Unreachable
Date: Mon, 21 Nov 2011 21:45:52 -0800
To: bind-users@lists.isc.org
Yesterday I started getting messages like:
Nov 22 10:29:01 gemini named[28532]: managed-keys-zone ./IN: No DNSKEY
RRSIGs found for '.': success
Nov 22 10:53:44 titan named[15260]: managed-keys-zone ./IN/external: No
DNSKEY RRSIGs found for '.': success
Nov 22 10:53:54 titan named[15260]:
Kevin: I did something similar, using nsupdate to modify the unsigned zone
instead of a manual edit. The myzone.db, myzone.db.jnl, myzone.db.signed, and
myzone.db.signed.jnl files all get updated appropriately. rndc reload is not
necessary. It is interesting to note that the serial number in
afaik your client can identify itself by TSIG instead of IP address.
of course, this requires tyour client to support TSIG ...
On 22.11.11 15:31, Jan-Piet Mens wrote:
Unfortunately the clients are dumb stub resolvers (Linux, Mac, Windows),
so TSIG is not an option.
no chance to run local
On 11/22/2011 3:24 AM, Niall O'Reilly wrote:
Since quite a few years, I habitually run 'make test' after building
BIND from sources. I'me seiing a failure with 9.8.1-P1, and wonder
whether anyone else is also.
All tests passed for me on FreeBSD, FWIW.
--
We could put the
On 11/22/2011 11:17 AM, Spain, Dr. Jeffry A. wrote:
When bind 9.9.0b2 starts up, the syslog shows the following messages:
Nov 22 10:18:19 nstest2 named[17190]: using default UDP/IPv6 port range:
[1024, 65535]
Nov 22 10:18:19 nstest2 named[17190]: listening on IPv6 interfaces, port 53
Nov
In message 4ecc3523.3070...@gis.net, Danny Mayer writes:
On 11/22/2011 11:17 AM, Spain, Dr. Jeffry A. wrote:
When bind 9.9.0b2 starts up, the syslog shows the following messages:
Nov 22 10:18:19 nstest2 named[17190]: using default UDP/IPv6 port range: [1
024, 65535]
Nov 22 10:18:19
On Tue Nov 22 2011 at 20:34:46 CET, Spain, Dr. Jeffry A. wrote:
I did something similar, using nsupdate to modify the unsigned zone
instead of a manual edit. [...] rndc reload is not necessary.
`rndc reload' never is necessary if you use DDNS to update master zones.
-JP
21 matches
Mail list logo
