[
https://issues.apache.org/jira/browse/KAFKA-17959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897214#comment-17897214
]
Arushi Helms commented on KAFKA-17959:
--------------------------------------
Sure [~gnarula].
In the meantime, here is the snippet of the configurations from both controller
and broker.
NOTE:
* *The hostname for the node does not match the CN but since we are using IPs
as communication, we have provided IPs as SAN.*
*CONTROLLER:*
Relevant controller configurations from one of the controllers:
{noformat}
KAFKA_CFG_PROCESS_ROLES=controller
KAFKA_KRAFT_CLUSTER_ID=5kztjhJ4SxSu-kdiEYDUow
KAFKA_CFG_NODE_ID=6
KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=4@10.87.170.83:9097,5@10.87.170.9:9097,6@10.87.170.6:9097
KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
KAFKA_CFG_INTER_BROKER_LISTENER_NAME=INSIDE_SSL
KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:SSL,INSIDE_SSL:SSL
KAFKA_CFG_LISTENERS=CONTROLLER://10.87.170.6:9097{noformat}
Controller certificate has:
{noformat}
Common Name: *.kafka.service.consul
Subject Alternative Names: *.kafka.service.consul, IP
Address:10.87.170.6{noformat}
*BROKER:*
Relevant broker configuration from one of the brokers:
{noformat}
KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
KAFKA_CFG_INTER_BROKER_LISTENER_NAME=INSIDE_SSL
KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=4@10.87.170.83:9097,5@10.87.170.9:9097,6@10.87.170.6:9097
KAFKA_CFG_PROCESS_ROLES=broker
KAFKA_CFG_NODE_ID=3
KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=INSIDE_SSL:SSL,OUTSIDE_SSL:SSL,CONTROLLER:SSL
KAFKA_CFG_LISTENERS=INSIDE_SSL://10.87.170.78:9093,OUTSIDE_SSL://10.87.170.78:9096
KAFKA_CFG_ADVERTISED_LISTENERS=INSIDE_SSL://10.87.170.78:9093,OUTSIDE_SSL://10.87.170.78:9096{noformat}
Broker certificate has:
{noformat}
Common Name: *.kafka.service.consul
Subject Alternative Names: *.kafka.service.consul, IP
Address:10.87.170.78{noformat}
> 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)
