Closed 0xdade closed 1 year ago
@0xdade I like that, thank you... I'm sorry it took this long to get back to you (mad year!), so the one goal of this project was to make contact where there isn't any and having a means of contact is the level one complete for us and that generally granted us less concern about the character space, altho extra records could easily be created for information stores for the things people cared about sharing ( I expect that will happen if NUM protocol takes off
@yesnet0 I do like this, I think it's a scope creep (being pedantic) but we could use it as an example of other good information to share
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:
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:
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
Cons of Expires
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
verified
fieldverified
instead ofmodified
, it allows us to increment the date without necessarily indicating that the policy or contact has changed.Cons of Verified
Expires AND Verified
Syntax:
v=YYYYMMDD e=YYYYMMDD
This approach considers the addition of both aforementioned fields.
Pros of Implementing Both
v=
field about when it was last valid.Cons of Implementing Both
Conclusion
Regardless of the specific implementation chosen, the value gained from the inclusion of time-based validity for these records should be considered.