| IANA has added the following in the "Email Authentication Result | |
| Names" registry: | |
| +=========+===========+===========+=======+==================+======+ | |
| |Code | Existing/ | Defined |Auth | Meaning |Status| | |
| | | New Code | |Method | | | | |
| +=========+===========+===========+=======+==================+======+ | |
| |none | existing | [RFC8601] |dmarc | No DMARC policy |active| | |
| | | | |(added)| record was | | | |
| | | | | | published for | | |
| from reading the authors-tools site on schema https://authors.ietf.org/en/templates-and-schemas | |
| I believe you can replace your <!DOCTYPE rfc SYSTEM "rfc2629.dtd" > | |
| with this | |
| <?xml-model href="rfc7991bis.rnc"?> | |
| <!DOCTYPE rfc [ | |
| <!ENTITY nbsp " "> |
| 5.3. General Record Format | |
| auth: (comma-separated plain-text list of dmarc-methods; OPTIONAL; default is "spf,dkim") | |
| Indicates the supported authentication methods. The order of the list is not significant and | |
| unknown methods are ignored. Possible values are as follows: | |
| dkim: Authenticate with DKIM | |
| spf: Authenticate with SPF | |
| An empty list is a syntax error. |
| https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ | |
| Consistency for CDS/CDNSKEY and CSYNC is Mandatory | |
| 114 | |
| Mark: CDS records are no different than any others | |
| One NS might be down, which would stop the | |
| Peter: This is telling the parent how to act when faced with inconsistent information | |
| Viktor: There might be hidden masters |
| ## Introduction | |
| [In which we include some motivations about the document, who it is for, explain how it is organized, and offer a money-back guarantee.] | |
| * Audience | |
| - Anonymous/Public | |
| - Account | |
| - Contract - Employees/Students |
| Various Internet protocols and applications require some mechanism for determining whether two domain names have some | |
| relation. The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the | |
| types of relations relevant. | |
| Some examples of the type of relations we are looking to address | |
| * Cookie that have same origin in browsers, as Paul described. | |
| * CA wildcards, it's OK to sign a cert for *.mycompany.co.uk or *.mycompany.com but not for *.co.uk or *.com. |
| ; Current ABNF | |
| ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". | |
| non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E | |
| ; non-digit is VCHAR minus DIGIT | |
| non-digit = %x21-2F / %x3A-7E | |
| ; dec-octet is a number 0-255 as a three-digit decimal number. | |
| dec-octet = ( "0" / "1" ) 2DIGIT / | |
| "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) | |
| escaped = "\" ( non-digit / dec-octet ) | |
| contiguous = 1*( non-special / escaped ) |
This appears to be every RFC from rfc-editor.org which has DNSSEC in the abstract or title
| Number | Title | Included? | Reasons | More Info | Status |
|---|---|---|---|---|---|
| RFC 9276 a.k.a. BCP 236 | Guidance for NSEC3 Parameter Settings | Yes | Errata | Best Current Practice | |
| RFC 9157 | Revised IANA Considerations for DNSSEC | Yes | Relevant | Proposed Standard |
| ; | |
| ; Extracted ABNF from RFC7489 | |
| ; | |
| ; URI rfc3986 | |
| ; DIGIT rfc5234 | |
| ; WSP rfc5234 | |
| ; Keyword rfc5321 | |
| ; ALPHA rfc5234 | |
| ; domain rfc5322 |