Following fields violates the RFC 1912
Decimal serial numbers have been officially deprecated in recent BIND versions.
The recommended syntax is YYYYMMDDnn (YYYY=year, MM=month, DD=day, nn=revision number.
This won't overflow until the year 4294.
weeks are suggested values.
No, that's not the issue. The issue is the claim that the SOA serial number from dnsauth1.sys.gtei.net is different than the one from ns1.villanova.edu for the villanova.edu domain. DNSreport has it having a different number than what dig reports.
1 of 1 people found this helpful
There are actually two issues at work here, John.
From your first message:
ns1.villanova.edu. has Serial #: 290372 and dnsauth1.sys.gtei.net. has Serial #: 290368
Regarding the differences in the serial numbers, this is a normal operation of DNS, and is not really something to be concerned with in itself. ns1.villanova.edu has the latest zone file (Serial #290372), and dnsauth1.sys.gtei.net has not yet updated that zone file, so it reports an older serial number (290368). No doubt, dnsauth1.sys.gtei.net resolved that issue within the defined refresh window, which appears to be 3 hours.
There is, however, a second issue, and that is the issue that DNSStuff is actually flagging.
The Serial Number does not conform to the specifications as defined in the RFC. Serial Numbers are now expected to be TEN DIGIT sequences of the form YYYYMMDD## where ## is a sequential number allowing for multiple changes within a single day. (Many organizations rarely process more than one change a day, so quite often ## will simply be 00.)
The serial number for villanova.edu (290372) does not conform to the current RFC specifications. Even if ns1.villanova.edu and dnsauth1.sys.geti.net have the same serial numbers, DNSStuff will still flag the SOA entry for the non-conformant serial number.
It's also apparently flagging the Expire interval for being too long. The Expire interval tells secondary servers when they MUST STOP using zone data obtained from the primary. The Expire interval for villanova.edu appears to be defined as 604800 seconds, which is 168 days (a bit short of six months). Suggested values are 2-4 weeks, and values greater than 28 days generally also get flagged. The intent of this value (as described in RFC1912) is that the value should be greater than howeverlong a major outage might typically last. Six months is a pretty catastrophic outage for an EDU domain! :-)
Thanks for replying. I completely forgot about the refresh window, that makes perfect sense. We had an issue this summer with them not being in sync with our domain, which they quickly resolved. I thought I was having deja vu when I saw the SOA serial number not up to date again. On the structure of the serial number, I recognize the issue, but we have a program that updates DNS with a simple +1 to the serial number. Something on our todo list to change. The expire interval I didn't even notice, we'll update that shortly. Thanks for pointing that out. (It hasn't been changed in years, don't ask me why it was made so long, I don't remember!)