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 na
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 '.': s
> 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 h
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? Th
> 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
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.
In article ,
Jim Pazarena 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.
Checking for this has long been one of my standard troubleshooting
> > 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.
--
Eva
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
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
> 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:
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%. y
12 matches
Mail list logo
