After setting up a zone with DNSSEC using inline-signing, I have run into
the issue where if I do anything that updates the unsigned file that is
input into BIND, that it never seems to update the signed data it generated.
I've previously [1] received the Gold Star for suggesting ;-)
On 01/30/2012 00:46, Jan-Piet Mens wrote:
After setting up a zone with DNSSEC using inline-signing, I have run into
the issue where if I do anything that updates the unsigned file that is
input into BIND, that it never seems to update the signed data it generated.
I've previously [1]
OK, call me stupid, but I must be missing something here.I just tried
what you mentioned below, and this seems to blow up major on 9.9.0rc1.
If I try 'rndc reload' it looks happy command wise:
# rndc reload
server reload successful
Now if I try 'rndc reload leadmon.org' as this is my
OK, got it, and I learned something new so figured I mention it.I have
been using two views in my bind setup for a while here, but I guess prior to
trying to work out the inline signing with 9.9, I had never attempted to
reload an individual zone. After firing up my google-fu for a couple
That said, instead of using 'rndc reload leadmon.org', I actually have to
use 'rndc reload leadmon.org IN external', or internal as the case may be to
separate the zone I am reloading.
Not here, in spite of multiple views; BIND 9.9.0rc1
-JP
Strange, I can't explain that one..
If I try it without passing the info to rndc, it fails for sure:
# rndc reload leadmon.org
rndc: 'reload' failed: not found
Now if I pass the view info along, life is good:
# rndc reload leadmon.org IN internal
zone reload queued
# rndc reload
Sorry, Shiva I have confused you. Mark is absolutely right and I was wrong.
Another way is to capture responses with tcpdump or dnscap.
2012/1/30 Mark Andrews ma...@isc.org
In message
canbtt6nxwb4fqygev4x8_jl+m5ho7wfenirxzg3pgvc-kzc...@mail.gmail.com
, Shiva Raman writes:
Hi Peter
On 1/30/2012 5:28 AM, Howard Leadmon wrote:
Jan 30 05:23:26 minbari named[30332]: zone leadmon.org/IN/external
(unsigned): loaded serial 2012012901
Jan 30 05:23:26 minbari named[30332]: zone leadmon.org/IN/external (signed):
serial 2012012901 (unsigned 2012012901)
Jan 30 05:23:26 minbari
Mark Elkins m...@posix.co.za wrote:
I also see...
$TTL 0 ; 0 seconds
TYPE65534 \# 5 ( 08467D0001 )
TYPE65534 \# 5 ( 0896730001 )
appearing on a secondary for this zone. What is it?
(Yes - an unknown data type - the secondary is running bind
On 1/30/2012 11:59 AM, Mark Elkins wrote:
Lastly - how does one 'view' the 'raw' format of a zone file?
Use named-compilezone
Guess that kind of makes some obscure logical sense. Works though
I do think that 'named-compilezone' should be able to work out the
format of the 'input' file
Alan Clegg a...@clegg.com wrote:
Just be sure to watch for the extra SOA record. :)
Or use dig axfr +onesoa ...
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
South-east Iceland: Southerly 5 to 7, occasionally gale 8, but variable 4 at
first and later in west. Very rough,
Nope, granted you would think that should work, but I really do have two
different views in different files, as I use it to support both my internal
IPv4 RFC1918 space, and my external view for what the rest of the world
should see.
Here is what my config looks like:
// Internal View
zone
Hello Evan,
As you probably saw from the other posts on the subject, the hint of taking
and telling named to reload just the specific zone, and not just a general
reload of all zones did indeed correct the problem.
As you mentioned, even a hard restart of the named process would not cause
As you mentioned, even a hard restart of the named process would not cause
a resign of the zone, and not that I did it the last time around, but for
sure removing the journal files and .signed zone file would cause named to
update from the unsigned file and then the signed data would be
I suspect that something was wrong with the unsigned zone, 'rndc reload'
failed to catch the problem, and so the zone got itself into a weird state.
The exact circumstance in which I've seen this happen involved a failure to
update the SOA serial, but there may be other triggers for it as
I can install bind 9.9.0rc2 tomorrow and test with both nsupdate and rndc
reload. I would also like to test DNSSEC automatic key rollover with
inline signing again. I imagine this will be fixed in rc2, given the
success of the patch you provided earlier. My next ZSK activation date is
16 matches
Mail list logo
