On Tue, Apr 08, 2025 at 09:33:47AM +0200, Lucas Rosalen wrote: > We have a strange behavior when attempting to download maintenance use SMPE > Receive Order. > > As indicated here ( > https://www.ibm.com/support/pages/ibm-software-electronic-delivery-servers-change), > our firewall has been opened for: > deliverycb-mul.dhe.ibm.com - 129.35.224.118 > deliverycb-mul.dhe.ibm.com - 170.225.126.48 > > However the download fails. > > When we ping deliverycb-mul.dhe.ibm.com, it resolves to 170.225.119.154, > not to the IPs above. > We tried ping/nslookup deliverycb-mul.dhe.ibm.com from several clients, > from our own laptops in different networks, but they all resolve the same.
In DNS on the public internet, deliverycb-mul.dhe.ibm.com is a CNAME to deliverycb-mul.dublindata.ibm.com., which in turn resolves to 170.225.119.154 currently. > We have a case opened with IBM, but they say don't support DNS resolution. Well, that is a contradiction in itself, for a number of reasons. * The website at [1] clearly states the FQDNs (they call them hostnames there). * Apparently the webserver that feels responsible for deliverycb-mul.dhe.ibm.com has a vhost set up for that FQDN only, not for the IP address. if you punch, let's say https://170.225.119.154/ into your browser, you are being served a certificate that is valid for the FQDN only, not for the IP address. Your browser is going to warn you about that condition, will allow you to continue though, as a match is not enforced. If they do not support DNS resolution, why are there DNS entries for the servers? Why are the web servers configured so that they only accept requests targeted at those FQDNs? Anyways... Provided DNS wouldn't be there at all and you still wanted to download from those servers. You could either instruct your download program to talk to that specific IP, e.g. $ curl --connect-to 170.225.119.154:443 https://deliverycb-mul.dhe.ibm.com Or you can associate the IP address with the FQDN in /etc/hosts or whatever the equivalent on Windows is. What really happened here is that they changed the IP adddresses of their servers for some unknown reason and neglected to drive appropriate customer communication and also neglected to update the documentation that you pointed to. Assuming that no funny business is happening here, you can just update your firewall rules to allow traffic to the 'new' IP address and be done with it. Modern firewalls can also whitelist DNS entries... The whole thing does not smell strange, the 'new' IP address is owned by IBM. I wouldn't worry too much about this. -Alex [1] https://www.ssllabs.com/ssltest/analyze.html?d=deliverycb-bld.dhe.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
