[
https://issues.apache.org/jira/browse/ZOOKEEPER-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632380#comment-16632380
]
Andor Molnar commented on ZOOKEEPER-3156:
-----------------------------------------
[~revans2] Thanks for looking into this. As long as you're the assignee of this
Jira, I'm happy to wait for your pull request to review.
Regarding backwards compatibility: "...could run into an issue where each
ensemble wants something different"
This wasn't supported previously either: meaning that previous versions always
did reverse IP lookups, so basically followed the behaviour that you mentioned
as 3.4.12. Therefore I don't think the fix could cause backward compatibility
issues as long as the default behaviour is the original (rnds=true).
Let's try to wrap up what I think happened here:
- Previous versions of ZooKeeper (up to 3.4.12) did DNS resolution upfront and
returned the pure IP address to upper layers like the SASL client. The original
implementation stripped the hostname from the InetSocketAddress after name
resolution and created a new one with only IP address and port number,
- This was fine for connecting the client to the server, because it only needs
the IP address,
- It forced the SASL client to do reverse DNS lookup by calling getHostName(),
- The current behaviour, which I think is the right approach, creates new
InetSocketAddress with the resolved IP address and the original hostname, so
upper layers don't need to do reverse lookup.
With the new switch and using getCanonicalHostName() in the SASL client we can
enforce the reverse lookup which is needed here.
> ZOOKEEPER-2184 causes kerberos principal to not have resolved host name
> -----------------------------------------------------------------------
>
> Key: ZOOKEEPER-3156
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3156
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.6.0, 3.4.13, 3.5.5
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
> Priority: Blocker
>
> Prior to ZOOKEEPER-2184 the zookeeper client would canonicalize a configured
> host name before creating the SASL client which is used to create the
> principal name. After ZOOKEEPER-2184 that canonicalization does not happen
> so the principal that the ZK client tries to use when it is configured to
> talk to a CName is different between 3.4.13 and all previous versions of ZK.
>
> For example
>
> zk1.mycluster.mycompany.com maps to real-node.mycompany.com.
>
> 3.4.13 will want the server to have
> [zookeeper/zk1.mycluster....@kdc.mycompany.com|mailto:zookeeper/zk1.mycluster....@kdc.mycompany.com]
> 3.4.12 wants the server to have
> [zookeeper/real-node.mycompany....@kdc.mycompany.com|mailto:zookeeper/real-node.mycompany....@kdc.mycompany.com]
>
> This makes 3.4.13 incompatible with many ZK setups currently in existence.
> It would be nice to have that resolution be optional because in some cases it
> might be nice to have a single principal tied to the cname.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
