[
https://issues.apache.org/jira/browse/KAFKA-17959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897582#comment-17897582
]
Arushi Helms edited comment on KAFKA-17959 at 11/12/24 7:46 PM:
----------------------------------------------------------------
Thanks for the response [~gnarula].
-Sometime back I think I did try this with 3.8.0 as well but let me check the
behavior again to be 100% sure.-
I think when we first ran into this issue, 3.8.0 wasn't released and we went
with the workaround. Testing our flows with 3.8.0 now and will get back to you.
was (Author: JIRAUSER305554):
Thanks for the response [~gnarula].
Sometime back I think I did try this with 3.8.0 as well but let me check the
behavior again to be 100% sure.
> 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.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)
