]> Independent

djvanc@outlook.com

This document specifies SOCKS 4A, an extension to the SOCKS Version 4 protocol. This extension allows SOCKS clients to delegate domain name resolution to the SOCKS server. This is particularly useful in environments where the client host cannot resolve the destination host's domain name due to restrictive network policies or lack of DNS access. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction The original SOCKSv4 protocol requires the client to provide the destination host's IPv4 address. However, in many firewall configurations, the client resides on a network without direct DNS access to the outside world. SOCKS 4A addresses this by allowing the client to provide a domain name string instead of a resolved IP address.

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 when, and only when, they appear in all capitals, as shown here. This specification uses the following terms:

• Client (Application Client): The program requesting a connection to an application server through the SOCKS server.
• SOCKS Server: The host, typically at a firewall, that intermediates the connection between the Client and the Application Server.
• Application Server: The host to which the Client ultimately wishes to connect (e.g., a Telnet daemon, an HTTP server).
• TCP Session: A connection established using the Transmission Control Protocol (TCP). SOCKSv4 only supports TCP sessions.
• DSTIP (Destination IP): The IP address of the Application Server, as specified in the SOCKS request.
• DSTPORT (Destination Port): The port number of the Application Server, as specified in the SOCKS request.
• USERID: A variable-length, NULL-terminated string identifying the client's user on the local system.
• NULL: A byte of all zero bits, used to terminate the USERID field.

Protocol Mechanism The SOCKS 4A extension is triggered by a specific, non-routable pattern in the DSTIP field of a standard SOCKSv4 request.

Request Format To initiate a SOCKS 4A request (either CONNECT or BIND), the client sends a packet with the following structure: SOCKS 4A Request Structure

Field	Description	Size (bytes)	Value/Notes
VN	Version Number	1	0x04
CD	Command Code	1	0x01 (CONNECT) or 0x02 (BIND)
DSTPORT	Destination Port	2	Network Byte Order
DSTIP	Destination IP	4	0x00, 0x00, 0x00, x (x != 0)
USERID	User Identifier	variable	Variable length, NULL terminated
DOMAIN	Destination Domain	variable	Variable length, NULL terminated

DSTIP Encoding and Signaling To signal a SOCKS 4A extension request, the client MUST set the first three octets of the DSTIP field to 0x00 and the final octet to a non-zero value in network byte order (i.e., representing an IPv4 address in the range 0.0.0.1 through 0.0.0.255). This specific address range, part of the 0.0.0.0/8 block, is reserved by IANA for "this host on this network" and is not a routable destination. This ensures that the 4A signal is syntactically distinct from standard SOCKSv4 requests. A SOCKS server receiving such a DSTIP MUST ignore its numerical value and proceed to extract the destination address from the DOMAIN field as defined in .

Destination Domain Name Field The DOMAIN field contains the fully qualified domain name (FQDN) of the application server. To ensure protocol stability and prevent common parsing errors, the following rules MUST be observed:

• Positioning: The DOMAIN field MUST begin immediately after the NULL (0x00) terminator of the USERID field.
• Encoding: The domain name SHOULD be encoded in US-ASCII. While some implementations support Internationalized Domain Names (IDNs), clients SHOULD use the Punycode-encoded A-label format to ensure maximum compatibility.
• Termination: The field MUST be terminated by a single NULL (0x00) octet.
• Length Constraints: The DOMAIN string (excluding the terminator) SHOULD NOT exceed 255 octets, consistent with the maximum length of a FQDN defined in . Servers SHOULD enforce a maximum buffer limit for this field to mitigate resource exhaustion attacks.

Server Processing Upon receipt of a client request, a SOCKS 4A compliant server MUST process the data according to the following sequential states:

Initial Header Parsing The server MUST first read the fixed-length 8-octet header. It SHALL evaluate the fields as follows:

