From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Description of problem: Possibly not a bug. But in previous versions of the Fedora core tests an install of the bind package would create a pre-generated secret key in the /etc/rndc.key file. In test 3 however this appears to missing with the file containing nothing more than: key "rndckey" { algorithm hmac-md5; secret "@KEY@"; }; Lack of a pre-generated secret key means that named will not start "out-of-the-box". I'm not sure if this was an oversight or a delibrate move to force admins to create their own key. Version-Release number of selected component (if applicable): bind-9.2.2.P3-6 How reproducible: Always Steps to Reproduce: 1. Install minimal base of Fedora test 3 2. Install bind rpm 3. Attemtpt to start named - Although he start scripts claims success a check of the logs shows that due to the lack of a proper secret key it exists. Actual Results: named failes to start with default config Expected Results: To get it to work out-of-the-box perhaps the key should be there? Additional info:
I see the exact same behaviour : it appears like named starts ok, but exits due to a fatal error due to the bade base64 encoding of the duff key in /etc/rndc.key. This was not the case for RH8 or RH9; where a key was auto-generated during install. For Fedora Core 0.95 test 3, I used rndc-confgen and copied the proper base64 key to /etc/rndc.key, replacing "@KEY@". This creates a new key every time it's run; but you do have to manually copy the key to the file. named now starts ok after the above key generation.
Fixed in bind-9.2.2.P3-8 on Rawhide. You must uninstall and then reinstall, to get the key generated. Basically the install was changed to not do this on an upgrade, but there was a bug. Dan