



Network Working Group                                        D. J. Vance
Internet-Draft                                               Independent
Intended status: Historic                                     4 May 2026
Expires: 5 November 2026


                       SOCKS Protocol Version 4A
                        draft-vance-socks-v4a-02

Abstract

   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

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/4socks/socks4.

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 5 November 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Vance                    Expires 5 November 2026                [Page 1]

Internet-Draft                  SOCKS 4A                        May 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Protocol Mechanism  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Request Format  . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  DSTIP Encoding and Signaling  . . . . . . . . . . . .   4
       3.1.2.  Destination Domain Name Field . . . . . . . . . . . .   4
   4.  Server Processing . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Initial Header Parsing  . . . . . . . . . . . . . . . . .   5
     4.2.  Routing Mode Selection and Field Extraction . . . . . . .   5
     4.3.  Name Resolution and Execution . . . . . . . . . . . . . .   6
     4.4.  Response Generation . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Operational Considerations . . . . . . . . . . . . .  10
     A.1.  Multi-tier Proxying and Chaining  . . . . . . . . . . . .  10
       A.1.1.  Recursive Resolution and Protocol Downgrade . . . . .  10
       A.1.2.  Transparent Relaying  . . . . . . . . . . . . . . . .  10
     A.2.  Implementation Robustness and Interoperability  . . . . .  10
       A.2.1.  Handling of Pre-resolved Requests . . . . . . . . . .  11
       A.2.2.  Buffer Management and Premature Termination . . . . .  11
       A.2.3.  Character Set Consistency . . . . . . . . . . . . . .  11
   Appendix B.  Security Analysis  . . . . . . . . . . . . . . . . .  11
     B.1.  Security Deficiencies of the Base Protocol  . . . . . . .  12
     B.2.  Remote Name Resolution and Information Leakage  . . . . .  12
     B.3.  Server-Side Request Forgery Risks . . . . . . . . . . . .  12
     B.4.  Robustness and Resource Exhaustion  . . . . . . . . . . .  13
     B.5.  Protocol Rollback and Downgrade Attacks . . . . . . . . .  13
     B.6.  Interaction with Internationalized Domain Names . . . . .  13
     B.7.  Final Security Note . . . . . . . . . . . . . . . . . . .  14
   Appendix C.  Example Implementations  . . . . . . . . . . . . . .  14
   Appendix D.  Relationship with SOCKS 4  . . . . . . . . . . . . .  14
   Original Author . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15






Vance                    Expires 5 November 2026                [Page 2]

Internet-Draft                  SOCKS 4A                        May 2026


1.  Introduction

   The original SOCKSv4 protocol ([I-D.vance-socks-v4]) 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.

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] 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.

3.  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.



Vance                    Expires 5 November 2026                [Page 3]

Internet-Draft                  SOCKS 4A                        May 2026


3.1.  Request Format

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

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

                   Table 1: SOCKS 4A Request Structure

3.1.1.  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" [RFC1122] 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 Section 3.1.2.

3.1.2.  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:



Vance                    Expires 5 November 2026                [Page 4]

Internet-Draft                  SOCKS 4A                        May 2026


   *  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
      [RFC5891] 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 [RFC1035].  Servers SHOULD enforce a maximum
      buffer limit for this field to mitigate resource exhaustion
      attacks.

4.  Server Processing

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

4.1.  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).

4.2.  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



Vance                    Expires 5 November 2026                [Page 5]

Internet-Draft                  SOCKS 4A                        May 2026


       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.

4.3.  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.

4.4.  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.












Vance                    Expires 5 November 2026                [Page 6]

Internet-Draft                  SOCKS 4A                        May 2026


   +=========+===============+==============+=========================+
   | 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   | 2            | Ignored for CONNECT;    |
   |         | Port          |              | provided for BIND       |
   +---------+---------------+--------------+-------------------------+
   | DSTIP   | Destination   | 4            | Ignored for CONNECT;    |
   |         | IP            |              | provided for BIND       |
   +---------+---------------+--------------+-------------------------+

                    Table 2: SOCKS 4A Reply Structure

5.  Security Considerations

   See Appendix B.

6.  IANA Considerations

   No IANA actions required.

7.  References

7.1.  Normative References

   [I-D.vance-socks-v4]
              Vance, D. J., "SOCKS Protocol Version 4", Work in
              Progress, Internet-Draft, draft-vance-socks-v4-09, 4 May
              2026, <https://datatracker.ietf.org/doc/html/draft-vance-
              socks-v4-09>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References






Vance                    Expires 5 November 2026                [Page 7]

