ning, and I wrote it 9 years ago (!) around
the time of 9.8.0 to make it easier to update signed zones. It's easier
than dnssec-signzone.
https://fanf.livejournal.com/112476.html
http://dotat.at/prog/nsdiff/
Tony.
--
f.anthony.n.finchhttp://dotat.at/
work to th
Hi again.
So finally i was able to sign my zone thanks to a different (older) tutorial.
I specified dnssec-signzone with flags -o and -S and it worked!
If anyone could please answer these questions, I would appreciate it
1) do I need to generate those 2 .key and .private files if I intend to sign
Hi all.
So I'm still fighting with dnssec in BIND 9.8.2 (oracle linux 6).
Unfortunately no automatic sigining before Bind 9.9, from what I read.
I can't sign my zone, I keep getting "dnssec-signzone: fatal: No signing keys
specified or found."
By now I've tried to move
> On 27 Jul 2018, at 1:34 am, Daniel Stirnimann
> wrote:
>
> Hello all,
>
> dnssec-signzone (BIND 9.12.2) sometimes does lowercase DNSSEC records.
> This seems a problem especially for NSEC records which are case
> sensitive. dnssec-verify is moaning with errors lik
Hello all,
dnssec-signzone (BIND 9.12.2) sometimes does lowercase DNSSEC records.
This seems a problem especially for NSEC records which are case
sensitive. dnssec-verify is moaning with errors like this:
Bad NSEC record for ipad-rigi-2.switch.ch, bit map mismatch
Example:
dnssec-signzone -o
> While this is not a problem for BIND to load the zone it seems
> unexpected to me. Should dnssec-signzone not remove obsolete signatures?
Found out that this issue is fixed in BIND 9.11.0a1:
4305. [bug]dnssec-signzone was not removing unnecessary rrsigs
from the zone&
Dear all,
I have the following test zone files:
8.example.com.signed
K8.example.com.+008+40162.key
K8.example.com.+008+40162.private
I edit the signed zone directly (8.example.com.signed) and remove for
example an A record and then resign the zone as following:
dnssec-signzone -z -o 8
On Tue, Oct 28, 2014 at 04:48:20AM +1100, shm...@riseup.net wrote:
> i couldn't sign a zone with the draft SMIMEA RR from debian jessie based OS
It's not yet been implemented in BIND.
I expect we will, but not until it's at least been allocated a type code
(see http://www.iana.org/assignments/dns
ption
+++-=-=-=-===
ii bind9utils1:9.8.4.dfsg.P1-6+nmu amd64
Utilities for BIND
dnssec-signzone: warning: example.net:40: unknown RR type 'SMIMEA'
dnssec-signzone: fatal: failed loading zone from 'example.net': unknown
class
Hello all,
I have written a small patch for dnssec-signzone to handle what I
assume is a pretty common case for big zones: ZSK rollover without
double RRSIGs, ie removal of the RRSIG records signed with the old
ZSK (inactive but still published while waiting for cache expiration
of the old RRSIGs
On 4/25/2013 11:57 AM, Evan Hunt wrote:
The warning is spurious and has been fixed in 9.9.3. It was incorrectly
checking to see whether there were any DNSKEY records in the zone *before*
loading them from the key files. It should have been doing so afterward,
obviously.
Ah, okay, thanks for
> dnssec-signzone -d /path/to/dsset -K /path/to/keys -3 00 -f
> zone.signed -e +3024000 -j 1800 -o zone.edu -r /dev/urandom -S -T 12h
> /path/to/input
>
> dnssec-signzone: warning: NSEC3 generation requested with no DNSKEY;
> ignoring
> Fetching ZSK 59544/RSASHA25
We're upgrading from bind 9.8 to 9.9, and there's a new warning from
dnssec-signzone that's confusing me. We are using a locally developed
mechanism for signing that predates the auto and in-line signing
mechanisms currently available in bind, and run the command like this:
dns
On Mon, 17 Sep 2012, Evan Hunt wrote:
Does anyone use dnssec-signzone with -x? If so, can you check/tell me
your DNSKEY RRset?
I just tested it with "dnssec-signzone -Sx example.com" and
"dnssec-signzone -x example.com", on 9.9.2 and 9.7.4, and it worked
as expected in
> Does anyone use dnssec-signzone with -x? If so, can you check/tell me
> your DNSKEY RRset? And if it works, could you reveal the full
> commandline argument used, the bind version, and whether any pkcs#11
> provider was compiled in?
I just tested it with "dnssec-signzone -Sx
was looking at using the "-x" option with
dnssec-signzone, but it seems that at least for my commandline
invocation, that this option is completely ignored. The version used
is 9.7.4.
Does anyone use dnssec-signzone with -x? If so, can you check/tell me
your DNSKEY RRset? And if it wo
tory.
>
> I have upgraded to BIND 9.9.1-P2 and see the same behaviour there as
> well. Unless I am missing something obvious, it seems that the only way
> to avoid having "dnssec-signzone -g" for a parent zone pick up stale DS
> records from dsset files generated by "d
re as
well. Unless I am missing something obvious, it seems that the only way
to avoid having "dnssec-signzone -g" for a parent zone pick up stale DS
records from dsset files generated by "dnssec-signzone -S" for the child
zones is to remove deleted KSK's from the (-K) key reposito
Context: BIND 9.8.3-P2
If dnssec-signzone is invoked with -S (smart signing), it examines keys
in the key repository directory (-K) and selects only current keys for
inclusion in the zone. That works well. It also generates DS records for
the parent zone and lands them in a dsset file in (-d
Hi,
When using dnssec-signzone manually to sign a zone, I think there is a
case where it does not drop the RRSIGs when I think it should. Image
that dnssec-signzone is used with the old signed zone's RRSIG/NSEC*
data, along with an updated "unsigned" zone.
Let's say we are
On Tue, 1 Nov 2011, Paul Wouters wrote:
There have been discussions in the past over this, but we were once again
bitten by this dnssec-signzone bug:
Tue Nov 1 12:11:28 2011 signDomain: sign command:
/usr/sbin/dnssec-signzone -C -u -r /dev/random -t -o openswan.org -f
/var/tmp
On Tue, 1 Nov 2011, Paul Wouters wrote:
There have been discussions in the past over this, but we were once again
bitten by this dnssec-signzone bug:
Tue Nov 1 12:11:28 2011 signDomain: sign command: /usr/sbin/dnssec-signzone
-C -u -r /dev/random -t -o openswan.org -f /var/tmp
There have been discussions in the past over this, but we were once again
bitten by this dnssec-signzone bug:
Tue Nov 1 12:11:28 2011 signDomain: sign command: /usr/sbin/dnssec-signzone -C
-u -r /dev/random -t -o openswan.org -f /var/tmp/openswan.org.sign.tmp -i
1296000 -e +2592000 -j
Hello,
I am trying to sign a zone(domain.nx) using Bind-9.7.3 with
PCKS11/OpenSC, I am able to generate key on smartcard using
(pkcs11-keygen) and export a meta-description info with
dnssec-keyfromlabel, however dnssec-signzone seem to have problem
finding a private key.
#./dnssec-signzone -E
; two-digit of daily version. This has benefit of being almost as good as
>> putting unixtime of last modification, while being much more
>> human-readable.
>> How difficult would it be to implement this for dnssec-signzone -N,
>> using a
>> fourth format specifie
> signatures, thus saving on computation time (not that I have a lot to
>> save
>> on ;). So, I'd like dnssec-signzone to take 'normal' records from
>> non-signed
>> zone, try to reuse RRSIG records as much as possible, taking them from
>> signed zone, and w
xtime of last modification, while being much more human-readable.
How difficult would it be to implement this for dnssec-signzone -N, using a
fourth format specifier?
It's not hard. See my bind-users post of Oct 15 with subject:
more flexible serial number handling in dnssec-signzone
e readable, and can contain $INCLUDE directives,
which makes modification easier.
But specifying the signed zone has added benefit of reusing existing
signatures, thus saving on computation time (not that I have a lot to save
on ;). So, I'd like dnssec-signzone to take 'normal' records
I have three questions regarding dnssec-signzone:
To clarify things, I'm using BIND 9.7.2-P2.
First is about input file: you can specify on the command line either the
signed version of the zone, or the unsigned one.
What I'd like to do hovever, is to use both.
The unsigned zone is
On Wed, 15 Dec 2010 22:22:45 +1100, Mark Andrews wrote:
> A string
in a TXT record can only be 255 characters long though there
> can be
multiple strings. If you try to load a string longer than 255
>
characters you will get the error above.
Thanks Mark. This was indeed
the case.
The DKIM TX
In message , Patrick Vande Walle writes
:
> Greetings,
>
> My zone file contains a TXT record for DKIM :
>
> sig-2010._domainkey IN TXT "v=DKIM1; r=postmaster; g=*; k=rsa;
> t=s; p=[deleted for shortness]"
>
> When I run: /usr/sbin/dnssec-
Greetings,
My zone file contains a TXT record for DKIM :
sig-2010._domainkey IN TXT "v=DKIM1; r=postmaster; g=*; k=rsa;
t=s; p=[deleted for shortness]"
When I run: /usr/sbin/dnssec-signzone -u -3 5D2CA8 -C -g -p -o
example.net. -e +7776000 -l dlv.isc.org zone.db K*.private
ne direction only, forward... so using date/time
> makes sure you are always incrementing the serial. And you even don't
> need to know the current serial to update it.
If that's the reason, dnssec-signzone already supports this: -N unixtime
Niobos
15.10.2010 20:54, Niobos kirjoitti:
What's the advantage of using a date anyway? I too can see when a zone
was last edited, even down to the second, by watching the RRSIG(SOA) timing.
Time usually goes to one direction only, forward... so using date/time
makes sure you are always incrementing
On 16/10/10 4:54 AM, Niobos wrote:
>
> What's the advantage of using a date anyway? I too can see when a zone
> was last edited, even down to the second, by watching the RRSIG(SOA) timing.
Python 2.6.5 (r265:79359, Mar 24 2010, 01:32:55)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help",
On 2010-10-15 19:38, Jay Ford wrote:
> I found myself in need of more flexibility in the way dnssec-signzone
> handled SOA serial numbers, so I hacked in a way to have the new serial
> number generated by calling strftime(3) with a user-specified time
> format.
I was on the ve
I found myself in need of more flexibility in the way dnssec-signzone handled
SOA serial numbers, so I hacked in a way to have the new serial number
generated by calling strftime(3) with a user-specified time format. For
example
dnssec-signzone -N '%Y%m%d1' ...
will generat
After upgrading to bind 9.7.1 recently, some of my scripts started to
output text when they shouldn't. Digging a little, I quickly found
that dnssec-signzone now unconditionally writes information like this
on stderr:
Verifying the zone using the following algorithms: RSASHA1.
better implentation anyway, we're still in the early prototyping phase.
> From dnssec-signzone
[...]
>2530144500 denotes 14:45:00 UTC on May 30th, 2000.
Perhaps this same example/clarification could be added to the man pages for
dnssec-keygen and dnssec-settime under th
TAo2qsyX9mW10B48M+slzk3HPGLvCDP5U6iKQWQvtEm4k6/ ml0Xzvnjfc36ynQK4IuffGz
FSsYenr01qF+SGizP2pb2LIWYIjyKamYG 34+0c1/5
>From dnssec-signzone
-s start-time
Specify the date and time when the generated RRSIG records become
valid. This can be either an a
On Wed, 28 Apr 2010, Mark Andrews wrote:
> The .private timestamps are in UTC and that is what is used for key
> management. The .key values are just comments. You should be able to
> work out my current offset from UTC.
>
> % grep Created Kl.+005+59421.*
> Kl.+005+59421.key:; Created: T
In message , "
Paul B. Henson" writes:
>
> I've been testing dnssec-keygen and the "smart signing" mode of
> dnssec-signzone and have run into some timezone confusion; I'm not sure if
> it's expected behavior or a bug. I searched around a bit an
I've been testing dnssec-keygen and the "smart signing" mode of
dnssec-signzone and have run into some timezone confusion; I'm not sure if
it's expected behavior or a bug. I searched around a bit and didn't find
anything relevant, apologies in advance if I missed
> Seeing this after upgrading to 9.6.2-P1.
>
> We've made no other changes to the host or any configuration files, etc.
>
> /var/named # dnssec-signzone -g -o xxx.xxx.gov.au db.xxx.xxx.gov.au
> dnssec-signzone: fatal: no self signed KSK's found
When dnssec-signz
ossible, so sorry
> for the size ...
> /var/named # dnssec-signzone -z -v 7 -g -o xxx.xxx.xxx.au db.xxx.xxx.xxx.au
> dnssec-signzone: using 2 cpus
> dnssec-signzone: debug 1: decrement_reference: delete from rbt: 81f2688
[ snip.. ]
Is there a key signing key (KSK) in the zone file? db.x
On Tue, Mar 30, 2010 at 12:39:58PM +1100, chris liesfield wrote:
> Seeing this after upgrading to 9.6.2-P1.
> We've made no other changes to the host or any configuration files, etc.
> /var/named # dnssec-signzone -g -o xxx.xxx.gov.au db.xxx.xxx.gov.au
> dnssec-signzone: fata
Seeing this after upgrading to 9.6.2-P1.
We've made no other changes to the host or any configuration files, etc.
/var/named # dnssec-signzone -g -o xxx.xxx.gov.au db.xxx.xxx.gov.au
dnssec-signzone: fatal: no self signed KSK's found
No idea what's going on here and we need advi
On 12-23-2009 15:33, Marco Davids wrote:
>>> It seems as if my 'dnssec-signzone' runs on one CPU-core only, where as
>>> I would have expected it to run on all four.
>>
>> dnssec-signzone first does a lot of preprocessing on one core, before
>> it f
Op 23-12-2009 15:14, schreef Paul Wouters:
> On Wed, 23 Dec 2009, Marco Davids wrote:
>
>> It seems as if my 'dnssec-signzone' runs on one CPU-core only, where as
>> I would have expected it to run on all four.
>
> dnssec-signzone first does a lot of prep
On Wed, 23 Dec 2009, Marco Davids wrote:
It seems as if my 'dnssec-signzone' runs on one CPU-core only, where as
I would have expected it to run on all four.
dnssec-signzone first does a lot of preprocessing on one core, before
it finally starts signing with multiple cores. Are you
Hi all,
It seems as if my 'dnssec-signzone' runs on one CPU-core only, where as
I would have expected it to run on all four.
Specs:
- Ubuntu 8.04.3 LTS
- bind-9.7.0b1.f1.tar.gz
- Quad-core 'Intel(R) Xeon(R) CPU E5335 @ 2.00GHz' (according to
'/proc/cpuinfo')
Hi,
When using 9.7.0a3 with dnssec-signzone and PKCS#11, one can use the genkey.sh
as a tool to generate keys. It is however hardcoded to RSASHA1. (We needed
NSECRSASHA1)
The below tiny patch addresses this.
Related, the dnssec-signzone command created a zone with algo 5 DNSKEY's with
> Re-signing the signed zone file, however, also includes signatures from
> the passive ZSK, *unless* I remove the DNSKEY records from the zone file
> before signing. I guess this is due to the keys already in the signed
> zone file overriding the -S switch:
Yes, that's a bug. Thank you very much
I currently explore the new DNSKEY metadata and dnssec-signzone -S with
BIND 9.7.0a3. This feature definitely helps making key management easier
and will motivate more operators to sign their zones. Thank you for that.
For this test, I created a zone with one manually timed KSK, one active
ZSK
Thanks to all for the fast reply and the detailed answers.
And thank you very mutch for the verifing option of dnssec-signzone.
With it (and your help) I've learned again a bit more about dnssec.
> In message <20090624211854.a3be222...@thrintun.hactrn.net>, Rob
> Austein write
In message <20090624211854.a3be222...@thrintun.hactrn.net>, Rob Austein writes:
> At Wed, 24 Jun 2009 18:23:52 +, Evan Hunt wrote:
> >
> > On Wed, Jun 24, 2009 at 05:45:33PM +0200, holger.zule...@arcor.net wrote:
> > > I have some issues with dnss
At Wed, 24 Jun 2009 18:23:52 +, Evan Hunt wrote:
>
> On Wed, Jun 24, 2009 at 05:45:33PM +0200, holger.zule...@arcor.net wrote:
> > I have some issues with dnssec-signzone under BIND 9.7.0a1.
> >
> > I'm using different algorithms for key- and zone signing ke
On Wed, Jun 24, 2009 at 05:45:33PM +0200, holger.zule...@arcor.net wrote:
> I have some issues with dnssec-signzone under BIND 9.7.0a1.
>
> I'm using different algorithms for key- and zone signing keys.
That's a problem.
> Does it mean that it is no longer possibl
I have some issues with dnssec-signzone under BIND 9.7.0a1.
I'm using different algorithms for key- and zone signing keys.
This is the list of currently used keys:
$ dnssec-zkt .
Keyname Tag Typ Sta Algorit Generation Time
sub.example.de. 5659
59 matches
Mail list logo
