On 6/1/23 3:57 PM, William Herrin wrote:
Certainly we would appreciate other opinions about what the right length
of a change-over time would be, especially from the operational
communities that will be most impacted by this change.
A server generation is about 3 years before it's obsolete and is
generally replaced. I suggest making the old address operable for two
generations (6 years) and black-holed for another generation (3 more
years).
I'm not convinced it should be based entirely on physical server rollovers, but certainly you could
look at it through the lens of DNS resolver software security update support timelines. As far as
I'm aware, RHEL is one of the longest-available support timelines, with RHEL 6 released in 2010
still supported into 2026 (per Wikipedia).
I assume RHEL would ship a root hints update during that time, but such things can slip through
pretty easily as its not a security update.
You could also look at the DNSSEC KSK rollover as a natural cutoff point - the KSK rollover in
October 2018 used a KSK created in October 2016, which is a substantially more aggressive timeline
than a 3 year physical server rollover (I'm gonna bet you can find *tons* of folks on this list
running physical servers way older than 3 years with production DNS resolvers on them) or 15+ year
RHEL support timeline.
As properly configured resolutions will fail after a new KSK rollover, its probably not unreasonable
to stop responding (correctly) after a future KSK rollover.
Not sure what the operation cost is to keep responding on another IP block, but I'm gonna assume its
not a whole lot, so absent a strong reason ISTM its easy to air on the side of responding for a
long, long time rather than not responding.
Perhaps make it a false responder in the last of those 9 years so that
anybody who is truly that far behind on their software updates gets
enough of a spanking to stop sending you packets. You'll have problems
repurposing the address and its subnet until folks stop sending you
DNS query packets, even if you don't respond to them.
Not a bad idea, you could also put a nice warning page up informing them that their DNS resolver is
broken and not enforcing DNSSEC while you're at it :)
Matt