Internet-Draft                  SOCKS 4A                        May 2026


   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/rfc/rfc1122>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.

   [RFC1928]  Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
              L. Jones, "SOCKS Protocol Version 5", RFC 1928,
              DOI 10.17487/RFC1928, March 1996,
              <https://www.rfc-editor.org/rfc/rfc1928>.

   [RFC1929]  Leech, M., "Username/Password Authentication for SOCKS
              V5", RFC 1929, DOI 10.17487/RFC1929, March 1996,
              <https://www.rfc-editor.org/rfc/rfc1929>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/rfc/rfc2827>.

   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
              Engineering Task Force Standard Protocols", BCP 61,
              RFC 3365, DOI 10.17487/RFC3365, August 2002,
              <https://www.rfc-editor.org/rfc/rfc3365>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3552>.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              DOI 10.17487/RFC3927, May 2005,
              <https://www.rfc-editor.org/rfc/rfc3927>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.





Vance                    Expires 5 November 2026                [Page 8]

Internet-Draft                  SOCKS 4A                        May 2026


   [RFC4732]  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
              Denial-of-Service Considerations", RFC 4732,
              DOI 10.17487/RFC4732, December 2006,
              <https://www.rfc-editor.org/rfc/rfc4732>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/rfc/rfc5246>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5890>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5891>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015,
              <https://www.rfc-editor.org/rfc/rfc7626>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/rfc/rfc7858>.

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/rfc/rfc791>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9293>.







Vance                    Expires 5 November 2026                [Page 9]

Internet-Draft                  SOCKS 4A                        May 2026


Appendix A.  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.

A.1.  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.

A.1.1.  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.

A.1.2.  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.

A.2.  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.



Vance                    Expires 5 November 2026               [Page 10]

Internet-Draft                  SOCKS 4A                        May 2026


A.2.1.  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.

A.2.2.  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 Appendix B.4).

A.2.3.  Character Set Consistency

   While this document recommends US-ASCII or Punycode (Section 3.1.2),
   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.

Appendix B.  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 [RFC8446].  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



Vance                    Expires 5 November 2026               [Page 11]

Internet-Draft                  SOCKS 4A                        May 2026


   infrastructure.

B.1.  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 [RFC1918], 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.

B.2.  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 [RFC7626].  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 [RFC7858] or DNS over HTTPS [RFC8484], 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.,
   [RFC4301] or [RFC5246]), the DOMAIN string itself is transmitted in
   the clear, negating any privacy benefits intended by the use of
   remote resolution.

B.3.  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.




Vance                    Expires 5 November 2026               [Page 12]

Internet-Draft                  SOCKS 4A                        May 2026


   To mitigate this, implementations MUST adhere to the guidance in
   [RFC2827] 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 [RFC1918], and link-local addresses [RFC3927].  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.

B.4.  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 [RFC4732], 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 [RFC1035].  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.

B.5.  Protocol Rollback and Downgrade Attacks

   While SOCKS 4A was designed to improve upon SOCKSv4, it remains a
   subset of the capabilities provided by SOCKSv5 [RFC1928].  SOCKSv5
   offers robust authentication methods [RFC1929] 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.

B.6.  Interaction with Internationalized Domain Names

   The use of the DOMAIN field requires careful handling of
   Internationalized Domain Names (IDNs).  As noted in [RFC5890], 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 [RFC5891]
   before transmission.  Servers SHOULD treat the DOMAIN string as an



Vance                    Expires 5 November 2026               [Page 13]

Internet-Draft                  SOCKS 4A                        May 2026


   opaque sequence of octets to be passed to the resolver, while
   ensuring that the resulting IP address undergoes the filtering
   described in Appendix B.3.

B.7.  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 [RFC1928] combined
   with TLS is strongly recommended to ensure the confidentiality and
   integrity of the session.

Appendix C.  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.

Appendix D.  Relationship with SOCKS 4

   See Appendix A of [I-D.vance-socks-v4] for the reason why SOCKS 4A
   was not an extension of SOCKS Version 4.

Original Author








Vance                    Expires 5 November 2026               [Page 14]

Internet-Draft                  SOCKS 4A                        May 2026


         Ying-Da Lee
         Principal Member Technical Staff
         NEC Systems Laboratory, CSTC
         ylee@syl.dl.nec.com

         David Koblas
         Netskope

   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

         George G. Michaelson
         Asia-Pacific Network Information Centre
         6 Cordelia St
         South Brisbane QLD 4101
         Australia
         Email: ggm@algebras.org

Author's Address

   Daniel James Vance
   Independent
   Email: djvanc@outlook.com






















Vance                    Expires 5 November 2026               [Page 15]
