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.¶
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 (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.¶
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.¶
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.¶
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.¶
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.¶
Type: One of the two IANA-assigned IPCP Configuration Option Types.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
If certificate validation against the ADN fails, the corresponding
resolver configuration MUST NOT be treated as an
authenticated encrypted DNS resolver.¶
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.¶
The allocation is subject to the policy defined by RFC 3818
[RFC3818].¶
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.¶
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.¶
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.¶
Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, , <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC7858]
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over TLS", RFC 7858, , <https://www.rfc-editor.org/rfc/rfc7858>.
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).¶