dcox@ssd.kodak.com (Don Cox ) (06/13/91)
SunOS4.1.1, Sun3/60, BIND 4.8.3
I have a primary nameserver and a secondary for ssd.kodak.com.
On the primary machine I have the following entry:
ssd.kodak.com. IN SOA ispdgate.ssd.kodak.com. dcox.ssd.kodak.com. (
32.1 ; Serial
^^^^ 1800 ; Refresh every 30 minutes
300 ; Retry every 5 minutes
604800 ; Expire after one week
3600 ) ; Minimum
If I look at the file for ssd.kodak.com on the secondary I get:
ssd IN SOA ispdgate.ssd.kodak.com. dcox.ssd.kodak.com. (
320001 1800 300 604800 3600 )
^^^^^^
If I make a change on the primary, it doesn't get transfered to the secondary
for up to 24 hours. Is this because the secondary is somehow translating the
serial number into 320001 when it's 32.1 on the primary? Wouldn't this mean
that the secondary would never get updated, since 32.1 would never be greater
than 320001?
When I changed the serial number on the primary to 320002 (so that it would
be greater than the number on the secondary) the transfers started taking
place every 30 minutes, as specified in the refresh. When I looked at the
access time for ssd.kodak.com on the secondary (ls -la) it changed every three
hours whether I incremented the serial number on the primary or not. Is this
just because the file was 'touched' to verify the serial number on the secondary,
and there wasn't an actual transfer from primary to secondary?
Thanks much.
--
Don Cox
Phone (716) 253-7121 KMX (716) 253-7998
INTERNET dcox@ssd.kodak.comkarl.kleinpaste@osc.edu (06/14/91)
dcox@ssd.kodak.com writes:
ssd.kodak.com. IN SOA ispdgate.ssd.kodak.com. dcox.ssd.kodak.com. (
32.1 ; Serial
1800 ; Refresh every 30 minutes
300 ; Retry every 5 minutes
604800 ; Expire after one week
3600 ) ; Minimum
The fundamental problem is that dotted numbers aren't supposed to be
in the SOA serial # field. From RFC 1035, section 3.3.13, page 19:
SERIAL The unsigned 32 bit version number of the original copy
of the zone. Zone transfers preserve this value. This
value wraps and should be compared using sequence space
arithmetic.
Any conversion of a dotted number to "unsigned 32 bit" is probably
implementation-dependent, and almost certainly wrong.
I use a YYMMDD encoding, e.g., 910123 means that I last updated the
zone last January 23rd.
"When in doubt, quote an RFC." --Ed Vielmetti
--karlphil@eecs.nwu.edu (William LeFebvre) (06/14/91)
In article <1991Jun13.161911.29541@ssd.kodak.com>, dcox@ssd.kodak.com (Don Cox ) writes: |> SunOS4.1.1, Sun3/60, BIND 4.8.3 |> |> I have a primary nameserver and a secondary for ssd.kodak.com. |> On the primary machine I have the following entry: |> |> ssd.kodak.com. IN SOA ispdgate.ssd.kodak.com. dcox.ssd.kodak.com. ( |> 32.1 ; Serial |> |> If I look at the file for ssd.kodak.com on the secondary I get: |> |> ssd IN SOA ispdgate.ssd.kodak.com. dcox.ssd.kodak.com. ( |> 320001 1800 300 604800 3600 ) Believe it or not, in BIND "32.1" is the same as "320001". The exact interpretation of "." is "000". Quite seriously (I looked at the code). This means that 32.10 > 32.9 by a very significant margin: 32.10 == 3200010 and 32.9 == 320009, a order of magnitude difference. I personally avoid using the "." notation for serial numbers. It it non-standard and as ill-defined (and IMHO, poor) semantics. As for the rest of it: I'm not sure why the transfers weren't taking place. But since it seems to work without the dot, I would advise just leaving it that way. William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
MAP@LCS.MIT.EDU (Michael A. Patton) (06/14/91)
Date: 13 Jun 91 20:07:55 GMT From: eecs.nwu.edu!phil@ucbvax.berkeley.edu (William LeFebvre) In article <1991Jun13.161911.29541@ssd.kodak.com>, dcox@ssd.kodak.com (Don Cox ) writes: |> ssd.kodak.com. IN SOA ispdgate.ssd.kodak.com. dcox.ssd.kodak.com. ( |> 32.1 ; Serial Believe it or not, in BIND "32.1" is the same as "320001". The exact interpretation of "." is "000". Quite seriously (I looked at the code). This means that 32.10 > 32.9 by a very significant margin: 32.10 == 3200010 and 32.9 == 320009, a order of magnitude difference. I was mostly ignoring this thread because it was obvious to me that the problem was that 32.1 was against the spec and several people had said that, but when I noticed this message it suddenly dawned on me how this brokenness was screwing this particular poor soul and why it was an object lesson about staying with the standards... I now understand what got Don Cox, he probably "increased" the serial from 31.xx (where xx was greater than 9), to 32.1 assuming the natural interpretation. Unfortunately, according to bind 32.1 << 31.11 so it doesn't think the serial increased. The right solution to this is DON'T USE THE x.y FORMAT FOR SERIAL, the spec says a single integer. Bind has offerred to let you have a non-standard system, and as I would expect with a non-standard setup, it DOES NOT WORK except under some specific circumstances that the implementer had in mind. __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology
gdmr@dcs.ed.ac.uk (George Ross) (06/17/91)
In article <9106141643.AA26522@gaak.LCS.MIT.EDU>, MAP@LCS.MIT.EDU (Michael A. Patton) writes: > I now understand what got Don Cox, he probably "increased" the serial > from 31.xx (where xx was greater than 9), to 32.1 assuming the natural > interpretation. Unfortunately, according to bind 32.1 << 31.11 so it > doesn't think the serial increased. Actually, he may have "increased" it from nnnnn.9 to nnnnn.10 and tripped over an overflow. The pre-overflow results would have been nnnnn0009 and nnnnn00010. > it DOES NOT WORK except under some specific circumstances that the > implementer had in mind. Looks to me like it's just plain broken. It could have been a good idea -- having explicit major and minor versions could cue the less sophisticated, thereby avoiding mistakes. Quite apart from the implementation being wrong, though, it rapidly runs into overflow problems. -- George D M Ross, Department of Computer Science, University of Edinburgh Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ Tel: 031-650 5147 Internet: gdmr@dcs.ed.ac.uk JANET: gdmr@uk.ac.ed.dcs
mohta@NECOM830.CC.TITECH.AC.JP (Masataka Ohta) (06/17/91)
> Believe it or not, in BIND "32.1" is the same as "320001". The exact > interpretation of "." is "000". Quite seriously (I looked at the code). > > This means that 32.10 > 32.9 by a very significant margin: > 32.10 == 3200010 and 32.9 == 320009, a order of magnitude difference. > The right solution to this is DON'T USE THE x.y FORMAT FOR SERIAL, the > spec says a single integer. Isn't it a good idea to use numbers like 320001, 320002, 320003, ... , 320010, ... , 320100, ... and then 330001 without "."? Masataka Ohta
jbryans@beach.csulb.edu (Jack Bryans) (06/17/91)
In article <BOB.91Jun17130137@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: > I find numbers like 91061203 much more readable. That denotes my > third try last Wednesday. It even sorts, if that's of any value to > you. What happens in nine years? Jack
bob@MorningStar.Com (Bob Sutterfield) (06/18/91)
In article <9106171434.AA24830@necom830.cc.titech.ac.jp> mohta@NECOM830.CC.TITECH.AC.JP (Masataka Ohta) writes:
Isn't it a good idea to use numbers like 320001, 320002, 320003,
... , 320010, ... , 320100, ... and then 330001 without "."?
I find numbers like 91061203 much more readable. That denotes my
third try last Wednesday. It even sorts, if that's of any value to
you.jnford@argos.weeg.uiowa.edu (Jay Ford) (06/18/91)
In article <JBRYANS.91Jun17110704@beach.csulb.edu>, jbryans@beach.csulb.edu (Jack Bryans) writes: |> In article <BOB.91Jun17130137@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: |> |> > I find numbers like 91061203 much more readable. That denotes my |> > third try last Wednesday. It even sorts, if that's of any value to |> > you. |> |> What happens in nine years? X.500? Or, a serial number format of yyyymmddnn (with a 4-digit year) could be used. Numbers of this format increase monotonically and will fit in an unsigned 32-bit field through the year 4294 (2^32 - 1 = 4294967295). (For brain-dead DNS implementations which do signed serial numbers, it will work through 2147.) You can even go from the yymmddnn format to the yyyymmddnn format without getting into trouble, because the numbers will always increase. ------------------------------------------------------------------------ Jay Ford, Weeg Computing Center, University of Iowa, Iowa City, IA 52242 jnford@handlebar.weeg.uiowa.edu, 319-335-5555
karl.kleinpaste@osc.edu (06/18/91)
jbryans@beach.csulb.edu writes: > I find numbers like 91061203 much more readable. That denotes my > third try last Wednesday. It even sorts, if that's of any value to > you. What happens in nine years? You bump way forward in the sequence to, e.g., 2000061203. With 2-digit sub-day identifiers as Bob uses, you can still last until the year 4294 before a 32-bit unsigned integer overflows. --karl
kre@cs.mu.oz.au (Robert Elz) (06/18/91)
jnford@argos.weeg.uiowa.edu (Jay Ford) writes: >Or, a serial number format of yyyymmddnn (with a 4-digit year) could be used. That's exactly what we use here already - ie: the serial number of AU is 1991061500 I've been using that format for ages - but now I've come to believe that the 2 digit 'nn' is unnecessary, one digit would be enough - more than 10 changes in a day just doesn't happen often enough to matter (and if it ocasionally does you can just borrow a number from tomorrow). I don't think I've ever actually gotten past about 05 ... That also solves all problems with possible signed numbers, etc, for a very long time indeed. Unfortunately switching from the 'nn' format back to a single 'n' isn't trivial, or I'd do that. kre
rickert@mp.cs.niu.edu (Neil Rickert) (06/18/91)
In article <kre.677213961@mundamutti.cs.mu.OZ.AU> kre@cs.mu.oz.au (Robert Elz) writes: >That's exactly what we use here already - ie: the serial number of AU is > > 1991061500 > >I've been using that format for ages - but now I've come to believe that >the 2 digit 'nn' is unnecessary, one digit would be enough - more than > >Unfortunately switching from the 'nn' format back to a single 'n' >isn't trivial, or I'd do that. If the software is reasonably compliant with the RFCs, changing should not be particularly difficult. Start by using: 4199106150 (i.e. with a superfluous leading 4). Use this format for a week, or so, till you are sure all outdate copies of your SOA record have timed out everywhere. Then drop the leading '4'. Wrap around beyond 2^32 is supposed to be handled smoothly, according to the RFC requirements. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
kre@cs.mu.oz.au (Robert Elz) (06/19/91)
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
barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) (06/20/91)
In article <kre.677213961@mundamutti.cs.mu.OZ.AU>, kre@cs.mu.oz.au (Robert Elz) writes: jnford@argos.weeg.uiowa.edu (Jay Ford) writes: >Or, a serial number format of yyyymmddnn (with a 4-digit year) could be used. That's exactly what we use here already - ie: the serial number of AU is 1991061500 I've been using that format for ages - but now I've come to believe that the 2 digit 'nn' is unnecessary, one digit would be enough - more than 10 changes in a day just doesn't happen often enough to matter (and if it ocasionally does you can just borrow a number from tomorrow). I don't think I've ever actually gotten past about 05 ... That also solves all problems with possible signed numbers, etc, for a very long time indeed. Unfortunately switching from the 'nn' format back to a single 'n' isn't trivial, or I'd do that. kre
lmjm@doc.ic.ac.uk (Lee McLoughlin) (06/23/91)
In article <1991Jun20.093116.19537@Daisy.EE.UND.AC.ZA> barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) writes: From: barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) Subject: Re: decimals in the serial field In article <kre.677213961@mundamutti.cs.mu.OZ.AU>, kre@cs.mu.oz.au (Robert Elz) writes: jnford@argos.weeg.uiowa.edu (Jay Ford) writes: >Or, a serial number format of yyyymmddnn (with a 4-digit year) could be used. That's exactly what we use here already - ie: the serial number of AU is 1991061500 I've been using that format for ages - but now I've come to believe that the 2 digit 'nn' is unnecessary, one digit would be enough - more than 10 changes in a day just doesn't happen often enough to matter (and if it ocasionally does you can just borrow a number from tomorrow). I don't think I've ever actually gotten past about 05 ... Locally we use this format with a two digit nn bit. We use hesiod to export more and more of the /etc type files around (passwd, services, printcap, automounter maps...). It is not that hard to get more than 10 passwd entry changes in a day. -- -- Lee McLoughlin phone: 071 589 5111 X 5085 fax: 071 581 8024 Department of Computing, Imperial College, 180 Queens Gate, London SW7 2BZ, UK Janet: lmjm@uk.ac.ic.doc Uucp: lmjm@icdoc.UUCP (or ..!ukc!icdoc!lmjm) DARPA: lmjm@doc.ic.ac.uk (or lmjm%uk.ac.ic.doc@nsfnet-relay.ac.uk)