Description of problem: i discovered this tool after investigating on a problem (some keys seemed to have been updated i couldn't resolve some reverse...) i installed autotrust and configured it to use bind and pointed it to the trusted-keys-file: "/etc/pki/dnssec-keys/named.dnssec.keys" instead of the nonexistent /etc/pki/dnssec-keys/production.conf i commented the unbound stuff. : cat /etc/autotrust/autotrust.conf | grep -v "#" | grep -v ^$ : config: working-dir: "/var/lib/autotrust" log-file: "/var/log/autotrust.log" state-file: "/var/lib/autotrust/autotrust.state" trusted-keys-file: "/etc/pki/dnssec-keys/named.dnssec.keys" resolver-pidfile: "/var/run/named/named.pid" i launched it : autotrust -v 5: [autotrust] verbose: reading trusted keys file /etc/pki/dnssec-keys/named.dnssec.keys [autotrust] verbose: reading trust anchor file /var/lib/autotrust/autotrust.state [autotrust] verbose: updating trust anchor file /var/lib/autotrust/autotrust.state but /var/lib/autotrust/autotrust.state is still 0 and nothing changed in /etc/pki/dnssec-keys Version-Release number of selected component (if applicable): bind-9.6.1-7.P2 dnssec-conf-1.21-2 autotrust-0.3.1-2 How reproducible: install autotrust configure it to use the current keyfile (installed by dnssec-conf) Actual results: update some reverse keys (for example 88.in-addr.arpa. is AwEAAcd1+bra7EHWxTx0BD4u9yJiMXlmOyKCqGdGntevyZfyg78JSu23t9Ge1TPLdPJNa29pF9HbNDLE1vnv7Dfyyghq+aOwdnqIdcXWEIsZ2SgzQXTSot7kouQWj5UP1MZFGo1FXyuqGOkwcZnxqyxG7dj56qXVl67h1GnSqZVKkFjsHEV9sSWvaTgwrOa14qqCRNw1UjrhWXswT+pWgWYcUTqriLv8O6/rs2/2QiQ3T+Uy8pCSYcMT5iRwHj72wTxykgOcwnScsA862FEsbQIR9tD47hCXl0lzhHdX+csC1oclzH2aPG/gFBUgIRPqmfANhcx0M8gnuul5Zo+MlKJZtkk= in /etc/pki/dnssec-keys/production/reverse/88.in-addr.arpa.conf and AwEAAbHmcpnHwvc8VJw2ruQw+K7o3MOGUav12uT4UyUtqnN2PdQYVnYHjOLBK46ZYAHi7Xg16LMjzkmmSSZwkjuHJMjO6GdJJq6wRed6ELMYTuA5uCH/ExsUiUtHRtZInYeCJ31d9shyA34oaH7xQJaL2XJKFHr2U3DoIs2GLcMnxPNxusiKtDspfB1KUN8n2FLg5UlqEmdIE3GvcYPTHBCz2DRJQuqi4pdrnWigNdChXOSm+o12VC3z6DKNmrLxrbMS0EwFDLas13niV9qcFWg/Uvcs3GEc9/QSNXLKTzq1qkzGoya09cClwOW9iF//XxaNfTRMuwonq0EA696pFpQP5Mk= in the https://www.ripe.net/projects/disi//keys/ Expected results: updates the keys. Additional info: end of strace of autotrust (it still wakeup named even if nothing changed): open("/var/log/autotrust.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=2060, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7f2cdc000 fstat(3, {st_mode=S_IFREG|0644, st_size=2060, ...}) = 0 lseek(3, 2060, SEEK_SET) = 2060 chdir("/var/lib/autotrust") = 0 open("/etc/pki/dnssec-keys/named.dnssec.keys", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=503, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7f2cdb000 read(4, "include \"/etc/pki/dnssec-keys//production/bg.conf\";\ninclude \"/etc/pki/dnssec-keys//production/br.conf\";\ninclude \"/etc/pki/dnssec-keys//production/cz.conf\";\ninclude \"/etc/pki/dnssec-keys//production/gov.conf\";\ninclude \"/etc/pki/dnssec-keys//production/museum.conf\";\ninclude \"/etc/pki/dnssec-keys//production/org.conf\";\ninclude \"/etc/pki/dnssec-keys//production/pr.conf\";\ninclude \"/etc/pki/dnssec-keys//production/se.conf\";\ninclude \"/etc/pki/dnssec-keys//production/reverse/ripe-ncc-dnssec-keys-new.txt\";\n", 4096) = 503 read(4, "", 4096) = 0 read(4, "", 4096) = 0 close(4) = 0 munmap(0x7fd7f2cdb000, 4096) = 0 open("/var/lib/autotrust/autotrust.state", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7f2cdb000 read(4, "", 4096) = 0 close(4) = 0 munmap(0x7fd7f2cdb000, 4096) = 0 open("/var/lib/autotrust/autotrust.state", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 close(4) = 0 open("/var/run/named/named.pid", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7f2cdb000 read(4, "26800\n", 4096) = 6 read(4, "", 4096) = 0 close(4) = 0 munmap(0x7fd7f2cdb000, 4096) = 0 kill(26800, SIGHUP) = 0 close(3) = 0 munmap(0x7fd7f2cdc000, 4096) = 0 exit_group(0) = ? To make my named work again i had to manually download the ripe-ncc-dnssec-keys-new.txt file and to replace old reverse zone keys file reference in named.dnssec.keys by it.
Updated from fedora 11 to fedora 12 using yum, still the same problem.
ok, maybe this is a normal behavior (but sill strange): It seems that autotrust does not manage the "include" keyword of bind. I had to manually add the final conf files referenced by the "/etc/pki/dnssec-keys/named.dnssec.keys". Still this is not very user friendly because thos files were initially added by dnssec-conf and i dont know if they are willing to be updated by a yum update.
I'm thinking of removing autotrust. The functionality has been partially moved into unbound itself, and bind probably will (or should) get its own method for doing RFC 5011 rollover. This is furthermore hard to test because the real world has not seen any real RFC 5011 rollovers yet. Just an "updated key" is not enough. So the RIPE key test you did is not a good test. They did not use any revoke bit with RFC 5011.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.