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/TXTbut 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 agoor somebody had hacked them out on me. And, I hadn't noticed
because I hadn't had need to make changes to those SPF recordswhere I have
had to tweak the top level SPF record now and thensuch 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[29380]: [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 weeksor 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-P1before 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 desiredso 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 signedand
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: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
