[Gluster-devel] [erik.jacobson at hpe.com: [Gluster-users] gluster forcing IPV6 on our IPV4 servers, glusterd fails (was gluster update question regarding new DNS resolution requirement)]

[Paul Jakma]

On Tue, 21 Sep 2021, Yaniv Kaul wrote:

> However, I do feel 'transport.address-family' should have been set to 
> IPv4 to force IPv4 regardless. Then the question is why 
> socket_client_get_remote_sockaddr() is calling 
> client_fill_address_family() to get the family address, but then the 
> next flow, a call to af_inet_client_get_remote_sockaddr() - which has 
> this information, but ignores it (as we see above). Y.

This isn't the only problem.

The code in the gluster servers has pretty strong assumptions in it that 
IP must resolve to a hostname that resolves to the IP. Presumably as a 
security check, presumably from the original (pre-SSL) security model.

This is a fragile assumption, both security wise, and operationally. 
With every additional network and/or address this constraint gets harder 
to maintain / more fragile.

And of course, dual-stack networks will have multiple addresses. And you 
don't per se want to list an IPv6 address in the main service hostname. 
You may have IPv6 only hosts and dual-stack hosts. You may use IPv6 
privacy addresses, which rotate.

This assumption may work initially, but then fail later down the road. 
It makes gluster very flakey operationally, with IPv6.

When you're using SSL for security, which provides a _secure_ notion of 
identity (unlike IP and hostname), independent of addresses, this 
fragile assumption feels antiquated.

regards,
-- 
Paul Jakma | paul at jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
At the source of every error which is blamed on the computer you will find
at least two human errors, including the error of blaming it on the computer.