]> Independent

djvanc@outlook.com

This document specifies SOCKS Protocol Version 4A, an independent protocol originated from the SOCKS Protocol Version 4. This protocol 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 only behaviors that SOCKS 4A is different from the original SOCKSv4 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 Independent This document describes SOCKS version 4, a protocol designed to facilitate TCP proxy services across a network firewall. SOCKS operates at the session layer, providing application users with transparent access to network services on the other side of the firewall. It is application-protocol independent, allowing it to support a wide range of services, including those utilizing encryption, while maintaining minimum processing overhead by simply relaying data after initial access control checks. The protocol defines two primary operations: CONNECT for establishing outbound connections to an application server, and BIND for preparing for and accepting inbound connections initiated by an application server. 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. This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK] This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK] Internet Architecture Board This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. This memo provides information for the Internet community. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.

Operational Considerations The following section outlines the operational behaviors and implementation strategies observed in historical deployments of SOCKS 4A. These notes are provided to ensure interoperability and to document how the protocol handles complex network topologies.

Multi-tier Proxying and Chaining In hierarchical network architectures, an intermediate SOCKS server often acts as a client to an upstream SOCKS server. This configuration, known as proxy chaining, requires specific handling of SOCKS 4A requests to maintain the integrity of the resolution delegation.

Recursive Resolution and Protocol Downgrade An intermediate proxy receiving a SOCKS 4A request MAY perform local resolution of the DOMAIN field. If the resolution is successful, the intermediate proxy may elect to "downgrade" the request to a standard SOCKSv4 CONNECT or BIND operation when communicating with the upstream server, using the literal IPv4 address obtained from its local resolver. While this approach reduces the resolution burden on the upstream server, it requires that the intermediate proxy possesses a DNS environment consistent with the client's expectations. Implementations should be aware that resolving a domain at an intermediate hop may yield different IP addresses (e.g., in Content Delivery Networks) than resolution at the network edge.

Transparent Relaying In environments where the intermediate proxy is situated behind a restrictive firewall without direct DNS access, it SHOULD implement transparent relaying. In this mode, the intermediate proxy preserves the SOCKS 4A signaling (the 0.0.0.x DSTIP pattern) and appends the USERID and DOMAIN fields exactly as received from the client when initiating the upstream connection. This ensures that the resolution intent is signaled end-to-end until it reaches a node capable of performing the lookup.

Implementation Robustness and Interoperability In accordance with the general robustness principle—to be conservative in what you send and liberal in what you accept—SOCKS 4A implementations have historically adopted permissive processing logic to accommodate diverse and sometimes non-compliant client behaviors.

Handling of Pre-resolved Requests Certain "SOCKSified" libraries or shim layers may resolve the destination hostname locally via the system's standard resolver before initiating the SOCKS handshake. Despite possessing a valid IP address, these clients may still utilize the SOCKS 4A format, placing the original hostname in the DOMAIN field. To ensure maximum interoperability, a SOCKS 4A-compliant server MUST NOT attempt to validate whether a 4A request was strictly necessary. Any request that matches the 0.0.0.x pattern MUST be processed according to the SOCKS 4A logic described in Section 4, even if the server suspects the client is capable of direct IPv4 addressing.

Buffer Management and Premature Termination Historical implementations have occasionally encountered "leaky" or malformed packets where the NULL terminators for the USERID or DOMAIN fields are missing or followed by extraneous data. A robust implementation SHOULD treat the first NULL octet encountered as the definitive end of the field. Furthermore, if the stream terminates before the second NULL octet (the DOMAIN terminator) is received, the server MUST treat the request as failed and send a rejection reply (Result Code 91). This prevents the server from hanging in a "half-read" state, which could be exploited as a resource exhaustion vector (see ).

Character Set Consistency While this document recommends US-ASCII or Punycode (), historical deployments have occasionally seen DOMAIN strings containing raw UTF-8 or local codepage octets. Servers SHOULD treat the DOMAIN string as an opaque sequence of octets when passing it to the local resolver. If the local resolver returns an error due to illegal characters, the server MUST return a failure code to the client rather than attempting to "guess" the intended encoding, which can lead to security vulnerabilities through domain name spoofing.

Security Analysis The SOCKS 4A protocol is a lightweight shim designed to facilitate TCP proxying with remote name resolution. It operates primarily at the session layer and lacks the cryptographic primitives found in more modern protocols like TLS . This appendix provides a detailed analysis of the security implications of the protocol, assuming a threat model where an attacker can observe, intercept, and modify traffic between the client, the SOCKS server, and the DNS infrastructure.

Security Deficiencies of the Base Protocol As an extension of SOCKSv4, SOCKS 4A inherits significant structural vulnerabilities. The protocol provides no mechanisms for mutual authentication, integrity protection, or confidentiality. Consequently, it is inherently susceptible to active man-in-the-middle (MITM) attacks. An attacker positioned between the client and the SOCKS server can silently alter the DSTPORT or DOMAIN fields, effectively redirecting the application traffic to a malicious destination without either party's knowledge. The USERID field, while intended for identity assertion, provides no cryptographic proof of origin. In the absence of a strong authentication framework as recommended in , this field must be treated as untrusted and unauthenticated information. Relying on USERID for access control decisions is a violation of the principle of least privilege and is highly discouraged.

