Thanks Kim, Good to know it is being considered! Terry
On 10 Oct 2024, at 3:31 AM, Kim Davies <kim.davies@iana.org> wrote:
Hi Terry, Hi all,
Quoting Terry Manderson on Wednesday October 09, 2024:
... On the face of it, I see that as a recognition that the method to update the hints files is glacial. More deeply I think it further promotes ossification in a system that should be more agile.
On this, IANA and Verisign have been discussing a modest idea that may help address this. Currently the root hints file has a Last Updated date in the commentary that doesn't necessarily correlate to a change in the underlying data.
The idea was to evolve this file to regularly republish the root hints file, similar to the root zone itself but on a lesser cadence, regardless of whether the underlying data has changed. Then in conjuction with that, we rev the publication date, and add an explicit expiry date into the future. This would send a signal for implementers to add some monitoring to make sure their hints file hasn't expired and/or implement a update mechanism rather than treating it as static data.
I could see the header of the hints file having a stanza something like this:
; Last-Update: YYYY-MM-DD ; Issued: YYYY-MM-DD ; Expires: YYYY-MM-DD
The hints file would get re-issued whenever there is an underlying change to the data, but also on a regular interval (e.g. 1st of the month). Then the expires date would be some period beyond that based on how frequently we'd like implementors to revalidate the data, e.g.
; Issued: 2024-10-01 ; Expires: 2025-03-31
Tooling can kick up warnings or corrective action if it tries to ingest the hints file and sees the current date is beyond the Expires date.
The leap second data that IANA publishes has a similar concept of being reissued every 6 months, even though the underlying data hasn't changed since 2017.
kim