Merge pull request #81598 from johnwilkins/HCIDCOS-348

HCIDOCS-348: Requirement to accept queries both over UDP and TCP by upstream DNS servers missing

Author: JoeAldinger

modules/ipi-install-network-requirements.adoc

@@ -6,7 +6,7 @@
 [id="network-requirements_{context}"]
 = Network requirements
 
-Installer-provisioned installation of {product-title} involves several network requirements. First, installer-provisioned installation involves an optional non-routable `provisioning` network for provisioning the operating system on each bare metal node. Second, installer-provisioned installation involves a routable `baremetal` network.
+Installer-provisioned installation of {product-title} involves multiple network requirements. First, installer-provisioned installation involves an optional non-routable `provisioning` network for provisioning the operating system on each bare-metal node. Second, installer-provisioned installation involves a routable `baremetal` network.
 
 image::210_OpenShift_Baremetal_IPI_Deployment_updates_0122_2.png[Installer-provisioned networking]
 
@@ -28,23 +28,23 @@ Certain ports must be open between cluster nodes for installer-provisioned insta
 
 | `123` | The cluster nodes must access the NTP server on port `123` using the `baremetal` machine network.
 
-|`5050`| The Ironic Inspector API runs on the control plane nodes and listens on port `5050`. The Inspector API is responsible for hardware introspection, which collects information about the hardware characteristics of the bare metal nodes.
+|`5050`| The Ironic Inspector API runs on the control plane nodes and listens on port `5050`. The Inspector API is responsible for hardware introspection, which collects information about the hardware characteristics of the bare-metal nodes.
 
 |`5051`| Port `5050` uses port `5051` as a proxy.
 
 |`6180`| When deploying with virtual media and not using TLS, the provisioner node and the control plane nodes must have port `6180` open on the `baremetal` machine network interface so that the baseboard management controller (BMC) of the worker nodes can access the {op-system} image. Starting with {product-title} 4.13, the default HTTP port is `6180`.
 
 |`6183`| When deploying with virtual media and using TLS, the provisioner node and the control plane nodes must have port `6183` open on the `baremetal` machine network interface so that the BMC of the worker nodes can access the {op-system} image.
 
-|`6385`| The Ironic API server runs initially on the bootstrap VM and later on the control plane nodes and listens on port `6385`. The Ironic API allows clients to interact with Ironic for bare metal node provisioning and management, including operations like enrolling new nodes, managing their power state, deploying images, and cleaning the hardware.
+|`6385`| The Ironic API server runs initially on the bootstrap VM and later on the control plane nodes and listens on port `6385`. The Ironic API allows clients to interact with Ironic for bare-metal node provisioning and management, including operations such as enrolling new nodes, managing their power state, deploying images, and cleaning the hardware.
 
 |`6388`| Port `6385` uses port `6388` as a proxy.
 
 |`8080`| When using image caching without TLS, port `8080` must be open on the provisioner node and accessible by the BMC interfaces of the cluster nodes.
 
 |`8083`| When using the image caching option with TLS, port `8083` must be open on the provisioner node and accessible by the BMC interfaces of the cluster nodes.
 
-|`9999`| By default, the Ironic Python Agent (IPA) listens on TCP port `9999` for API calls from the Ironic conductor service. This port is used for communication between the bare metal node where IPA is running and the Ironic conductor service.
+|`9999`| By default, the Ironic Python Agent (IPA) listens on TCP port `9999` for API calls from the Ironic conductor service. Communication between the bare-metal node where IPA is running and the Ironic conductor service uses this port.
 
 |====
 
@@ -90,6 +90,8 @@ test-cluster.example.com
 
 {product-title} includes functionality that uses cluster membership information to generate A/AAAA records. This resolves the node names to their IP addresses. After the nodes are registered with the API, the cluster can disperse node information without using CoreDNS-mDNS. This eliminates the network traffic associated with multicast DNS.
 
+CoreDNS requires both TCP and UDP connections to the upstream DNS server to function correctly. Ensure the upstream DNS server can receive both TCP and UDP connections from {product-title} cluster nodes.
+
 In {product-title} deployments, DNS name resolution is required for the following components:
 
 * The Kubernetes API
@@ -134,7 +136,7 @@ Network administrators must reserve IP addresses for each node in the {product-t
 [id="network-requirements-reserving-ip-addresses_{context}"]
 == Reserving IP addresses for nodes with the DHCP server
 
-For the `baremetal` network, a network administrator must reserve a number of IP addresses, including:
+For the `baremetal` network, a network administrator must reserve several IP addresses, including:
 
 . Two unique virtual IP addresses.
 +
@@ -162,7 +164,7 @@ External load balancing services and the control plane nodes must run on the sam
 The storage interface requires a DHCP reservation or a static IP.
 ====
 
-The following table provides an exemplary embodiment of fully qualified domain names. The API and Nameserver addresses begin with canonical name extensions. The hostnames of the control plane and worker nodes are exemplary, so you can use any host naming convention you prefer.
+The following table provides an exemplary embodiment of fully qualified domain names. The API and name server addresses begin with canonical name extensions. The hostnames of the control plane and worker nodes are exemplary, so you can use any host naming convention you prefer.
 
 [width="100%", cols="3,5,2", options="header"]
 |=====
@@ -180,7 +182,7 @@ The following table provides an exemplary embodiment of fully qualified domain n
 
 [NOTE]
 ====
-If you do not create DHCP reservations, the installer requires reverse DNS resolution to set the hostnames for the Kubernetes API node, the provisioner node, the control plane nodes, and the worker nodes.
+If you do not create DHCP reservations, the installation program requires reverse DNS resolution to set the hostnames for the Kubernetes API node, the provisioner node, the control plane nodes, and the worker nodes.
 ====
 
 [id="network-requirements-provisioner_{context}"]
@@ -193,7 +195,7 @@ The provisioner node requires layer 2 connectivity for network booting, DHCP and
 [id="network-requirements-ntp_{context}"]
 == Network Time Protocol (NTP)
 
-Each {product-title} node in the cluster must have access to an NTP server. {product-title} nodes use NTP to synchronize their clocks. For example, cluster nodes use SSL certificates that require validation, which might fail if the date and time between the nodes are not in sync.
+Each {product-title} node in the cluster must have access to an NTP server. {product-title} nodes use NTP to synchronize their clocks. For example, cluster nodes use SSL/TLS certificates that require validation, which might fail if the date and time between the nodes are not in sync.
 
 [IMPORTANT]
 ====