Subject: Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 2 Dec 2019 11:33:30 -0800

Hi Brian,

I agree that this updated text provides more clarity about why the
change is being made, but I am not sure that it fully addresses all of
the concerns you raised, and would appreciate your thoughts.

Specifically, you had raised the possibility of existing, fielded,
implementations that would behave poorly when presented with input that
has the sign bit set.  The DNS-OARC data that indicates such packets have
not been seen in the wild serves only to amplify this uncertainty, since
we have no reason to believe that such a codepath would have been triggered
already and diagnosed.  Isn't there still some latent risk of such
fielded implementations that would be incompatible with this change if it
ever did show up on the wire?

Thanks,

Ben

On Fri, Oct 25, 2019 at 11:23:42AM +1300, Brian E Carpenter wrote:
> Hi Dave,
> 
> Thanks. I think that covers it. I still suspect that the original reason
> was concern about int versus uint confusion, but the new text is fine.
> 
> Regards
>    Brian Carpenter
> 
> On 25-Oct-19 08:35, Dave Lawrence wrote:
> > [email-masked] writes:
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09
> > 
> > This revision addressed the one remaining outstanding issue that Brian
> > Carpenter raised in the Gen-ART Last Call Review.  The following text
> > was added to explain why a TTL with the high-order bit set is now
> > handles as a large positive number (then capped down) rather than a
> > negative number (and treated as zero).
> > 
> >     As for the change to treat a TTL with the high-order bit set as
> >     positive and then clamping it, as opposed to [RFC2181] treating it as
> >     zero, the rationale here is basically one of engineering simplicity
> >     versus an inconsequential operational history.  Negative TTLs had no
> >     rational intentional meaning that wouldn't have been satisfied by just
> >     sending 0 instead, and similarly there was realistically no practical
> >     purpose for sending TTLs of 2^25 seconds (1 year) or more.  There's
> >     also no record of TTLs in the wild having the most significant bit set
> >     in DNS-OARC's "Day in the Life" samples.  With no apparent reason for
> >     operators to use them intentionally, that leaves either errors or
> >     non-standard experiments as explanations as to why such TTLs might be
> >     encountered, with neither providing an obviously compelling reason as
> >     to why having the leading bit set should be treated differently from
> >     having any of the next eleven bits set and then capped per Section 4.
> > 
> > I also removed the phrasing about 2181's handling of this issue as a
> > "curious suggestion".  I recognize it could have an unintended
> > negative connotation against the original authors, though when I wrote
> > the sentence originally I meant it only with its neutral denotation.
> > It was curious to me only because no rationale was provided as to why
> > that particular choice had been made, despite the current assertion
> > that it was obvious as to why.
> > 
> > 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Dec 2019 10:02:18 +1300

Ben,

It's certainly a judgment call, but it really does seem that uint_32t has been around so long now that surviving implementations that misuse int for this surely have many other problems too. We'd be talking about resolver code that hasn't been refurbished since 1997 *and* a DNS record with an absurdly large TTL.

I think DNSOP participants are better placed than me to comment.

Regards
   Brian Carpenter

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 2 Dec 2019 17:33:53 -0500

Benjamin Kaduk writes:
> Isn't there still some latent risk of such fielded implementations
> that would be incompatible with this change if it ever did show up
> on the wire? 

There's always some risk with any change, right?  I'm not trying to be
flatly dismissive of the concern. I do, however, find vague,
unsubstantiated concerns about the behaviour of unidentified software
to be a poor basis for an engineering decision.

Given that no circumstance has been identified where this is an issue,
the next best thing is a risk analysis of the potential, and I've
previously gone over the possible failure scenarios.  The worst case
identified is that someone was actually sending a negative TTL with
the intent of it being cached as 0 (leaving open the question about
why they'd make that choice), but which would now be treated by new
software as very large and almost universally capped at something more
sane but still on the order of days instead of an augenblick.  

As failure cases go, my subjective opinion is that this is not vexing,
especially without any evidence that someone is making meaningful
operational use of the treat-as-zero logic.  If they were, it seems to
me that the people running the authority doing that and needing the
dynamic remapping it implies would be highly incentivized to update
their relatively smaller footprint of servers to behave more
reasonably.

On the flip side, authorities sending an obnoxiously large TTL (2^31+)
would now get the expected behviour of being cached as long as
possible rather than 0.  Of course I personally would expect them to
get their act together and send more sane TTLs, too, in no small part
because in practical terms there are smaller values they could use to
achieve the same aims without having to even deal with the question of
the high order bit.  The risk on this end is that new software,
written with the expectation that 2^31+ TTLs would be treated as
basically equivalent to 2^31-1 and then capped by modern resolvers,
might send to an old treat-as-0 resolver and get surprisingly frequent
requeries for what the operator intended to be a static response.  If
this traffic were for a popular enough name to cause packet volume to
rise above the usual noise in any sort of remotely problematic way,
the authority operators are then highly incentivized to change as
well.  This is all hinging on a lot of "ifs" though, starting that
chain with it being new behavior by an authority to start sending such
TTLs.

If you see some greater risk potential, I'll gladly think on that some
more.  I certainly don't want to cause any harm either; I just don't
see it here.