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 name
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 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 create
> 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 s
On 30 July 2013 20:31, Brandon Whaley 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 that something is causing BI
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. wrote:
>
>
> --
>
>
> I think that's what you asked for. In case I misunderstood, here'
On 30 July 2013 21:38, Brandon Whaley 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 contacting 10.0.1.1
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 10.0.
In article ,
"Lawrence K. Chen, P.Eng." 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 domain.
It *should* be. But if it gets an error loading the zone
>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
th
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 we
On 30 July 2013 22:52, Brandon Whaley 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 understand BIND does not d
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 c
On 30 July 2013 23:19, Brandon Whaley 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
> later? As you can see in t
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 make
18 matches
Mail list logo
