When I run a BIND with auto-dnssec maintain and inline-signing
yes, if I create no key, there is no error message and, worse, the
log file says the zone is signed:
Jul 30 16:31:42 u12-33673 named[1605]: zone auto.rd.nic.fr/IN (unsigned):
loaded serial 2013073000
Jul 30 16:31:42 u12-33673
On Tue, 30 Jul 2013, Stephane Bortzmeyer wrote:
Of course, there is no signature:
% dig +multi @localhost SOA auto.rd.nic.fr
Add +dnssec
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users
On Tue, Jul 30, 2013 at 09:50:46AM -0500,
Jeremy C. Reed jr...@isc.org wrote
a message of 7 lines which said:
Of course, there is no signature:
% dig +multi @localhost SOA auto.rd.nic.fr
Add +dnssec
[I thought it was in my .digrc.] It changes nothing. Without a key,
BIND could not
When I run a BIND with auto-dnssec maintain and inline-signing
yes, if I create no key, there is no error message and, worse, the
log file says the zone is signed:
Thanks for pointing this out. It's not really an error, but the log
should certainly be clearer about what's going on.
An
Sorry for the bump here, but through extensive troubleshooting I've
identified a trend in this. It appears that zones hosted on the
lower-numbered masters are still updating without issue. This leads me to
believe that something is causing BIND to forget the later cluster
servers, as the logs
On 30 July 2013 20:31, Brandon Whaley brand...@inmotionhosting.com wrote:
Sorry for the bump here, but through extensive troubleshooting I've
identified a trend in this. It appears that zones hosted on the
lower-numbered masters are still updating without issue. This leads me to
believe
Hey Steve, thanks for the reply. Here's the top of one of the masters'
named.conf files (they're all the same, with the exception of which zones
are on them:
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
include /etc/rndc.key;
logging{
channel simple_log {
- Original Message -
I think that's what you asked for. In case I misunderstood, here's a
zone entry from the slave's named.conf (this immediately follows the
options block in my first email:
zone example.com {
type slave;
file /var/named/slaves/example.com.db;
masters {
Hey Lawrence, this is the zone entry as seen on the 10.10.10.1 slave. The
10.0.x.1 IPs are the addresses of the masters.
On Tue, Jul 30, 2013 at 4:43 PM, Lawrence K. Chen, P.Eng. lkc...@ksu.eduwrote:
--
I think that's what you asked for. In case I
On 30 July 2013 21:38, Brandon Whaley brand...@inmotionhosting.com wrote:
zone example.com {
type slave;
file /var/named/slaves/example.com.db;
masters { 10.0.1.1; 10.0.2.1; 10.0.3.1; 10.0.4.1; 10.0.5.1; };
};
So given what I mentioned before I would envisage BIND
Oh, guess I got it mixed up because the slave is saying it got
non-authoritative answers from 10.0.x.1.. where I think of the master should at
least be authoritative for its domain.
- Original Message -
Hey Lawrence, this is the zone entry as seen on the 10.10.10.1 slave.
The
In article mailman.968.1375218342.20661.bind-us...@lists.isc.org,
Lawrence K. Chen, P.Eng. lkc...@ksu.edu wrote:
Oh, guess I got it mixed up because the slave is saying it got
non-authoritative answers from 10.0.x.1.. where I think of the master should
at least be authoritative for its
From 9.9.2-P2...I had build 9.9.3, but just as I was about to deploy came the
announcement to either go to 9.9.3-P1 or stay with 9.9.2-P2.
All the picky messages of this version.there were the no SPF/SPF records
for SPF/TXTbut I thought I already had SPF everywhere...but turned out
The logs do seem to only check the first 1-2 servers in the forwarders
section when the problem is occurring. If named is restarted on this
slave, it will check all the servers, as expected when it receives a notify.
We have our zones distributed among 5 masters to speed updates. The
software
On 30 July 2013 22:52, Brandon Whaley brand...@inmotionhosting.com wrote:
Once every few minutes the reload occurs on the master, which sends the
notify to our slave servers, who should check serials on all the masters
and transfer from the latest.
I think this is your problem. From what I
That's certainly disconcerting (and diverges from the behavior we continue
to see with BIND 9.3). Is there any reason these updates would work
without issue immediately after a restart but stop working at some point
later? As you can see in the logs I provided in my initial post (relevant
lines
On 30 July 2013 23:19, Brandon Whaley brand...@inmotionhosting.com wrote:
That's certainly disconcerting (and diverges from the behavior we continue
to see with BIND 9.3). Is there any reason these updates would work
without issue immediately after a restart but stop working at some point
On 07/30/2013 02:49 PM, Lawrence K. Chen, P.Eng. wrote:
From 9.9.2-P2...I had build 9.9.3, but just as I was about to deploy came the
announcement to either go to 9.9.3-P1 or stay with 9.9.2-P2.
All the picky messages of this version
You had a lot of issues in your message. IMO they
18 matches
Mail list logo
