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

[Dave Lawrence <[e-mail]>]

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.