Skip to content

Commit

Permalink
update documents
Browse files Browse the repository at this point in the history
  • Loading branch information
github-actions committed Nov 7, 2023
1 parent 3d0ff02 commit 982dad6
Show file tree
Hide file tree
Showing 7 changed files with 159 additions and 1 deletion.
25 changes: 25 additions & 0 deletions data/RFC9460.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
<reference anchor="RFC.9460" target="https://www.rfc-editor.org/info/rfc9460">
<front>
<title>Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)</title>
<author fullname="B. Schwartz" initials="B." surname="Schwartz">
<organization/>
</author>
<author fullname="M. Bishop" initials="M." surname="Bishop">
<organization/>
</author>
<author fullname="E. Nygren" initials="E." surname="Nygren">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2023" month="November"/>
<workgroup>dnsop</workgroup>
<abstract>
<t>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC9460"/>
<seriesInfo name="RFC" value="9460"/>
<seriesInfo name="IETF"/>
</reference>
19 changes: 19 additions & 0 deletions data/RFC9461.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
<reference anchor="RFC.9461" target="https://www.rfc-editor.org/info/rfc9461">
<front>
<title>Service Binding Mapping for DNS Servers</title>
<author fullname="B. Schwartz" initials="B." surname="Schwartz">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2023" month="November"/>
<workgroup>add</workgroup>
<abstract>
<t>The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC9461"/>
<seriesInfo name="RFC" value="9461"/>
<seriesInfo name="IETF"/>
</reference>
31 changes: 31 additions & 0 deletions data/RFC9462.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
<reference anchor="RFC.9462" target="https://www.rfc-editor.org/info/rfc9462">
<front>
<title>Discovery of Designated Resolvers</title>
<author fullname="T. Pauly" initials="T." surname="Pauly">
<organization/>
</author>
<author fullname="E. Kinnear" initials="E." surname="Kinnear">
<organization/>
</author>
<author fullname="C. A. Wood" initials="C. A." surname="Wood">
<organization/>
</author>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<author fullname="T. Jensen" initials="T." surname="Jensen">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2023" month="November"/>
<workgroup>add</workgroup>
<abstract>
<t>This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC9462"/>
<seriesInfo name="RFC" value="9462"/>
<seriesInfo name="IETF"/>
</reference>
31 changes: 31 additions & 0 deletions data/RFC9463.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
<reference anchor="RFC.9463" target="https://www.rfc-editor.org/info/rfc9463">
<front>
<title>DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)</title>
<author role="editor" fullname="M. Boucadair" initials="M." surname="Boucadair">
<organization/>
</author>
<author role="editor" fullname="T. Reddy.K" initials="T." surname="Reddy.K">
<organization/>
</author>
<author fullname="D. Wing" initials="D." surname="Wing">
<organization/>
</author>
<author fullname="N. Cook" initials="N." surname="Cook">
<organization/>
</author>
<author fullname="T. Jensen" initials="T." surname="Jensen">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2023" month="November"/>
<workgroup>add</workgroup>
<abstract>
<t>This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC9463"/>
<seriesInfo name="RFC" value="9463"/>
<seriesInfo name="IETF"/>
</reference>
28 changes: 28 additions & 0 deletions data/RFC9464.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
<reference anchor="RFC.9464" target="https://www.rfc-editor.org/info/rfc9464">
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS</title>
<author fullname="M. Boucadair" initials="M." surname="Boucadair">
<organization/>
</author>
<author fullname="T. Reddy.K" initials="T." surname="Reddy.K">
<organization/>
</author>
<author fullname="D. Wing" initials="D." surname="Wing">
<organization/>
</author>
<author fullname="V. Smyslov" initials="V." surname="Smyslov">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2023" month="November"/>
<workgroup>ipsecme</workgroup>
<abstract>
<t>This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ).</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC9464"/>
<seriesInfo name="RFC" value="9464"/>
<seriesInfo name="IETF"/>
</reference>
24 changes: 24 additions & 0 deletions data/RFC9491.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
<reference anchor="RFC.9491" target="https://www.rfc-editor.org/info/rfc9491">
<front>
<title>Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)</title>
<author role="editor" fullname="J. Guichard" initials="J." surname="Guichard">
<organization/>
</author>
<author role="editor" fullname="J. Tantsura" initials="J." surname="Tantsura">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2023" month="November"/>
<workgroup>spring</workgroup>
<abstract>
<t>This document describes the integration of the Network Service Header (NSH) and Segment Routing (SR), as well as encapsulation details, to efficiently support Service Function Chaining (SFC) while maintaining separation of the service and transport planes as originally intended by the SFC architecture.</t>
<t>Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFFs) along a given Service Function Path (SFP), whereas the NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata.</t>
<t>This integration demonstrates that the NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using the NSH.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC9491"/>
<seriesInfo name="RFC" value="9491"/>
<seriesInfo name="IETF"/>
</reference>
2 changes: 1 addition & 1 deletion flag.txt
Original file line number Diff line number Diff line change
@@ -1 +1 @@
Mon Nov 6 15:14:20 UTC 2023
Tue Nov 7 15:13:18 UTC 2023

0 comments on commit 982dad6

Please sign in to comment.