Subject: [DNSOP] valid value range for SOA REFRESH/RETRY/EXPIRE

From: 神明達哉 <[email-masked]>
Date: Thu, 17 Oct 2019 16:11:40 -0700

I have a question for which I believe there's an answer already that I
couldn't find: what's the valid range for SOA REFRESH/RETRY/EXPIRE
values?

RFC1035 says:

  REFRESH         A 32 bit time interval ...
  RETRY           A 32 bit time interval ...
  EXPIRE          A 32 bit time value ...

and since it explicitly uses "unsigned" for SERIAL and MINIMUM, e.g:

  SERIAL          The unsigned 32 bit version number of the original copy

one obvious interpretation is that REFRESH/RETRY/EXPIRE are signed 32
bit integers.  And, since negative values for these don't make much
sense, we might even interpret it similar to RR TTLs as clarified in
RFC2181, i.e., 0 <= REFRESH/RETRY/EXPIRE <= 2^31-1.

Is this correct?  Implementations seem to vary on this point, btw.
>From my quick experiment with some code reading,
- BIND 9 accepts any unsigned 32-bit values
- Same for Knot
- NSD treats them like TTL (values >= 2^31 are reduced to the "default
  TTL" value)
(I've only checked at the primary side; I didn't do any test how the
secondary side of the implementation uses these values when they are
very large).

Such huge values for these parameters don't make sense in practice
anyway, so this is probably a pedantic question.  But if anyone knows
an authoritative reference that can answer it I'd appreciate it very
much.

Thanks,

--
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Oct 2019 10:25:29 +1100

> On 18 Oct 2019, at 10:11 am, 神明達哉 <[email-masked]> wrote:
> 

REFRESH         A 32 bit time interval before the zone should be
                refreshed.

RETRY           A 32 bit time interval that should elapse before a
                failed refresh should be retried.

EXPIRE          A 32 bit time value that specifies the upper limit on
                the time interval that can elapse before the zone is no
                longer authoritative.

> bit integers.

They are all intervals.  How do you have a negative interval?

>  And, since negative values for these don't make much
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Thu, 17 Oct 2019 16:46:22 -0700

At Fri, 18 Oct 2019 10:25:29 +1100,

> They are all intervals.  How do you have a negative interval?

I actually didn't expect they can be negative.  My main question is
whether values larger than 2^31-1 should be considered valid.

--
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Oct 2019 10:49:40 +1100

> On 18 Oct 2019, at 10:46 am, 神明達哉 <[email-masked]> wrote:
> 

Well they are in range.  That said slaves can and do apply sanity
checks to these values.  Both too low and too high cause operational
problems.

Mark

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 18 Oct 2019 11:28:20 -0400

[ Classification Level: PUBLIC ]

Apologies if this sounds condescending, but I haven't seen RFC 1982
mentioned in this thread so far.

While that RFC may not be the last word on the acceptable values of
SOA.SERIAL, in normal operation, it does contain some advice on how to
effectuate (or avoid) a "reset" of a zone's serial.

                          - Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 18 Oct 2019 11:29:54 -0400

Sorry, I misread the thread. I thought it was for all values in the SOA.
RFC 1982 is specific to only the serial, not relevant to
REFRESH/RETRY/EXPIRE.

Not enough caffeine...

                                                               - Kevin

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Oct 2019 13:04:19 -0700

At Fri, 18 Oct 2019 10:49:40 +1100,
Mark Andrews <[email-masked]> wrote:

> Well they are in range.

I was not sure if they are really "in range".  If the RFC explicitly
says "*unsigned* 32-bit time interval", yes, but with the lack of
"unsigned" (while explicitly using "unsigned" for SERIAL and MINIMUM)
it seemed ambiguous.  That's why I asked the question in the first
place.

> That said slaves can and do apply sanity

Agreed, I already noted essentially the same point in my first message.

Anyway, my interpretation of the responses so far (or the lack of
thereof) is that no one knows (or cares about) the exact range (per
protocol standard) for these parameters.  That's not the best result I
wished to see, but at least it looks like I didn't miss anything
obvious for others.

--
JINMEI, Tatuya

---

From: Tony Finch <[email-masked]>
Date: Mon, 21 Oct 2019 13:18:34 +0100

> wished to see, but at least it looks like I didn't miss anything

I would be inclined to treat them like TTL values and follow section 8 of
RFC 2181, but as Mark said, the signedness doesn't affect the behaviour
since you'll be clamping the values between something like a few minutes
and a few weeks.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth: Northeast 3 or 4, becoming variable 3 or less later.
Smooth or slight, occasionally moderate at first in west Plymouth. Showers.
Good.