On November 14, 2017 9:13:29 PM PST, Dave Lawrence <[email protected]> wrote: >Paul Vixie writes: >> i'm of the opposite view. we should not change behaviour without >> explicit signaling. if that means it takes 10 years to reach 50% >> penetration, like EDNS did, then that's the cost of doing business. > >Just so I'm clear, am I understanding correctly from this that you >believe a recursive server should only fall back to stale data from >cache if the request explicitly included a staleness option?
Yes. I know that coherency does not rank high in a cdn operator's priority queue, but the dns has other users also. >I ask because Bob's comment that started this thread was exploring >being able to signal staleness back when OPT was included in the >request but the option being defined by the draft wasn't included. Ah. >To me this makes three different positions we're trying to reach >consensus about, for allowing fallback to stale either: > >1) when the request explicitly signals it is ok; >2) when the request groks EDNS but might or might not understand > a staleness option; or >3) in all cases. > >My current understanding is that you and Paul are of position 1, while >I'm at 3. At first glance 2 would appear to be pretty nearly the same >as 3 as far as its permissive toward unaware clients, but >significantly it does at least provide signal you could still access >via protocol debugging (dig, tcpdump, etc). I expect you to implement 3. I expect us to document 1. 2 would be chaos, helping nobody. >_______________________________________________ >DNSOP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
