Hello Simon,
> what we did to achieve this amount of zones is the following:
Thank you for your explanation. We originally avoided the MySQL route
because its OpenDNSSEC support is explicitly marked as being
*experimental*, but have now taken up on your suggestion and have wiped
everything, and rebuilt with MySQL support. The whole system now does
indeed feel a little snappier (how's that for an un-technical term :-)
Interestingly, what now fails, at least upon initially adding a zone,
are incoming AXFR. We first thought this had to do with long pathnames
and an limitation of the appropriate database columns, but that doesn't
apply.
$ z=c1006.aa
$ods-ksmutil zone add --zone $z --policy pol0 -s /tmp/o/signconf/$z -i
/tmp/o/unsigned/$z -o /tmp/o/signed/$z
$ ods-ksmutil update all
# ods-control enforcer notify
Jan 28 16:09:59 sign1 ods-enforcerd: Zone c1006.aa found.
Jan 28 16:09:59 sign1 ods-enforcerd: Policy for c1006.aa set to pol0.
Jan 28 16:09:59 sign1 ods-enforcerd: Config will be output to
/tmp/o/signconf/c1006.aa.
Jan 28 16:10:00 sign1 ods-enforcerd: INFO: Promoting ZSK from publish to
active as this is the first pass for the zone
Jan 28 16:10:00 sign1 ods-enforcerd: WARNING: Making non-backed up ZSK
active, PLEASE make sure that you know the potential problems of using
keys which are not recoverable
Jan 28 16:10:00 sign1 ods-signerd: cmdhandler: updating signer
configuration (c1006.aa)
Jan 28 16:10:00 sign1 ods-signerd: zone fetcher reloaded (pid=22101)
Jan 28 16:10:00 sign1 ods-signerd: zone fetcher AXFR for c1006.aa failed
Jan 28 16:10:00 sign1 ods-signerd: AXFR for new zone c1006.aa failed
Jan 28 16:10:00 sign1 ods-signerd: zone fetcher reloaded (pid=22101)
Jan 28 16:10:00 sign1 ods-signerd: unable to open file
/tmp/o/unsigned/c1006.aa.axfr for reading: No such file or directory
Jan 28 16:10:00 sign1 ods-signerd: unable to copy axfr file
/tmp/o/unsigned/c1006.aa.axfr to /tmp/o/unsigned/c1006.aa
Jan 28 16:10:00 sign1 ods-signerd: task [read zone c1006.aa] failed
Jan 28 16:10:00 sign1 ods-enforcerd: Disconnecting from Database...
Jan 28 16:10:00 sign1 ods-enforcerd: Sleeping for 3600 seconds.
The zone actually is transferred from it's master server:
28-Jan-2011 16:10:02.497 transfer of 'c1006.aa/IN': AXFR started
28-Jan-2011 16:10:02.500 transfer of 'c1006.aa/IN': AXFR ended
However, it isn't stored anywhere:
$ find /tmp/o -ls
2140361 4 drwxrwxrwx 5 root root 4096 Jan 28 15:35 /tmp/o
2140362 4 drwxrwxrwx 2 root root 4096 Jan 28 16:02
/tmp/o/signed
2140365 4 drwxrwxrwx 2 root root 4096 Jan 28 16:10
/tmp/o/signconf
2140363 4 -rw-r--r-- 1 opendnssec opendnssec 950 Jan 28 16:10
/tmp/o/signconf/c1006.aa
2140364 4 drwxrwxrwx 2 root root 4096 Jan 28 16:10
/tmp/o/unsigned
If I stop and start OpenDNSSEC, I see the following:
Jan 28 16:12:22 sign1 ods-enforcerd: Zone c1006.aa found.
Jan 28 16:12:22 sign1 ods-enforcerd: Policy for c1006.aa set to pol0.
Jan 28 16:12:22 sign1 ods-enforcerd: Config will be output to
/tmp/o/signconf/c1006.aa.
Jan 28 16:12:22 sign1 ods-enforcerd: WARNING: key rollover not completed
as there are no keys in the 'ready' state; ods-enforcerd will try again
when it runs next
Jan 28 16:12:22 sign1 ods-enforcerd: No change to: /tmp/o/signconf/c1006.aa
Jan 28 16:12:22 sign1 ods-enforcerd: Disconnecting from Database...
Jan 28 16:12:22 sign1 ods-enforcerd: Sleeping for 3600 seconds.
----------- JP: signed c1006.aa in /tmp/o/signed/c1006.aa --------
Jan 28 16:12:23 sign1 ods-signerd: [STATS] c1006.aa RR[count=613
time=0(sec)] NSEC3[count=205 time=0(sec)] RRSIG[new=820 reused=0
time=1(sec) avg=820(sig/sec)] AUDIT[time=0(sec)] TOTAL[time=1(sec)]
The zone is (again?) transferred, stored and correctly signed; I see the
c1006.aa.axfr file (belonging to root) and the resulting signed zone
file in /signed, belonging to 'opendnssec'.
Any idea why incoming zone transfers are having a problem since
switching to MySQL ?
Thanks,
-JP
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
