I have 1 domain name, and 1 reverse in-addr.arpa
citires.ca and0-127.254.194.207.in-addr.arpa
which my two slaves log that the master is not authoritative for
I have plenty of rdns subnets, and 3 fractional subnets in that group
so my copy paste of this new /25 looks 100%. yet
I have 1 domain name, and 1 reverse in-addr.arpa
citires.ca and0-127.254.194.207.in-addr.arpa
which my two slaves log that the master is not authoritative for
Seen from here (.DE) the NS for citires.ca both refuse to answer
queries, so they are indeed not authoritative:
Jan-Piet Mens wrote, On 2011-11-23 12:21 AM:
I have 1 domain name
citires.ca
which my two slaves log that the master is not authoritative for
Seen from here (.DE) the NS for citires.ca both refuse to answer
queries, so they are indeed not authoritative:
$ dig @ns.qcislands.net.
Jan-Piet Mens wrote, On 2011-11-23 12:21 AM:
I have 1 domain name, and 1 reverse in-addr.arpa
citires.ca and0-127.254.194.207.in-addr.arpa
which my two slaves log that the master is not authoritative for
I found the issue!
I had TWO named.conf files for my slaves, one not
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.
True, but in that situation 'inline-signing' isn't necessary either.
--
Evan Hunt
In article mailman.321.1322037649.68562.bind-us...@lists.isc.org,
Jim Pazarena b...@paz.bz wrote:
I had TWO named.conf files for my slaves, one not being used
any longer, and THAT'S the one I updated with these new entries.
I can't count the number of times this has happened to someone.
Evan: I'd like to ask for clarification. My understanding is that
inline-signing yes: is necessary to cause bind to keep separate signed and
unsigned zone files, and that the source of the unsigned zone file can be a
disk file in the case of a master, or a zone transfer in the case of a slave.
Evan: I'd like to ask for clarification. My understanding is that
inline-signing yes: is necessary to cause bind to keep separate signed
and unsigned zone files, and that the source of the unsigned zone file
can be a disk file in the case of a master, or a zone transfer in the
case of a
On Wed Nov 23 2011 at 20:21:00 CET, Evan Hunt wrote:
Correct, but... let me start by explaining the situation in releases prior
to 9.9, without the inline-signing feature.
And would you now kindly do all of us and all future readers a favor and
copy/paste that text *verbatim* into the ARM?
Now, you can *also* turn on DDNS and use nsupdate on an inline-signing
zone... but, if you're going to be using DDNS anyway, then I'm unclear what
operational need is being served by separating the data. With or without
inline-singing, your master file will be overwritten, and you'll have
Still seeing these... No ideas anybody :)?
Looks like they're always paired with an EDNS log line:
Nov 23 13:35:19 atlas named[28846]: success resolving './DNSKEY' (in
'.'?) after disabling EDNS
Nov 23 13:35:19 atlas named[28846]: managed-keys-zone ./IN/internal: No
DNSKEY RRSIGs found for '.':
On Wed, Nov 23, 2011 at 02:02:42PM -0800, Paul B. Henson wrote:
Still seeing these... No ideas anybody :)?
Looks like they're always paired with an EDNS log line:
Nov 23 13:35:19 atlas named[28846]: success resolving './DNSKEY' (in
'.'?) after disabling EDNS
Nov 23 13:35:19 atlas
12 matches
Mail list logo
