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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