• VN: If the version number is not 4, the server SHOULD terminate the connection.
• CD: The server determines the requested operation (CONNECT or BIND).
• DSTPORT: The destination port is extracted for later use in the connection attempt.
• DSTIP: The server inspects the four-octet destination IP address to determine the routing mode (Standard SOCKSv4 or SOCKS 4A).

Routing Mode Selection and Field Extraction The server MUST apply the following logic based on the DSTIP value:

1. SOCKS 4A Signaling: If the first three octets of DSTIP are zero and the fourth octet is non-zero (0.0.0.x, where x != 0), the server SHALL enter the SOCKS 4A extended resolution mode. The server MUST continue to read the input stream to extract the USERID string, defined as all octets up to and including the first NULL (0x00) terminator. Immediately following the USERID terminator, the server MUST continue reading to extract the DOMAIN string, defined as all octets up to and including the second NULL (0x00) terminator.
2. Standard SOCKSv4 Handling: If the DSTIP does not match the 0.0.0.x pattern (including the case of 0.0.0.0), the server MUST follow the standard SOCKSv4 procedure, extracting only the USERID field. In this mode, the server MUST NOT attempt to read or interpret any data following the first NULL terminator as a domain name.

Name Resolution and Execution In SOCKS 4A mode, once the DOMAIN string is extracted:

• Resolution: The server SHALL attempt to resolve the ASCII-encoded domain name to a valid IPv4 address using the server's local DNS resolver or host lookup mechanism.
• Successful Resolution: If the domain resolves to one or more IPv4 addresses, the server SHOULD attempt to establish the requested TCP session (for CONNECT) or bind a socket (for BIND) using the first resolvable and reachable address.
• Resolution Failure: If the domain cannot be resolved, or if the resolver returns an error, the server MUST consider the request failed. It SHALL return a reply packet with CD = 91 and MUST immediately close the connection to the client.

Response Generation Following the completion (success or failure) of the request processing, the server MUST return an 8-octet reply packet. For SOCKS 4A CONNECT operations, the DSTPORT and DSTIP fields in the reply are typically set to zero and SHOULD be ignored by the client. For BIND operations, these fields MUST contain the specific port and IP address where the SOCKS server is listening for the inbound connection. SOCKS 4A Reply Structure

Field	Description	Size (bytes)	Value/Notes
VN	Reply Version	1	0x00 (Null byte)
CD	Result Code	1	0x5A (Granted), 0x5B (Rejected/Failed), etc.
DSTPORT	Destination Port	2	Ignored for CONNECT; provided for BIND
DSTIP	Destination IP	4	Ignored for CONNECT; provided for BIND

Security Considerations See .

IANA Considerations No IANA actions required.

References Normative References NEC Systems Laboratory, CSTC n.d. Netskope NEC Systems Laboratory, CSTC n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK] The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK] All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK] This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.

Operational Considerations and Implementation Notes The following behaviors were observed in historical deployments of SOCKS 4A to address specific network constraints and interoperability challenges.

Proxy Chaining and Relaying In multi-tiered network environments, a SOCKS server (the "intermediate proxy") may itself be configured to use another SOCKS server (the "upstream proxy") for outbound connectivity. When an intermediate proxy receives a SOCKS 4A request:

• Recursive Resolution: The intermediate proxy may attempt to resolve the DOMAIN locally. If successful, it may then downgrade the request to a standard SOCKSv4 CONNECT/BIND using the resolved IPv4 address when communicating with the upstream proxy.
• Transparent Relaying: If the intermediate proxy lacks DNS access or is configured for "blind" relaying, it passes the SOCKS 4A request—including the 0.0.0.x DSTIP signaling and the DOMAIN field—intact to the upstream proxy. This delegates the resolution responsibility to the edge of the network.

This mechanism was frequently employed in "firewall-behind-firewall" scenarios where only the outermost gateway possessed external name resolution capabilities.

Client-Side Resolution "Leakage" and Server Robustness While the SOCKS 4A extension was primarily designed for clients unable to perform local DNS lookups, many "SOCKSified" application libraries (such as those using LD_PRELOAD or global proxy settings) exhibited "leaky" behavior.