Remote Name Resolution and Information Leakage One of the primary motivations for SOCKS 4A is the mitigation of "DNS leakage" on the client's local network. By delegating resolution to the SOCKS server, the client avoids issuing plaintext DNS queries that would otherwise expose the destination hostname to local observers . However, this delegation does not eliminate the risk but rather relocates it to the SOCKS server's network environment. Unless the SOCKS server employs encrypted DNS transports such as DNS over TLS or DNS over HTTPS , the resolution process remains transparent to upstream passive monitors. Furthermore, if the client and SOCKS server communicate over an untrusted wide-area network (WAN) without a secure tunnel (e.g., or ), the DOMAIN string itself is transmitted in the clear, negating any privacy benefits intended by the use of remote resolution.

Server-Side Request Forgery Risks SOCKS 4A servers act as confused deputies by performing network operations on behalf of potentially anonymous clients. This mechanism introduces a significant risk of Server-Side Request Forgery (SSRF). A malicious client may leverage the SOCKS server to probe or attack internal infrastructure that is otherwise shielded from the public internet. To mitigate this, implementations MUST adhere to the guidance in regarding network ingress filtering. Servers should be configured with strict egress Access Control Lists (ACLs) to prevent connections to loopback addresses (127.0.0.0/8), private address space , and link-local addresses . Failure to implement these controls allows an attacker to use the SOCKS server as a scanning proxy to enumerate internal services or exploit vulnerabilities in non-hardened internal applications.

Robustness and Resource Exhaustion The variable-length nature of the USERID and DOMAIN fields introduces vectors for Denial of Service (DoS) attacks. Unlike protocols with explicit length-prefixing, SOCKS 4A relies on NULL terminators. An implementation that performs unbounded reads while searching for a NULL octet is vulnerable to memory exhaustion attacks. In accordance with , implementations MUST enforce hard limits on the size of the input buffers used for these fields. For the DOMAIN field, a limit of 255 octets is recommended to align with the maximum length of a Fully Qualified Domain Name (FQDN) as specified in . Furthermore, servers MUST implement per-session timeouts for the resolution phase to prevent "tarpitting" attacks, where a client initiates a large number of requests that target slow or non-responsive DNS authoritative servers, thereby exhausting the server's thread pool or file descriptors.

Protocol Rollback and Downgrade Attacks While SOCKS 4A was designed to improve upon SOCKSv4, it remains a subset of the capabilities provided by SOCKSv5 . SOCKSv5 offers robust authentication methods and support for UDP. However, because SOCKS 4A does not participate in a formal version negotiation (it merely uses a different version octet), it is susceptible to downgrade attacks. An attacker may modify the version octet of a SOCKSv5 request to force the use of SOCKS 4A, thereby stripping away any authentication or encryption requirements mandated by the higher-version configuration.

Interaction with Internationalized Domain Names The use of the DOMAIN field requires careful handling of Internationalized Domain Names (IDNs). As noted in , the interpretation of non-ASCII characters can lead to ambiguity and "homograph" attacks, where a visually similar but different domain is resolved. For maximum security and interoperability, clients SHOULD convert IDNs to A-label format (Punycode) as defined in before transmission. Servers SHOULD treat the DOMAIN string as an opaque sequence of octets to be passed to the resolver, while ensuring that the resulting IP address undergoes the filtering described in .

Final Security Note SOCKS 4A is an aged protocol and lacks modern security features. It should only be used in environments where the communication channel is otherwise secured by a lower-layer technology (such as IPsec) or where the risk of interception and spoofing is deemed acceptable. For all other use cases, the transition to SOCKSv5 combined with TLS is strongly recommended to ensure the confidentiality and integrity of the session.

Example Implementations The following software projects provide full or partial implementations of the SOCKS4A protocol. The author consulted these implementations as practical references during the drafting of this document. It is explicitly stated that the author and this draft are entirely unaffiliated with these projects.

• Dante: A sophisticated SOCKS server implementation for Unix-based systems. It handles SOCKS4A requests within its broader SOCKS4 module, utilizing the specific "null-domain" IP address format to trigger remote DNS resolution.
• GOST (Go Simple Tunnel): A multi-protocol tunnel manager written in Go. It includes a native SOCKS4A handler that supports both the protocol's command set and its specific address representation.
• 3proxy: A lightweight, multi-platform proxy server. It implements SOCKS4A as part of its compact SOCKS service, supporting the extension for environments where client-side DNS resolution is restricted.

Relationship with SOCKS 4 See Appendix A of for the reason why SOCKS 4A was not an extension of SOCKS Version 4.

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.

Contributors