Jinan University

dongjieliu8917@gmail.com

CNNIC

yanzhiwei@cnnic.cn

Guangzhou University

cryptjweng@gmail.com

Jinan University

guanggang.geng@gmail.com

Jinan University

csyyzhang@gmail.com

Internet ADD Working Group This document defines extensions to the Point-to-Point Protocol (PPP) Internet Protocol Control Protocol (IPCP) for negotiating encrypted DNS resolver configurations. These extensions allow PPP peers to exchange information about encrypted DNS servers supporting protocols such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ). The design maintains backward compatibility with RFC 1877 while addressing modern security requirements.

The Point-to-Point Protocol (PPP) and its Ethernet adaptation, PPPoE () remain foundational technologies for authenticated network access, particularly in broadband and enterprise environments. PPP is widely used in scenarios such as: ISP broadband access (e.g., PPPoE for DSL/fiber authentication) Industrial control networks (serial PPP for SCADA/PLC communications) Cellular backhaul (PPP over GTP in 4G/5G user-plane data) Secure tunneling (PPP inside L2TP/IPsec or MPLS VPNs) Despite the rise of DHCP and IPv6 RA for configuration, PPP persists due to its fine-grained access control, negotiation flexibility, and compatibility with legacy systems. However, traditional PPP IPCP extensions () only support plaintext DNS, exposing queries to surveillance and manipulation — a critical gap in an era where encrypted DNS (DoT , DoH , DoQ ) is essential for privacy and security. This document extends PPP IPCP to negotiate encrypted DNS resolvers, enabling: Secure DNS by default: Clients automatically adopt encrypted transports (e.g., DoT on port 853) without manual configuration. Operator-managed trust: ISPs can provide authenticated DNS resolvers (via ADNs and certificate fingerprints) to enable secure DNS by default. Clients retain the flexibility to use other resolvers if configured accordingly. Backward compatibility: Coexists with RFC 1877 options, allowing fallback to plaintext DNS if needed. By integrating encrypted DNS negotiation into PPP, this specification bridges the gap between legacy access protocols and modern security requirements, ensuring confidentiality and integrity for DNS queries across diverse deployment scenarios — from home broadband to critical infrastructure.

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 .

This document defines three new IPCP Configuration Options: Type Name Description 133Primary Encrypted DNSPrimary encrypted DNS server 134Secondary Encrypted DNSSecondary encrypted DNS server 135DNS Encryption ParametersAdditional encryption parameters

This option provides the primary encrypted DNS resolver configuration.

Fields: Type: 133 Length: ≥ 6 Protocol: 1=DoT, 2=DoH, 3=DoQ Reserved: MUST be 0 ADN Length: Length of ADN field ADN: Resolver FQDN (RFC 1035 format) Port Number: Defaults to 853 (DoT/DoQ) or 443 (DoH) if 0

This option provides a fallback encrypted DNS resolver configuration when the primary server is unavailable. It follows the same structure as the Primary Encrypted DNS Server Option (Section 2.1) but uses a distinct type code. Type: 134

This option provides supplemental configuration parameters required for specific encrypted DNS protocols. It enables negotiation of advanced settings that cannot be conveyed in the primary/secondary options alone.

Fields: Type: 135 Length: ≥ 5 Server Selector (1 octet): 0x00 – Parameters apply to the Primary Encrypted DNS Server (Option 133) 0x01 – Parameters apply to the Secondary Encrypted DNS Server (Option 134) Other values are reserved for future use Param Type (1 octet): 0x01 – ALPN Protocols 0x02 – DoH Path Template 0x03–0xFF – Reserved Param Length: Length of Parameter Value Parameter Value: Protocol-specific data Defined Parameters: ALPN Protocols (Type 0x01) – Value: comma-separated list of ALPN identifiers as defined in [RFC7301]. Example: “dot,h2” for DoT and HTTP/2. DoH Path Template (Type 0x02) – Value: URI path for DoH requests (UTF-8). Example: “/dns-query”. When multiple Option 135 instances are received for the same server (specified by the Server Selector) with the same Param Type, the client MUST use the parameter value from the last received Option 135 in the IPCP negotiation. This follows the standard negotiation behavior of IPCP (RFC 1332), ensuring determinism. Parameter options are processed independently per server. If a client receives an unrecognized Param Type or an invalid value, it SHOULD ignore that specific option and continue processing other valid options.

This section specifies the state machine and processing rules for encrypted DNS option negotiation. The procedure follows standard IPCP negotiation defined in , with additional validation specific to encrypted DNS parameters.

1. The client MAY include Option 133 and/or 134 in Configure-Request 2. To request configuration: Set ADN Length = 0 Set Port Number = 0 Omit ADN field 3. The client MAY include Option 135 to request specific parameters

1. If server supports encrypted DNS: For valid requests: Respond with Configure-Ack For invalid/empty requests: Respond with Configure-Nak containing valid configuration 2. If server doesn't support encrypted DNS: Respond with Configure-Reject If the client includes a DNS Encryption Parameters Option (Option 135) in a Configure-Request, the server responds in one of the following ways: If the server supports all of the requested parameters, it MUST include them unchanged in a Configure-Ack. If the server supports a subset of the requested parameters, or supports alternative values for them, it SHOULD respond with a Configure-Nak containing a valid DNS Encryption Parameters Option with the parameters (and values) it is willing to support. If the server does not support encrypted DNS negotiation at all, or does not recognize Option 135, it SHOULD respond with a Configure-Reject for this option.

When both Options 129 (RFC 1877) and 133 or 134 are present: Clients SHOULD prefer encrypted DNS (Option 133/134) Clients MAY fall back to plaintext DNS if encrypted connection fails

Clients MUST validate the server's TLS certificate against the provided ADN Clients SHOULD perform standard TLS certificate validation by checking that the server's certificate is valid, chains to a trusted root, and matches the provided Authentication Domain Name (ADN)

While the options themselves may be transmitted in cleartext, they enable encrypted DNS transport Implementations SHOULD use PPP encryption (e.g., MPPE) when available

Active attackers may remove encrypted DNS options from IPCP negotiation Clients SHOULD maintain a history of successful encrypted DNS usage and warn when unexpectedly unavailable

The DNS resolver addresses negotiated via PPP IPCP are intended as configuration suggestions. Implementations MAY allow users to manually override these settings or fall back to other resolvers, as PPP itself does not enforce DNS usage. This flexibility ensures that end-user choice is not restricted by network-provided configuration.

This document has no IANA actions.

This work is supported by the National Key Research and Development Program of China (No. 2022YFB3103000). The authors would like to thank Dan Wing from Cisco for his useful input.

IETF IETF IETF IETF IETF IETF IETF IETF IETF IETF IETF

This document focuses on PPP IPCP. Future work may explore analogous extensions for other configuration protocols, such as IPv6 Router Advertisements (RAs) or DHCP, to enable encrypted DNS negotiation in those contexts.