DNSSEC's sorted zone
Mark Elkins
mje at posix.co.za
Wed Jan 12 16:58:35 UTC 2011
Still playing with DNSSEC and signing zones.
I'm resigning an already signed zone.
I'm doing this on a hyper-threaded 4-core i7 (Intel(R) Core(TM) i7 CPU
920 @ 2.67GHz) which under linux gives me 8 cores.
I'm using the command:
dnssec-signzone -3 "abcd" -o example.com -p -t -A -d keyset -g -a -N
increment -s 20110111161553 -e 20110210161553 -f example.com.sign-1
example.com.signed
A minute later - I run the same command - but output to a different
file... -f example.com.sign-2
A 'diff' of the two output files gives lots of differences - apart from
the zone creation time.
If I include the "-n ncpus" as "-n 1" - then the files are the same
(except for the creation time).
I believe that the data is fundamentally the same - but it is partially
re-ordered if there are multiple threads. This is not what I would have
expected - having had it been drummed into me that dnssec-signzone will
first sort the zone then generate all the RRSIG records - etc...
I find this disturbing. It appears to only be doing this on CNAME
records.
In one file:
www.access.example.com CNAME www.entry.example.com
access.example.com CNAME entry.example.com
In the next - their order is swapped.
Are these differences in ordering completely ignored when BIND loads the
file into memory?
--
. . ___. .__ Posix Systems - (South) Africa
/| /| / /__ mje at posix.co.za - Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6696 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110112/c9895ab9/attachment.bin>
More information about the bind-users
mailing list