• Pre-resolution: A client might resolve a domain name locally but still initiate a SOCKS 4A request using that domain name rather than the resolved IP address.
• Server Interoperability: To ensure maximum compatibility with various client stacks, historical SOCKS 4A server implementations typically did not validate whether the client needed to use 4A. A server would process any request matching the 0.0.0.x DSTIP pattern as a 4A request, regardless of the client's network location or supposed capabilities.

This permissive approach was essential for maintaining a uniform interface across diverse application environments, though it occasionally resulted in redundant DNS queries if both the client and the server performed the same resolution.

Security Analysis This section provides an analysis of the security implications introduced by the SOCKS 4A extension. As an extension to SOCKSv4, it inherits the fundamental insecurities of the base protocol while introducing new vectors related to remote name resolution.

DNS Privacy and information Leakage SOCKS 4A functions as a countermeasure against DNS leakage at the client-side network layer. In the base SOCKSv4 protocol, the Requirement for the client to provide a literal IPv4 address necessitates a local DNS lookup. This transaction is typically unencrypted and occurs outside the proxy tunnel, exposing the destination hostname to local network observers and the DNS recursive resolver. By delegating resolution to the SOCKS server, the client encapsulates the intent (the DOMAIN string) within the TCP session established to the SOCKS server. However, this merely shifts the point of leakage; the SOCKS server’s own DNS queries may still be observable unless the server implements encrypted DNS transport (e.g., DNS over TLS).

Server-Side Request Forgery The SOCKS 4A resolution mechanism enables a primitive form of Server-Side Request Forgery. Because the server performs resolution and subsequent connection on behalf of the client, a malicious client may use the SOCKS server to:

• Probe Internal Infrastructure: Access or scan hostnames and IP addresses that are non-routable or firewalled from the public internet but reachable from the SOCKS server’s internal interface.
• Resolve Split-Horizon DNS: Enumerate internal DNS records that are only visible to the SOCKS server's configured resolvers.

Implementations SHOULD employ strict egress filtering and Access Control Lists (ACLs) to prevent the SOCKS server from connecting to loopback addresses (127.0.0.0/8), private address space (RFC 1918), or link-local addresses.

Denial of Service and Resource Exhaustion The variable-length nature of the SOCKS 4A request introduces two primary vectors for resource exhaustion:

1. Memory Exhaustion: A SOCKS 4A request involves two variable-length NULL-terminated strings (USERID and DOMAIN). An implementation that fails to enforce strict bounds on these fields during the "read-until-NULL" phase is vulnerable to heap exhaustion. Servers MUST enforce a maximum buffer limit (RECOMMENDED 255 octets for DOMAIN) and terminate connections that exceed this limit without a NULL terminator.
2. Resolver Tarpitting: DNS resolution is an asynchronous, I/O-bound operation. A client may initiate numerous concurrent 4A requests targeting non-responsive or slow DNS authoritative servers. This can exhaust the server's thread pool or file descriptors. Servers MUST implement a per-request resolution timeout.

Lack of Cryptographic Integrity and Authentication SOCKS 4A, like its predecessor, provides no facility for session encryption, message integrity, or robust authentication.

• Identity Spoofing: The USERID field is provided by the client without any cryptographic proof of identity. It is trivial to spoof and SHOULD NOT be relied upon for security-critical authorization.
• Active Interception: The entire handshake, including the DOMAIN string, is transmitted in plaintext. An attacker in the path between the client and the SOCKS server can perform a Man-in-the-Middle (MITM) attack, observing the destination domain or modifying the server's reply to redirect the client.

Implementations requiring confidentiality or integrity MUST wrap the SOCKS 4A transaction in a secure transport layer, such as TLS or an SSH tunnel.

Original Author We sincerely apologize that, due to the document's long history and the passage of time, many early contributors may not have been formally included in this list. We extend our deepest gratitude to all who have contributed to this work. If you believe your name should be added to the acknowledgments, please contact the draft maintainers.