[
https://issues.apache.org/jira/browse/KAFKA-17959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897154#comment-17897154
]
Gaurav Narula edited comment on KAFKA-17959 at 11/11/24 10:32 AM:
------------------------------------------------------------------
Hi [~arushi315]! I'm unable to reproduce this locally in a docker setup where I
use TLS on the controller listener with an IP in the SAN and connect to the
controller using its IP. The TLS stack is the same across the controller and
the broker so I'm surprised you're observing the reverse lookup in only one of
them.
I wonder if the connection is being initiated on the hostname instead of the
IP. Can you please enable debug logs for {{org.apache.kafka.clients}} and
search for the following strings
{code}
"Resolved host"
"Initiating connection to node"
{code}
was (Author: gnarula):
Hi [~arushi315]! I'm unable to reproduce this locally in a docker setup where I
use TLS on the controller endpoint with an IP in the SAN and connect to the
controller using its IP. The TLS stack is the same across the controller and
the broker so I'm surprised you're observing the reverse lookup in only one of
them.
I wonder if the connection is being initiated on the hostname instead of the
IP. Can you please enable debug logs for {{org.apache.kafka.clients}} and
search for the following strings
{code}
"Resolved host"
"Initiating connection to node"
{code}
> 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.6.0, 3.7.0, 3.8.0, 3.7.1
> Reporter: Arushi Helms
> Assignee: Gaurav Narula
> Priority: Blocker
>
> 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)
