Skip to Main Content
IBM Z Software


This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Categories z/TPF
Created by Guest
Created on Jul 23, 2024

Proposal for enhanced z/TPF DNS Client behavior and alerting

The recent exchange between the IBM z/TPF Lab and DXC in the Support Case TS016560816 has suggested that IBM would be open to considering enhancements to the behavior and/or alerting for the DNS client processing associated with gethostbyname and gethostbyaddr resolutions sent to a remote DNS server.  This is to serve as the formalization of that RFE.

 

The problem statement that DXC provided in the Support Case described a recent incident where the Primary DNS server at our site (ZDTCP DNS PRI) was experiencing problems, and was not returning resolution responses.  During this incident, gethostbyname resolutions were still being satisfied, due to the calls failing over to the Secondary DNS server (ZDTCP DNS SEC) and succeeding.  No actual IP “broken connections” or “failed connection attempts” were being experienced.  However, the timeout wait during the first resolution call to the Primary DNS server was contributing to notably increased connection times – which, across the system, were experienced as increased response times.  Since there were no actual connection failures being observed, it was unclear, for an extended period, why response times were elongated.  In the follow-up from the incident, it was determined that we could wish for the z/TPF DNS client to provide some visibility to when the Primary DNS server is chronically failing to provide resolutions, or perhaps even some monitoring behavior that could automatically reorder the calls to Secondary server versus Primary server for a time, if it was recognized that an interval was being experienced where the Primary DNS was not responding with resolutions.

 

In the response to the Support Case, following some internal deliberations at the Lab, this was provided to DXC on 07/16/2024 regarding what IBM might consider…

 

The thought is to have knowledge of when one of the DNS servers is not responding, and switch to try the secondary first for a period of time. WTOPCing information to the console when a failure occurs. The implementation details will need to be worked out, but it sounds like an RFE would be accepted to address this.

 

With this RFE, DXC does request IBM to undertake development in the z/TPF gethostbyname and gethostbyaddr DNS client processing that would incorporate some portion of what has been considered in the Support Case TS016560816.

 

Thanks and Regards.

Brent Worden

DXC Technology

Tulsa, Oklahoma

 

Idea priority Low
  • Guest
    Reply
    |
    Jul 23, 2024

    One additional item to add to the RFE.  Within the aforementioned Support Case TS016560816, there was some discussion of whether the existing hard-coded 2-second Timeout wait for a response from the DNS Server could instead be made a configurable value, and what that would require.  In the wake of the recent DNS server incident that occurred at our site, the follow-up discussions have produced considerable interest in whether that timeout value could be made configurable - including sub-second.  Opinions have been expressed that 2 seconds is an overly generous amount of time for such a response.  As part of this RFE, we do also ask that IBM explore whether the timeout value for requests to the DNS server could be made configurable - including a sub-second value.