Arushi Helms created KAFKA-17959:
------------------------------------
Summary: Avoid Reverse DNS Lookup for IP-Based SSL Authentication
in Kraft Mode
Key: KAFKA-17959
URL: https://issues.apache.org/jira/browse/KAFKA-17959
Project: Kafka
Issue Type: Bug
Components: kraft
Affects Versions: 3.7.1, 3.8.0, 3.7.0, 3.6.0
Reporter: Arushi Helms
We have encountered an issue with Kafka's Kraft mode where reverse DNS lookups
are being performed unnecessarily during SSL authentication between controllers
and between brokers and controllers, despite using IP addresses for
communication.
In our Kafka setup, we are using IP addresses for communication and have
configured certificates with {*}IP addresses in the Subject Alternative Name
(SAN){*}. However, when the controller tries to establish SSL connections with
other controllers or brokers, it attempts a reverse DNS lookup on the IP
address (e.g., {{{}10.87.170.83{}}}), which causes SSL handshake failures due
to the mismatch between the resolved hostname and the IP address in the
certificate.
The issue arises even though the certificate contains the IP in the SAN and
should not require a reverse DNS lookup. This unnecessary lookup introduces
delays and inconsistencies, especially in environments where DNS resolution is
not required or reliable (e.g., in private networks).
h3. Affected Scenarios:
# {*}Broker-to-Controller Communication{*}: The broker fails to authenticate
with the controller because the reverse DNS lookup of the controller's IP
address does not match the expected DNS name in the certificate.
# {*}Controller-to-Controller Communication{*}: Controllers also fail to
authenticate with each other due to similar reverse DNS lookup issues.
h3. Current Behavior:
* Kafka's SSL handshake fails when using IPs for communication, with errors
like
{code:java}No subject alternative DNS name matching <resolved hostname>
found{code} due to reverse DNS lookup mismatches.
* The controller attempts reverse DNS lookups even when the connection is
established using IP addresses directly.
h3. Expected Behavior:
* Kafka should use the *IP address directly* for SSL engine creation and
authentication when IPs are provided for communication, without performing a
reverse DNS lookup.
* *SSL hostname verification* should match the IP address in the SAN of the
certificate, not a resolved DNS name.
h3. Request:
* Please address the issue by ensuring that Kafka does *not perform reverse
DNS lookups* for SSL authentication when IP addresses are explicitly provided
for communication.
* This behavior should be consistent across all Kafka components (brokers and
controllers) in Kraft mode.
Old ticket with similar issue for reference:
https://issues.apache.org/jira/browse/KAFKA-5051
--
This message was sent by Atlassian Jira
(v8.20.10#820010)