Updated to bind 9.9.3-P2
Lawrence K. Chen, P.Eng.
lkchen at ksu.edu
Tue Jul 30 21:49:00 UTC 2013
>From 9.9.2-P2...I had build 9.9.3, but just as I was about to deploy came the announcement to either go to 9.9.3-P1 or stay with 9.9.2-P2.
All the picky messages of this version.....there were the no SPF/SPF records for SPF/TXT....but I thought I already had SPF everywhere...but turned out there was one zone file the main SPF record had both types, but the rest were only of TXT kind. Not sure if I just missed it when I had adding SPF types long ago....or somebody had hacked them out on me. And, I hadn't noticed because I hadn't had need to make changes to those SPF records....where I have had to tweak the top level SPF record now and then....such as adding new mailservers or switching to ironport or change ~all to -all.
But, it also complained about the formerly delegated subdomains that have now become include files.....All I had done was remove the SOA and NS records....
dnssec-signzone: warning: ol$$$.ksu.edu:12: record with inherited owner (u$$$.n$$$.k-state.edu) immediately after $ORIGIN (ol$$$.k-state.edu)
dnssec-signzone: warning: oe$$$.ksu.edu:9: record with inherited owner (u$$$.n$$$.k-state.edu) immediately after $ORIGIN (oe$$$.k-state.edu)
Not sure how it came up with the message, but in these files (not including the extensive comments) were of the form:
TXT "who we are"
@ A a.b.c.d
www A a.b.c.d
While there were plenty of other such files where it didn't complain...but the TXT line was commented out. Elsewhere we publish a template of what a zone file should look like...with SOA, NS, and the commented out TXT line, should the department/unit want something there.
Putting an @ in front made the warnings go away.
And, then also after all the found SPF/TXT record but no SPF/SPF record messages, there was also the message:
Jul 30 15:07:00 ns-1 named: [ID 873579 daemon.warning] pri/$$.$$$.ksu.edu.signed:10: signature has expired
The file timestamp was Feb 13, 2013. Yeah, I guess the signature had expired. The zone file hadn't been changed since December 5, 2012. But, the system is supposed to do periodic refresh signings.... It used to do it on the 1st and 15th of every month...but it was then changed to do it every two weeks....or it was supposed to. But, I guess I neglected to confirm that the convoluted command sequence I had come up under bash, would work under cron and /bin/sh
December 5 being when I thought I needed to jump from 9.7.6-P4 to 9.9.2-P1....before taking some time off before leaving for LISA.... And, knowing that 9.9 was a desired upgrade given that this is a DNSSEC NSEC3 signed zone file where a wildcard recorded was desired....so it had been taken out until I did upgrade.
Which is odd, because as I type this...I realize that another unit (library/ezproxy) has a wildcard DNS record also DNSSEC NSEC3 signed....and they hadn't mentioned any problems to me. Though they hadn't been using a wildcard certificate for the service for some time (ipsCA certs not being widely recognized anymore being the reason wasn't enough to stay with free for .edu certs...which they had found included wildcard certs.) So they had probably had a workaround for the one external resource that was SSL, they were working on a wildcard cert now as there are now more than two external resources requiring SSL. And, that somebody that knows the cost of incommon certs has started working for them....
9.9.3 also marks the switch to compiling it 64-bit instead of 32-bit for Solaris.
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkchen at ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
More information about the bind-users