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