4 Replies Latest reply: Sep 25, 2013 10:23 AM by jcenter RSS

SOA error on DNSreport




I ran DNSreport against our domain & it came back with a Fail on the SOA Serial # agreement.  Here is one of the output lines:


ns1.villanova.edu. has Serial #: 290372 and dnsauth1.sys.gtei.net. has Serial #: 290368



I started to open a ticket with Level3 when their form had a "did you confirm this" field.  I ran dig on our domain & got the following result:


; <<>> DiG 9.8.1-P1 <<>> villanova.edu SOA host dnsauth1.sys.gtei.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29731
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 10

;villanova.edu.            IN    SOA

villanova.edu.        21600    IN    SOA    ns1.villanova.edu. hostmaster.villanova.edu. 290372 10800 3600 604800 86400



So, the SOA serial number is the same.  Why would DNSreport get this incorrect?





  • Re: SOA error on DNSreport

    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.

    • Re: SOA error on DNSreport



      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.



      • Re: SOA error on DNSreport
        Lawrence Garvin

        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! :-)

        • Re: SOA error on DNSreport



          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!)


          Thanks, again.