[
https://issues.apache.org/jira/browse/KAFKA-17959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897498#comment-17897498
]
Gaurav Narula commented on KAFKA-17959:
---------------------------------------
Thanks for sharing those logs [~arushi315]. Can you please share the Kafka
version you're trying this with? I can reproduce the issue on the 3.7 branch
and deduce it to the following:
*Controller-Controller Communication*
I think this is because {{QuorumConfig::voterConnectionsToNodes}} used
{{InetSocketAddress#getHostName()}} prior to KAFKA-16207 landing in {{3.8.0}}.
*Broker-Controller Communication*
I think this is because {{RaftControllerNodeProvider}} used
{{QuorumConfig::voterConnectionsToNodes}} prior to KAFKA-16516 landing in
{{3.8.0}}.
I realise you've marked in the JIRA that this affects {{3.8.0}} but I want to
confirm that once again.
> 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)
