ADD Working Group D. Liu Internet-Draft Jinan University Intended status: Standards Track Z. Yan Expires: 21 March 2027 CNNIC G. Geng Jinan University 17 September 2026 PPP IPCP Extensions for Encrypted DNS Server Negotiation draft-liu-add-ppp-edns-negotiation-03 Abstract This document defines extensions to the Point-to-Point Protocol (PPP) Internet Protocol Control Protocol (IPCP) for negotiating encrypted DNS resolver configurations. Two IPCP Configuration Options are defined for primary and secondary encrypted DNS resolvers. Each option carries an Authentication Domain Name (ADN), an explicit list of resolver IP addresses, and Service Parameters (SvcParams) using the wire format defined by RFC 9460. The design supports DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ), while maintaining coexistence with the plaintext DNS configuration mechanism defined by RFC 1877. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires 21 March 2027 [Page 1] Internet-Draft PPP Encrypted DNS September 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 3 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Primary Encrypted DNS Server Option (133) . . . . . . . . . . 5 6. Secondary Encrypted DNS Server Option (134) . . . . . . . . . 5 7. Length Fields . . . . . . . . . . . . . . . . . . . . . . . . 6 8. ADN Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Address List . . . . . . . . . . . . . . . . . . . . . . . . 6 10. SvcParams . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. Wire-Format Validation . . . . . . . . . . . . . . . . . . . 8 12. IPCP Negotiation . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Client Configure-Request . . . . . . . . . . . . . . . . 8 12.2. Server Response . . . . . . . . . . . . . . . . . . . . 9 12.3. Duplicate Options . . . . . . . . . . . . . . . . . . . 9 13. Primary and Secondary Resolver Selection . . . . . . . . . . 9 14. Coexistence with RFC 1877 . . . . . . . . . . . . . . . . . . 9 15. Encrypted DNS Transport Use . . . . . . . . . . . . . . . . . 10 16. Transport Mappings . . . . . . . . . . . . . . . . . . . . . 10 17. TLS Authentication . . . . . . . . . . . . . . . . . . . . . 10 18. Security Considerations . . . . . . . . . . . . . . . . . . . 11 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 20. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 20.1. Basic DoT Configuration . . . . . . . . . . . . . . . . 12 20.2. DoH with Custom Path . . . . . . . . . . . . . . . . . . 12 20.3. Dual-Stack Resolver Address List . . . . . . . . . . . . 13 21. Implementation Considerations . . . . . . . . . . . . . . . . 14 22. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 14 23. Normative References . . . . . . . . . . . . . . . . . . . . 14 24. Informative References . . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Liu, et al. Expires 21 March 2027 [Page 2] Internet-Draft PPP Encrypted DNS September 2026 1. Introduction The Point-to-Point Protocol (PPP) [RFC1661] includes the Internet Protocol Control Protocol (IPCP), which is used to configure IPv4 parameters for a PPP peer. RFC 1877 [RFC1877] defines an IPCP extension for communicating DNS name server addresses, but those addresses identify plaintext DNS resolvers and do not provide information needed to configure encrypted DNS transports. This document defines two IPCP Configuration Options for encrypted DNS: one for a primary resolver and one for a secondary resolver. Each option is a complete resolver configuration and contains an Authentication Domain Name (ADN), an explicit address list, and Service Parameters (SvcParams). The SvcParams use the encoding specified by RFC 9460 [RFC9460] so that existing Service Binding parameter definitions can be reused without defining a new parameter registry. The design supports DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484], and DNS over QUIC (DoQ) [RFC9250]. It does not define a new encrypted-DNS transport protocol or a new representation for ALPN, port, or DoH path parameters. The encrypted DNS options coexist with RFC 1877. When both encrypted DNS and plaintext DNS configuration are available, the encrypted DNS configuration takes precedence. If the encrypted DNS service cannot be used, the client MAY fall back to plaintext DNS configuration obtained through RFC 1877, subject to local policy and the requirements of RFC 1877. 2. Conventions and Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. *ADN* means Authentication Domain Name, encoded as a DNS wire-format domain name and used for TLS server identity validation. *Resolver Configuration* means one complete Option 133 or Option 134 option containing an ADN, an address list, and SvcParams. 3. Protocol Model This document defines exactly two encrypted DNS IPCP Configuration Options: Liu, et al. Expires 21 March 2027 [Page 3] Internet-Draft PPP Encrypted DNS September 2026 * Option 133: Primary Encrypted DNS Server. * Option 134: Secondary Encrypted DNS Server. Option 133 is the Primary Encrypted DNS Server Option, and Option 134 is the Secondary Encrypted DNS Server Option. IANA is requested to assign these values from the PPP IPCP Configuration Option Types registry. Each Option 133 or Option 134 independently contains all information required to configure one encrypted DNS resolver. There is no independent configuration option for encryption parameters. A client MUST NOT treat multiple instances of the same Option 133 or Option 134 as an ordered list or apply a "last received wins" rule. Duplicate instances are invalid. Processing of malformed or duplicate Configuration Options follows the general IPCP rules in RFC 1661 [RFC1661]. The primary and secondary roles do not define an IPCP renegotiation procedure. Selection and failover between the two successfully negotiated resolver configurations are local client policy. 4. Option Format Both Option 133 and Option 134 use the same option format. The only difference is the Configuration Option Type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ADN Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADN ... | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address List | Address List | SvcParams ... | | Length | ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SvcParams ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Encrypted DNS Configuration Option Format The fields are: * *Type:* One of the two IANA-assigned IPCP Configuration Option Types. Liu, et al. Expires 21 March 2027 [Page 4] Internet-Draft PPP Encrypted DNS September 2026 * *Length:* The total length of the Configuration Option, including Type and Length. * *ADN Length:* One octet indicating the length of the ADN field in octets. * *ADN:* The DNS wire-format Authentication Domain Name. * *Address List Length:* One octet indicating the length of the Address List field in octets. * *Address List:* A sequence of address-family identifiers and IP addresses. * *SvcParams Length:* One octet indicating the length of the SvcParams field in octets. * *SvcParams:* Service Parameters encoded using the wire format defined by RFC 9460. The complete option, including all nested fields, MUST fit within the PPP MRU. This document does not define fragmentation of an individual Configuration Option. An implementation MUST NOT silently truncate an option. 5. Primary Encrypted DNS Server Option (133) Option 133 identifies the primary encrypted DNS resolver configuration. An Option 133 MUST contain an ADN field, an Address List field, and a SvcParams field, each preceded by its corresponding length field. A client may use an empty Address List as a discovery probe as described in Section 12. 6. Secondary Encrypted DNS Server Option (134) Option 134 identifies the secondary encrypted DNS resolver configuration. Option 134 has exactly the same field structure and validation requirements as Option 133. The distinction between primary and secondary is determined by the Configuration Option Type, not by a field inside the option. Liu, et al. Expires 21 March 2027 [Page 5] Internet-Draft PPP Encrypted DNS September 2026 7. Length Fields ADN Length, Address List Length, and SvcParams Length are each one octet. The outer PPP Configuration Option Length field is also one octet, as defined by IPCP. Consequently, the complete option cannot exceed 255 octets. A receiver MUST verify that every inner length is no greater than the number of octets remaining in the outer Configuration Option. A receiver MUST reject or otherwise process as malformed any option whose inner lengths cause parsing to extend beyond the outer option boundary. This document does not define larger inner length fields. Any future extension requiring subfields larger than 255 octets would require a revision or a new option format. 8. ADN Encoding The ADN is encoded using the DNS wire-format domain-name representation defined by RFC 1034 and RFC 1035 [RFC1034] [RFC1035]. The ADN MUST terminate with the root label. It MUST contain at least one non-root label and MUST NOT contain DNS compression pointers. The encoded ADN, including the terminating root label, MUST NOT exceed 255 octets. A client that uses an ADN of zero length is making a configuration request or probe and is not presenting a resolver identity. A server response that supplies a usable resolver configuration SHOULD contain a valid non-empty ADN. 9. Address List The Address List consists of zero or more address entries. Each entry begins with a one-octet address-family identifier (AF), followed by the address associated with that AF. +====+=========+===========+ | AF | Address | Length | +====+=========+===========+ | 1 | IPv4 | 4 octets | +----+---------+-----------+ | 2 | IPv6 | 16 octets | +----+---------+-----------+ Table 1: Address-Family Values Liu, et al. Expires 21 March 2027 [Page 6] Internet-Draft PPP Encrypted DNS September 2026 Address List Length counts both the one-octet AF field and the address octets for every entry. For example, an IPv4 entry consumes 5 octets and an IPv6 entry consumes 17 octets. IPv4 and IPv6 entries MAY be mixed in one list. Address-family values other than 1 and 2 are not defined by this document. A receiver MUST treat an entry with an unsupported AF as invalid rather than guessing its length. Address List Length equal to zero MAY be used in a client Configure- Request as a discovery probe. Such a probe MAY contain non-zero SvcParams. A Configure-Ack containing no resolver addresses is NOT RECOMMENDED unless another trusted resolver discovery or bootstrap mechanism is available. 10. SvcParams The SvcParams field reuses the SvcParam wire format defined by RFC 9460 [RFC9460]. This document does not define a new SvcParam encoding or registry. SvcParam keys MUST appear in strictly increasing numerical order. Duplicate keys are invalid. Processing of individual SvcParams, including handling of unknown optional parameters, follows the rules of RFC 9460. The alpn, port, and dohpath parameters, when applicable, use their RFC 9460 definitions. The ALPN identifiers are defined by RFC 7301 [RFC7301], and the DoH path template follows RFC 9461 [RFC9461]. The ipv4hint and ipv6hint parameters MUST NOT be included in a resolver configuration defined by this document, because the resolver IP addresses are explicitly carried in the Address List. SvcParams Length equal to zero means that the SvcParams field contains zero octets. It does not denote a separate encoding of an empty SvcParam set. When SvcParams Length is zero, the local default encrypted DNS transport is DoT. If a resolver configuration contains a required encrypted-DNS transport parameter that an implementation cannot understand or safely apply, that resolver configuration MUST NOT be activated. If a port SvcParam is present, its value MUST NOT be zero. The default ports for the encrypted DNS transports are used only when the corresponding protocol specification defines such a default and the port parameter is absent. Liu, et al. Expires 21 March 2027 [Page 7] Internet-Draft PPP Encrypted DNS September 2026 11. Wire-Format Validation A receiver MUST perform the following validation before activating a resolver configuration: 1. The outer Configuration Option Length is consistent with the number of octets received. 2. All inner length fields remain within the outer option boundary. 3. The ADN satisfies the DNS wire-format requirements in Section 8. 4. The Address List contains complete AF/address entries and uses only AF values defined by this document. 5. SvcParam keys are strictly increasing and contain no duplicates. 6. Any port SvcParam has a non-zero value. 7. The encrypted DNS transport indicated by the configuration is supported by the implementation. 8. TLS identity validation can be performed using the ADN as specified in Section 17. 12. IPCP Negotiation The negotiation follows the Configure-Request, Configure-Ack, Configure-Nak, and Configure-Reject procedures defined by RFC 1661 [RFC1661]. 12.1. Client Configure-Request A client MAY include Option 133 and/or Option 134 in a Configure- Request. To probe for encrypted DNS configuration without supplying a resolver address, the client may use an empty Address List. The client MAY include non-zero SvcParams in such a request to indicate requested transport capabilities or parameters. A client MUST NOT assume that an empty Address List in a Configure- Ack constitutes a usable resolver configuration unless an independent trusted discovery or bootstrap mechanism exists. Liu, et al. Expires 21 March 2027 [Page 8] Internet-Draft PPP Encrypted DNS September 2026 12.2. Server Response For a recognizable option whose value is unacceptable but for which an acceptable replacement can be constructed, the peer may use Configure-Nak as specified by RFC 1661. A Configure-Nak MUST NOT contain a malformed Option 133 or Option 134. If an option is unrecognized or cannot be negotiated, Configure- Reject is used according to RFC 1661. If an option is malformed and no valid replacement can be represented, the implementation follows the general malformed packet processing rules rather than constructing an invalid Configure-Nak. 12.3. Duplicate Options A Configure-Request containing more than one Option 133 instance or more than one Option 134 instance is invalid. An implementation MUST NOT apply a "last received wins" rule to duplicate resolver options. 13. Primary and Secondary Resolver Selection Option 133 identifies the primary resolver and Option 134 identifies the secondary resolver. Both may be negotiated independently. Failover from the primary resolver to the secondary resolver is local client policy. A client MAY try the secondary resolver after connectivity-level failures of the primary resolver, subject to local policy. Such failover does not require IPCP renegotiation. Authentication failure of the primary resolver MUST NOT automatically trigger failover to the secondary resolver merely to bypass authentication failure. A client MAY use the secondary resolver when independently configured or trusted according to local policy. This document defines exactly two encrypted DNS resolver configurations. Negotiation and selection of more than two encrypted DNS resolvers are outside the scope of this document. 14. Coexistence with RFC 1877 When an encrypted DNS resolver configuration is successfully negotiated, the client SHOULD prefer the encrypted DNS service for DNS resolution. If the client cannot establish or use the negotiated encrypted DNS service, the client MAY use plaintext DNS configuration obtained through RFC 1877 [RFC1877], subject to local policy and the requirements of RFC 1877. Liu, et al. Expires 21 March 2027 [Page 9] Internet-Draft PPP Encrypted DNS September 2026 The IPCP Configuration Options defined in this document do not negotiate an operating mode. The presence of an encrypted DNS configuration does not prohibit the use of RFC 1877 plaintext DNS when the encrypted DNS service is unavailable. Failure of the encrypted DNS service does not require IPCP renegotiation. 15. Encrypted DNS Transport Use The protocol identifier and SvcParams determine which encrypted DNS transport is used. Implementations supporting DoT use RFC 7858 [RFC7858]. Implementations supporting DoH use RFC 8484 [RFC8484] together with RFC 9461 [RFC9461] when the DoH path is specified. Implementations supporting DoQ use RFC 9250 [RFC9250]. When SvcParams Length is zero, DoT is the local default. A deployment requiring another transport SHOULD provide the necessary SvcParams explicitly. 16. Transport Mappings This document reuses existing protocol-specific parameter definitions rather than defining new ALPN, path, or port TLVs. * DoT uses the transport defined by RFC 7858 and the corresponding TLS service parameters. * DoH uses RFC 8484 and the dohpath parameter defined by RFC 9461 when a non-default path is required. * DoQ uses RFC 9250 and its applicable ALPN identifier. ALPN values are encoded using the SvcParam representation specified by RFC 9460 and are not encoded as comma-separated strings or as a new IPCP-specific TLV. 17. TLS Authentication The IP addresses in the Address List are network locators. They are not TLS identities. When establishing an encrypted DNS connection, the client MUST validate the server identity using the ADN and the applicable TLS certificate identity rules in RFC 9525 [RFC9525]. An implementation MUST NOT treat possession of an IP address from an IPCP option as sufficient evidence of the resolver's TLS identity. Liu, et al. Expires 21 March 2027 [Page 10] Internet-Draft PPP Encrypted DNS September 2026 If certificate validation against the ADN fails, the corresponding resolver configuration MUST NOT be treated as an authenticated encrypted DNS resolver. 18. Security Considerations The IPCP Configuration Options defined in this document provide encrypted DNS resolver configuration. Receipt of an IPCP option does not by itself authenticate the DNS service or prove that the option was supplied by a trusted network operator. When establishing an encrypted DNS connection, the client MUST authenticate the resolver according to the applicable encrypted DNS transport specification. In particular, the Address List identifies network locations and the ADN identifies the DNS service for purposes of TLS server identity validation. An IP address received in an IPCP option MUST NOT be treated as sufficient evidence of the resolver's identity. The IPCP options defined by this document do not provide cryptographic protection for the configuration itself. Deployments that require protection of PPP control traffic should use an appropriate PPP security mechanism when available. When the encrypted DNS service cannot be established or used, the behavior defined in this document permits the client to use plaintext DNS configuration obtained through RFC 1877 [RFC1877]. Such fallback does not provide the confidentiality and integrity properties of encrypted DNS. PPP does not require applications to use the resolver configuration negotiated by this protocol. Implementations may apply local resolver-selection policy, provided that such policy is consistent with the requirements of this document. 19. IANA Considerations IANA is requested to assign the following values from the "PPP IPCP Configuration Option Types" registry: * 133 — Primary Encrypted DNS Server. * 134 — Secondary Encrypted DNS Server. The allocation is subject to the policy defined by RFC 3818 [RFC3818]. Liu, et al. Expires 21 March 2027 [Page 11] Internet-Draft PPP Encrypted DNS September 2026 This document does not create a new SvcParam registry or a new address-family registry. The AF values 1 and 2 used in this document are local field values corresponding to IPv4 and IPv6. Additional AF values would require a revision of this document. 20. Examples 20.1. Basic DoT Configuration Client: Configure-Request Option 133: Address List Length: 0 SvcParams Length: 0 Server: Configure-Nak Option 133: ADN: dot.example.com. Address List: AF=1, Address=192.0.2.53 SvcParams Length: 0 Client: Configure-Request Option 133: ADN: dot.example.com. Address List: AF=1, Address=192.0.2.53 SvcParams Length: 0 Server: Configure-Ack Option 133: ADN: dot.example.com. Address List: AF=1, Address=192.0.2.53 SvcParams Length: 0 Figure 2: Basic DoT Negotiation 20.2. DoH with Custom Path Liu, et al. Expires 21 March 2027 [Page 12] Internet-Draft PPP Encrypted DNS September 2026 Client: Configure-Request Option 133: Address List Length: 0 SvcParams: dohpath=/dns-query Server: Configure-Nak Option 133: ADN: doh.example.com. Address List: AF=2, Address=2001:db8::53 SvcParams: alpn=h2 dohpath=/dns-query Client: Configure-Request Option 133: ADN: doh.example.com. Address List: AF=2, Address=2001:db8::53 SvcParams: alpn=h2 dohpath=/dns-query Server: Configure-Ack Option 133: ADN: doh.example.com. Address List: AF=2, Address=2001:db8::53 SvcParams: alpn=h2 dohpath=/dns-query Figure 3: DoH Negotiation with SvcParams 20.3. Dual-Stack Resolver Address List Option 133: ADN: dns.example.com. Address List: AF=1, Address=192.0.2.53 AF=2, Address=2001:db8::53 SvcParams Length: 0 Figure 4: Mixed IPv4 and IPv6 Addresses Liu, et al. Expires 21 March 2027 [Page 13] Internet-Draft PPP Encrypted DNS September 2026 21. Implementation Considerations Implementations should validate all nested lengths before attempting to parse an ADN, Address List, or SvcParams field. In particular, an implementation should not use an inner length to read beyond the enclosing PPP Configuration Option. Implementations should preserve the distinction between a missing SvcParams field, a zero-length SvcParams field, and an SvcParams field containing encoded parameters. Under the format defined here, a zero-length SvcParams field selects the local DoT default. Implementations should reject duplicate SvcParam keys and should not silently reinterpret an unsupported address-family value. Implementations should keep resolver selection and failover decisions separate from IPCP option parsing. In particular, authentication failure should not be converted into an automatic secondary-resolver bypass. 22. Future Work This document intentionally limits encrypted DNS negotiation to two complete resolver configurations and one-octet inner length fields. Future work could define a new option format if larger configurations or more than two resolver configurations are required. 23. Normative References [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", RFC 3818, June 2004, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, July 2014, . Liu, et al. Expires 21 March 2027 [Page 14] Internet-Draft PPP Encrypted DNS September 2026 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over TLS", RFC 7858, May 2016, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS", RFC 8484, October 2018, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC", RFC 9250, May 2022, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding Mapping", RFC 9460, November 2023, . [RFC9461] Schwartz, B., "Service Binding Mapping for HTTP", RFC 9461, November 2023, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, December 2024, . 24. Informative References [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987, . [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987, . Acknowledgments The authors would like to thank Dan Wing from Cisco for useful input. This work is supported by the National Key Research and Development Program of China (No. 2022YFB3103000). Liu, et al. Expires 21 March 2027 [Page 15] Internet-Draft PPP Encrypted DNS September 2026 Authors' Addresses Dongjie Liu Jinan University Email: dongjieliu8917@gmail.com Zhiwei Yan CNNIC Email: yanzhiwei@cnnic.cn Guanggang Geng Jinan University Email: guanggang.geng@gmail.com Liu, et al. Expires 21 March 2027 [Page 16]