Expires and/or Verified Field

Much like the HTTP Security.txt, I think that DNS Security TXT records should implement a date field for either expiration or last verified.

The purpose of this field is to ensure the validity of the document with respect to elapsed time. There are pros and cons to either one of them, as well as pros and cons to adding both. In this essay I will...

Field Format

For both proposed fields that are discussed within this issue, the following format is proposed:

f=YYYYMMDD

The field identifier has been shortened to the first letter of the field in optimize for minimal impact to the length of the record. This could be considered optional, with the full field name also being considered valid.

The value of these proposed fields follows the ordering of ISO 8601 dates, however the field separators (-) have been removed in order to optimize for the character length restrictions inherent to TXT records. Time has been omitted from the field due to the unlikely relevance of it to a particular researcher, as well as to further optimize for the aforementioned character length restrictions.

Field Separator

Due to this additional metadata being added to existing records, a field separator must be introduced. I believe that two separators should be considered for inclusion: ; and `. Existing TXT record formats, such as SPF, make use of a space to serve as a separator, while other records, such as DKIM, may use;` as a separator. I do not believe we need to support both, but we should support at least one.

Example Record

A new record using one of these fields might look like this:

e=20210901; security_contact=example@example.com

Expires

Syntax: e=YYYYMMDD

By allowing domain administrators to set an e= field on their relevant security TXT records, it gives them a way to indicate to researchers that the data should be considered valid until a particular date, after which it should be considered out of date.

Pros of Expires

It sets a clock by which it is the domain administrator's job, or the security team's job, to update the record.
Because it is a future date, it can be easy to write automation around in order to be reminded when it's about to expire so you can update it
Aligns with the security.txt required field "Expires"

Cons of Expires

Security teams get busy, domain admins forget, and the language of the standard, as well as the very nature of the term "expires", suggests that the data included in the record is no longer valid, even if it is. As a researcher, if I find an expired policy or expired contact information, do I just yolo my research in that general direction? Otherwise, what do I do with this expired data?
Recommendation in the security.txt field is to use less than 1 year to avoid staleness, and we'd probably want to align with security.txt wherever possible. The failure modes have effectively become "This data is expired" or "this data has an expiration so far in the future that it's probably never been updated." Either of these failure modes may encourage a domain administrator to automate the updating of the field, which then ceases to ensure any validity about the contents therein.
Because it is always a future date, performing research on security TXT records themselves can be more complicated, since that research would have to regularly query the record, identify the change to e=, and then document it as such. It would not give reliable insight into how regularly the information is actually being updated other than in increments of how quickly we can scan for it.

Verified

Syntax: v=YYYYMMDD

By allowing domain administrators to set a v= field on their relevant security TXT records, it provides a way to indicate to researchers that the data is accurate as of a particular date.

Pros of Verified

Any changes to the record(s) basically have to be conducted in such a way that it's easy to also modify the verified field
Provides a marker by which to indicate to researchers that the data is no more than X days old
By using verified instead of modified, it allows us to increment the date without necessarily indicating that the policy or contact has changed.
It avoids language that suggests that the data herein is somehow invalid and instead just promises that it was valid as of a specific time.
It is an incrementing field, making it easy to store information about changes to it in a time series, enabling broader internet-wide research about how regularly security teams are validating their security contact / policies information.

Cons of Verified

This is a deviation from the security.txt field (although I would like to pitch an Optional verified field to security.txt via whatever means necessary to do so)
Because it's a present date, it is easy to set it up and then forget to ever update it, resulting in stale records. There is no upper bound on the validity of the record.
This is also prone to automation which then ceases to ensure any validity about the contents therein

Expires AND Verified

Syntax: v=YYYYMMDD e=YYYYMMDD

This approach considers the addition of both aforementioned fields.

Pros of Implementing Both

Implementing both would neatly give an upper and lower bound for the validity of any contact or policy information
Not updating within the expiration window still results in useful validity information to the researcher, who gets information from the v= field about when it was last valid.

Cons of Implementing Both

TXT records are only 255 characters long, meaning addition of two new fields for a record could be challenging for particularly long contact or policy URLs or for future uses of the record
More work on behalf of admins to update both fields, which could result in automation, which as previously identified, is not good for ensuring the validity of the information.

Conclusion

Regardless of the specific implementation chosen, the value gained from the inclusion of time-based validity for these records should be considered.

disclose / dnssecuritytxt