Weird host name / ip address lookup issue

[wyang007]

I ran into a weird name lookup issue:

1. I have a host 134.79.23.45.
2. Its DNS name is sdfdtn005.slac.stanford.edu everywhere, except on the node itself.
3. On the node, its hostname is also the above, but an name lookup of the ip address will give sdfdtn005.sdf.slac.stanford.edu (note the .sdf.)
4. domain name .sdf.slac.stanford.edu is not known anywhere except on this host (and other nodes in SLAC's newest computing facility)
5. Don't ask why 3) and 4). it is politics.

When xrootd starts, it somehow associate the IP address to sdfdtn005.sdf.slac.stanford.edu.

a) using xrootd client in 5.5.0, after TLS, the client (xrdfs) will try to reach to sdfdtn005.slac. So all works
b) using xrootd client in 5.4.x, after TLS, the client (xrdfs) will try to reach to sdfdtn005.sdf.slac... this will fail because domain .sdf.slac.stanford.edu is not known to the outside.

I worked around this issue by manipulating /etc/hosts so that the IP address is associated to sdfdtn005.slac.stanford.edu

why these different behavior between xrootd 5.5.0 and xroot 5.4.x ?
how to prevent xrootd from associating 134.79.23.45 to sdfdtn005.sdf.slac (especially since its host name is sdfdtn005.slac)

[xrootd-dev]

Hi Wei, First, these kinds of politics appear at other institutions where te name of the node is different on the inside that it is on the outside. So, the problem is known and a feature ehancement request has been made by one of these institutions. Second, the way you have solved the problem is the way other sites have solved this problem, so it's a workable, though cumbersome, workaround. I am suprised that there is a difference betwee 5.4.x and 5.5.x. The only change that was introduced was in 5.4.0 (so there would be a change between 5.3. and 5.4) that accomodated K8s network namespaces by switching to the way that a server's self-IP adress is esolved. This made the "hidden" intermediate node name visible. This was needed because in an k8s environment these intermediate node names are automatically introduced to support namespaces and the cmsd needs to know about them in order to recover from network failures. Anyway, I will run a test to see whee the difference actually comes from. Andy On Sun, 25 Sep 2022, Wei Yang wrote:

…

I ran into a weird name lookup issue: 1. I have a host 134.79.23.45. 2. Its DNS name is sdfdtn005.slac.stanford.edu everywhere, except on the node itself. 3. On the node, its hostname is also the above, but an name lookup of the ip address will give sdfdtn005.sdf.slac.stanford.edu (note the .sdf.) 4. domain name .sdf.slac.stanford.edu is not known anywhere except on this host (and other nodes in SLAC's newest computing facility) 5. Don't ask why 3) and 4). it is politics. When xrootd starts, it somehow associate the IP address to sdfdtn005.sdf.slac.stanford.edu. a) using xrootd client in 5.5.0, after TLS, the client (xrdfs) will try to reach to sdfdtn005.slac. So all works b) using xrootd client in 5.4.x, after TLS, the client (xrdfs) will try to reach to sdfdtn005.sdf.slac... this will fail because domain .sdf.slac.stanford.edu is not known to the outside. I worked around this issue by manipulating /etc/hosts so that the IP address is associated to sdfdtn005.slac.stanford.edu why these different behavior between xrootd 5.5.0 and xroot 5.4.x ? how to prevent xrootd from associating 134.79.23.45 to sdfdtn005.sdf.slac (especially since its host name is sdfdtn005.slac) -- Reply to this email directly or view it on GitHub: #1787 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1

[abh3]

I am about to close this issue chalking this up to improper registration of hosts in a subdomain. Specifically, IP address 134.79.23.45 is registered with two names in the sdf subnet: sdfdtn005.sdf.slac.stanford.edu and sdfdtn005.slac.stanford.edu. The reverse translation of the IP address only resolves to the name sfdtn005.sdf.slac.stanford.edu.

Now the same lookup outside of the subdomain the IP address is only attached to the host name sdfdtn005.slac.stanford.edu and host name sfdtn005.sdf.slac.stanford.edu is not accessible (i.e.not registered).

I would say this is incorrect as both names have the same IP address so there is no reason not to make the registration consistent across DNS servers.

[abh3]

I am closing this as no further information is forthcoming.