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
_
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 1
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
>
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
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 tsig
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 t
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]: managed-
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
I
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 unsigne
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
> 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
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
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
> 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
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 f
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 sing
Jan-Piet Mens 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
http://ripe63.ripe.net/presentations/151-DNSCCM_RIPE6
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.
___
Pleas
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 dyna
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
T
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 flus
21 matches
Mail list logo
