Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!spool.mu.edu!munnari.oz.au!cs.mu.OZ.AU!cs.mu.oz.au!kre From: kre@cs.mu.oz.au (Robert Elz) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: decimals in the serial field Message-ID: Date: 19 Jun 91 08:53:24 GMT References: <6529@ns-mx.uiowa.edu> <1991Jun18.143602.18569@mp.cs.niu.edu> Sender: news@cs.mu.OZ.AU Organization: Comp Sci, University of Melbourne, Australia Lines: 26 rickert@mp.cs.niu.edu (Neil Rickert) writes: >If the software is reasonably compliant with the RFCs, The softwre in issue is BIND, which bears only a cursory resemblance to the RFC's ... The test in 4.8.3 is ... if (zp_start.z_serial > serial_no || serial_no == 0) (the variables are unsigned). This particular part of BIND bears even less than usual resemblance to the RFC's ... Even if a new BIND with this (not the most serious of BIND's bugs) fixed were distributed, its not worth the hassle of making sure that all secondary servers has updated, just to avoid some possible problem with the high order bit becomes set around 2137 (by which time, just maybe, a working BIND might exist). But I do believe that all BIND's have treated this field as unsigned, so the real problem won't come for another couple of millenia, if BIND isn't fixed by then, people using the yyyymmddnn scheme are going to be in all kinds of trouble. Frankly, I kind of suspect that I won't really care... kre