Free 3V0-23.25 Practice Test Questions 2026

Explanation:

This question tests understanding of vSAN maintenance mode behavior and fault tolerance. With the default vSAN storage policy of RAID-1 and FTT=1, objects can tolerate only a single host, disk, or network failure. When one host is placed in maintenance mode using Ensure Accessibility and a second host subsequently becomes unavailable, some object components may no longer have the required quorum, causing VM accessibility issues.

🟢 Correct Option:

D. Some VMs become inaccessible until one of the affected hosts return to service.
The Ensure Accessibility option keeps objects accessible during maintenance but does not create additional replicas. With RAID-1 and FTT=1, vSAN can tolerate only one failure. Once a host is in maintenance mode and another host loses connectivity, some objects may lose quorum because multiple components become unavailable. As a result, affected VMs can become inaccessible until connectivity is restored or the maintenance host returns to service.

🔴 Incorrect Options:

A. Data is permanently lost for affected objects.
The scenario describes temporary host unavailability rather than permanent device or host loss. The object components still exist on the unavailable hosts. Therefore, data is not permanently lost and can become available again when one of the affected hosts returns.

B. All VMs remain accessible; vSAN automatically rebalances to the other hosts.
The Ensure Accessibility mode does not trigger full data evacuation or create additional replicas before maintenance. Since RAID-1 with FTT=1 only tolerates a single failure, losing a second host can cause quorum loss, making some VMs inaccessible despite remaining hosts being operational.

C. vSAN rebuilds missing components immediately on remaining hosts.
vSAN does not immediately rebuild components when a host enters maintenance mode with Ensure Accessibility selected. Rebuild operations are subject to timers and available resources. In this scenario, the second host failure occurs before sufficient redundancy can be restored, leading to potential object unavailability.

🔧 Reference:
⇒ vSAN Maintenance Mode Options
Confirms the behavior of Ensure Accessibility and how object availability is maintained during host maintenance.

⇒ vSAN Object Availability and Failures to Tolerate Policies
Explains RAID-1, FTT=1 behavior, quorum requirements, and object accessibility during host failures.

Explanation:

This question tests knowledge of vSAN Data Protection immutable snapshots. Immutable snapshots are designed to protect recovery points from modification or deletion, helping organizations recover from ransomware and cyber-attacks. Because the snapshots must remain unchanged, VMware enforces specific restrictions on protected VMs and protection groups to preserve the integrity of the recovery data.

🟢 Correct Option:

A. The Virtual Machine cannot be part of multiple protection groups.
A VM configured with immutable snapshot protection can belong to only one protection group. Allowing membership in multiple protection groups could create conflicting retention policies, schedules, and immutability settings. Restricting a VM to a single protection group ensures consistent management of protected recovery points and maintains predictable recovery operations.

🟢 Correct Option:

C. Virtual machine hardware cannot be changed on VM having immutable snapshots.
When immutable snapshots exist, VM hardware reconfiguration operations are restricted. Changes such as adding or removing virtual devices could affect the consistency of protected recovery points. VMware therefore prevents hardware modifications while immutable snapshots are present, ensuring that recovery data remains valid and protected against accidental or malicious changes.

🔴 Incorrect Options:

B. The protection group cannot have more than 7 snapshot schedules.
There is no VMware limitation restricting immutable protection groups to a maximum of seven snapshot schedules. Snapshot scheduling limits are determined by overall product capabilities and configuration guidelines rather than by immutability requirements.

D. Virtual Machine hardware must be at least version 10.
Immutable snapshot functionality is not tied to VM hardware version 10. The feature is managed through vSAN Data Protection and protection-group policies, making the virtual hardware version requirement stated in this option incorrect.

E. The protection group cannot be both replicated and immutable.
Replication and immutability address different protection objectives. VMware does not require these capabilities to be mutually exclusive, and a protection group can support replication-related features while maintaining immutable recovery points.

🔧 Reference:
⇒ vSAN Data Protection Administration Guide
Describes immutable snapshots, protection groups, and operational restrictions for protected virtual machines.

⇒ vSAN Data Protection - Immutable Protection Group Restrictions
Confirms restrictions associated with immutable protection groups and protected VM configurations.

Explanation:

This question tests knowledge of VMware Cloud Foundation 9.0 principal storage requirements for a minimum configuration. The key constraints are only 2 hosts and no budget for additional hardware. Standard hyperconverged storage (like vSAN) or Fibre Channel typically requires at least 3 hosts. NFS v3 is the only option supported for this minimal scenario .

✔️ Option C (NFS v3):
VCF 9.0 supports NFS v3 as a principal storage solution for clusters, including minimal configurations with only 2 hosts . Since the customer has an existing NFS-capable array and only two recycled hosts, NFS v3 fits the hardware constraints (no need for additional shared storage hardware) and meets the connectivity requirement via 10GbE .

❌ Option A (Fibre Channel):
While Fibre Channel is supported as principal storage in VCF 9.0, it typically requires a minimum of 3 hosts . Additionally, the hosts provided lack Fibre Channel HBAs (only 10GbE network cards are listed), and the budget does not allow for purchasing new adapters.

❌ Option B (NFS v4.1):
NFS v4.1 is supported, but primarily as a supplemental storage type for workload domains, not as principal storage for new clusters in automated greenfield deployments . Given the customer requires principal storage for this new cluster, NFS v3 is the more compatible and straightforward choice.

❌ Option D (Fibre Channel over Ethernet):
FCoE is not listed as a supported principal storage model for workload domains in VCF 9.0 . It also requires specific hardware convergence (Converged Network Adapters) not present in the provided server configuration and would fail to meet the deployment requirements.

🔧 Reference:
→ Broadcom TechDocs: Storage Models – Confirms NFS v3 supports principal storage for management domains and VI workload domains.
→ VMware Blog: VCF 9 Now Ready For All Storage – Details support for NFS v3 as principal storage in greenfield deployments.

Explanation:

This question tests the administrator's knowledge of optimizing the host remediation lifecycle within a vSAN cluster managed by vSphere Lifecycle Manager (vLCM) images. It evaluates methods to minimize host reboot times and operational disruptions during critical security patching cycles.

✅ Correct Option:

B. Enable the Quick Boot setting in the host remediation settings for the images.
Quick Boot allows supported ESXi hosts to restart the hypervisor software without going through the physical hardware and BIOS/UEFI self-test (POST) sequence. Enabling this setting under vLCM image remediation drastically shortens host downtime, ensuring the vSAN cluster is patched quickly with the absolute least amount of disruption.

❌ Incorrect options:

A. Enable the suspend to memory feature in the host remediation settings for the baselines.
The cluster in this scenario is explicitly configured to use vSphere Lifecycle Manager images, rendering any remediation settings or adjustments tied to legacy VUM baselines completely irrelevant. Furthermore, suspend-to-memory features do not bypass the hardware boot cycle for full hypervisor-level security patches.

C. Disable the Quick Boot feature in the host remediation settings for the images.
Disabling Quick Boot forces every ESXi host in the vSAN cluster to undergo a complete cold reboot, including physical hardware initializations and memory checks. This significantly extends the remediation window for each host, increasing the overall time the cluster operates in a degraded or maintenance state.

D. Disable HA admission control in the host remediation settings for the baselines.
Modifying vSphere High Availability (HA) admission control configuration is a cluster-level resilience setting rather than a host boot optimization tool. Additionally, adjusting baseline-specific options will have zero functional effect on a cluster whose lifecycle is governed entirely by a unified vLCM image.

🔧 Reference:
⇒ VMware vSphere Lifecycle Manager Guide
→ Validates that Quick Boot is an image-based remediation setting designed to reduce ESXi upgrade downtime by skipping hardware re-initialization.

Explanation:

This question tests your understanding of vSAN behavior when encountering noncompliant VM objects with partial replica availability. When vSAN can locate either a full replica or more than 50% of votes for noncompliant objects, it forwards I/O operations to the available replica and automatically recovers corrupted objects if the cluster has sufficient resources to rebuild them.

✔️ Option A (Correct):
Automatically recovering the noncompliant objects and marking the VM as compliant is correct because vSAN can locate a full replica AND 55% of votes (which exceeds the 50% threshold). When vSAN cannot locate a full replica but CAN locate more than 50% of votes, it forwards I/O operations to the available replica. If the cluster contains enough resources, vSAN automatically recovers corrupted objects even when the failure is permanent. Since 55% exceeds the 50% minimum requirement for object accessibility, vSAN can rebuild the missing components and restore compliance.

❌ Option B (Incorrect):
Powering off the Virtual Machine is incorrect because vSAN only powers off or marks a VM as inaccessible when it cannot locate a full replica OR more than 50% of votes for the object. Since vSAN found 55% of votes (which exceeds the 50% threshold), the VM remains accessible and I/O operations continue through the available replica. VMs are only powered off when they become completely inaccessible due to insufficient votes, not when noncompliance exists with partial replica availability above the quorum threshold.

❌ Option C (Incorrect):
Marking the Virtual Machine as inaccessible is incorrect because the threshold for inaccessibility is NOT 60% - it's 50% of votes. The option states "vSAN is not able to locate more than 60% of the votes," which is factually wrong. vSAN can locate 55% of votes, which exceeds the actual 50% threshold required for availability. Since 55% > 50%, the VM remains accessible with I/O forwarded to the available replica, and vSAN will automatically rebuild the missing components.

❌ Option D (Incorrect):
Marking the Virtual Machine as orphaned is incorrect because orphaned status occurs specifically when the VM .vmx file is not accessible due to VM Home Namespace corruption, not when objects are noncompliant. Orphaned VMs have their configuration files unavailable, whereas noncompliant VM objects still exist but don't meet storage policy requirements. Since vSAN located 55% of votes and can access the object replica, the VM is neither corrupted nor orphaned. The objects are simply noncompliant and will be recovered automatically.

🔧 Reference:
→ Virtual Machine Appears as Noncompliant, Inaccessible or Orphaned in vSAN
Confirms that if vSAN cannot locate a full replica or more than 50% of votes, VM becomes inaccessible; with sufficient resources, vSAN automatically recovers corrupted objects

Explanation:

This question tests the administrator's knowledge of the prerequisite network and infrastructure requirements for enabling vSAN File Services in an Edge environment. vSAN File Service requires specific DVS configurations, NSX compatibility settings, and minimum versioning to deploy and serve NFS file shares correctly across the environment.

✅ Correct Options:

A. Create a dedicated port group for vSAN File Services in the DVS.
vSAN File Services requires a dedicated DVS port group to handle file service agent (FSA) traffic separately from other vSAN or management traffic. This dedicated port group provides the network path for NFS share access and is a mandatory configuration step before enabling the vSAN File Service on the cluster.

B. If using an NSX-based network, ensure that MAC Learning is enabled.
When vSAN File Services is deployed on an NSX-backed network, MAC Learning must be enabled on the DVS port group. File Service Agents use virtual IPs with unique MACs that NSX must learn dynamically. Without MAC Learning enabled, network traffic to file shares will be dropped or misdirected, causing NFS accessibility failures.

E. Hosts connected to a DVS version 6.6.0 or later.
vSAN File Services has a minimum DVS version requirement of 6.6.0. This version introduced the necessary port group capabilities and network features that File Service Agents depend on for proper operation. Hosts connected to older DVS versions are not supported and will prevent successful File Services enablement and deployment.

❌ Incorrect Options:

C. MAC Learning and Forged Transmits are disabled.
This is the opposite of the actual requirement. For vSAN File Services, Forged Transmits must be enabled on the port group to allow File Service Agents to send traffic using virtual IP addresses. Disabling both MAC Learning and Forged Transmits would break NFS file share connectivity entirely.

D. Jumbo frames are enabled on the network and the DVS port group.
Jumbo frames (MTU 9000) are a performance optimization, not a mandatory requirement for vSAN File Services. The service can be deployed and function correctly on standard MTU 1500 networks. While recommended in high-throughput environments, it is not listed as a prerequisite for enabling File Services in VMware's official documentation.

F. vSAN Witness functionality is enabled on each VMkernel.
vSAN Witness functionality on VMkernel adapters is specific to Stretched Cluster and Two-Node configurations for quorum purposes. It has no relevance to vSAN File Services deployment or NFS share delivery. Enabling witness functionality on each VMkernel is neither required nor related to File Services configuration.

🔧 Reference:
⇒ VMware vSAN File Services Configuration Guide → Confirms prerequisites including dedicated DVS port group, MAC Learning for NSX environments, and minimum DVS version 6.6.0 for vSAN File Services deployment.
⇒ VMware vSAN File Services and NSX Networking Requirements → Validates MAC Learning and Forged Transmits enablement requirements when deploying vSAN File Services on NSX-based network infrastructure.

Explanation:

This question tests the prerequisites for stretching a vSAN cluster across two availability zones in a VCF Workload Domain. Equal host distribution per site is already given; these four additional conditions must be satisfied.

✅ Correct Options:

The cluster must not include hosts from different subnets or networks (L3).
Stretched vSAN clusters in VCF require consistent L2/L3 networking design between sites. Hosts from different subnets can break vSAN stretched cluster communication and fault domain configuration.

The default management vSphere cluster must already be stretched.
For VI Workload Domains, the management domain cluster must be stretched first. This ensures NSX control plane and management components remain available during site events.

The cluster must not include DPU-backed hosts.
DPU-backed hosts are not supported in stretched vSAN clusters in VCF due to compatibility and networking constraints with the stretched topology.

The cluster must not share a vSAN Storage Policy with any other cluster.
Each stretched cluster must use its own dedicated vSAN storage policy. Sharing policies with other clusters is not allowed during stretch operations.

❌ Incorrect options:

The default management vSphere cluster must not be stretched.
This is the opposite of the requirement. The management cluster must be stretched before stretching a workload domain cluster.

SSH on all hosts in the cluster must be activated.
SSH enablement is not a prerequisite for stretching a vSAN cluster.

The cluster must not use host Self-Signed certificates.
Certificate type (self-signed vs. CA-signed) is not a blocking condition for vSAN cluster stretching.

🔧 Reference:
→ Stretching vSAN Clusters in VMware Cloud Foundation
Lists exact prerequisites and limitations for stretching workload domain clusters.

Explanation:

This question tests knowledge of vSAN performance troubleshooting. High cluster latency in vSAN performance charts often indicates that storage resources are unable to process I/O requests efficiently. One of the most common causes is congestion within disk groups, where queued operations increase response times and negatively impact overall cluster performance.

🟢 Correct Option:

D. There is congestion in one or more disk groups.
Disk group congestion occurs when storage devices become overloaded with read or write operations, causing I/O requests to queue and increasing latency. vSAN performance charts frequently expose this condition through elevated latency metrics. When one or more disk groups are congested, the entire cluster can experience slower storage performance, making this a likely root cause of the observed high latency.

🔴 Incorrect Options:

A. The Virtual Machines are using PVSCSI controllers.
PVSCSI controllers are recommended for high-performance workloads because they reduce CPU overhead and support greater I/O throughput. Their use generally improves storage efficiency rather than causing high vSAN cluster latency.

B. Jumbo frames are enabled on the VMkernel adapters.
Jumbo frames are commonly used in vSAN environments to improve network efficiency and reduce protocol overhead. When configured consistently across the network, they do not create storage latency issues and are not a typical cause of high vSAN latency.

C. Erasure Coding is disabled in the storage policy.
Disabling Erasure Coding results in RAID-1 style mirroring rather than RAID-5 or RAID-6 protection. While this affects capacity utilization, it does not inherently cause elevated latency or disk group congestion within the vSAN cluster.

🔧 Reference:
⇒ vSAN Monitoring and Troubleshooting Guide - Performance Metrics
Explains how latency and congestion metrics are used to identify storage performance bottlenecks in vSAN clusters.

⇒ vSAN Performance Service and Congestion Analysis
Describes vSAN performance monitoring, including disk group congestion and its impact on cluster latency.

Explanation:

This question tests knowledge of how to provide shared storage for a Windows Server Failover Cluster (WSFC) on a vSAN ESA cluster. WSFC requires a disk that can be accessed simultaneously by all cluster nodes with SCSI-3 Persistent Reservations for arbitration . On vSAN, this requirement can be met through two distinct methods: exposing storage via the vSAN iSCSI target service, or configuring native vSAN virtual disks with the correct controller settings .

✔️ Option A (vSAN iSCSI target):
The vSAN iSCSI target service enables both virtual and physical workloads to access vSAN datastores as block storage. Official VMware documentation explicitly confirms that vSAN iSCSI targets support Windows Server Failover Clustering (WSFC) . This method allows WSFC nodes to discover and connect to shared LUNs using standard iSCSI initiators, with each LUN protected by vSAN storage policies.

✔️ Option E (Paravirtual SCSI controller with physical bus sharing):
For native vSAN shared disks, VMware documentation specifies that shared disks must be accessed through a SCSI controller with SCSI Bus Sharing set to Physical . The recommended controller type for shared disks in WSFC configurations is the VMware Paravirtualized (PVSCSI) controller . This configuration enables SCSI-3 Persistent Reservations, which WSFC requires to arbitrate access to clustered disk resources .

❌ Option B (LSI SCSI controller per disk):
While LSI Logic SAS controllers are supported for boot disks in WSFC configurations, they are not the recommended controller type for shared disks. Furthermore, using a separate controller per disk does not fulfill the requirement for a disk shared between all cluster members—the same disk must be attached to all nodes via a controller with physical bus sharing.

❌ Option C (Raw Device Mapping):
Raw Device Mapping (RDM) is not a typical native vSAN configuration. For vSAN environments, shared VMDKs (Clustered VMDKs) are the native method, not RDMs . Additionally, the vSAN iSCSI target service explicitly does not support migrations using RDM .

❌ Option D (NFS v4.1):
NFS datastores are not supported for WSFC configurations. Multiple official sources list NFS datastores as an unsupported scenario for WSFC on vSphere . WSFC requires block-level storage with SCSI-3 Persistent Reservations, which NFS as a file-level protocol cannot provide.

🔧 Reference:
→ Broadcom KB 326884: Best practices for using vSAN iSCSI targets – Confirms vSAN iSCSI target supports Windows Server Failover Cluster (WSFC).
→ Broadcom TechDocs: Shared Storage Clusters on vSAN – Documents requirement for SCSI controller with Physical bus sharing for WSFC.

Explanation:

This question tests an administrator's knowledge of the operational tools and CLI utilities available to monitor and alert on external Network File System (NFS) datastore behavior within a VCF cluster. It requires selecting valid vSphere and command-line actions that accurately report latency, throughput, and capacity metrics for file-based principal or supplemental storage.

✅ Correct Option:

Run the esxcli storage nfs list command.
This option is correct because the esxcli storage nfs list command is a valid local ESXi shell utility. It allows an administrator to quickly view a list of currently mounted NFS volumes on a specific host along with their connection statuses and basic share details, serving as a baseline diagnostic action.

Use vCenter Datastore Performance view to monitor NFS datastore latency, IOPS and throughput.
This choice is correct because the native vCenter Server Performance tab provides complete real-time and historical graphical tracking for storage metrics. It allows administrators to closely inspect the input/output operations per second (IOPS), overall read/write throughput, and localized latency spikes specifically across any attached NFS datastores.

Create a vCenter performance alarm for "Datastore Latency (NFS)" to trigger when thresholds are exceeded.
This option is correct because setting proactive vCenter performance alarms is the industry-standard method for continuous infrastructure oversight. Configuring a specialized alarm targeting NFS datastore latency thresholds ensures the storage administration team is flagged immediately whenever performance metrics degrade past operational limits.

❌ Incorrect options:

Run the esxcli storage nfs list --verbose command to obtain detailed NFS latency and throughput data.
This command variation is invalid because the native ESXi CLI toolset does not feature a --verbose modifier for the esxcli storage nfs list namespace. Attempting to execute this syntax inside the shell returns a command error rather than providing deep latency or throughput telemetry.

Run the esxcli storage core device list command.
This action is incorrect because the esxcli storage core device list command is strictly designed to query and display properties for local or SAN block-based storage devices (such as SCSI LUNs, local SSDs, or NVMe paths). It does not track or map logical network shares or remote file systems like NFS.

Use VCF Operations Logs to analyze NFS throughput graphs.
This selection is inaccurate because VCF Operations (formerly vRealize Operations) visualizes structural metrics, trends, and throughput analytics using dashboards and structured performance graphs, not through text-based log streams. Log tracking is handled by Log Insight, which is separate from graph-based metrics analysis.

Use vSAN Performance Service to review NFS datastore latency.
This configuration step is incorrect because the vSAN Performance Service is architecturally restricted to tracking native vSAN storage components, objects, and disk groups. It cannot capture, process, or display performance telemetry or network latency measurements for an externally attached third-party NFS datastore.

🔧 Reference:
⇒ VMware vSphere Monitoring and Performance Guide
→ Confirms valid configuration paths for building performance alarms and using the native vCenter performance tracking charts to oversee file-system storage arrays.

Explanation:

This question tests the prerequisite for enabling vSAN Data Protection in VMware Cloud Foundation 9.0, which provides snapshot-based local protection and optional replication.

✅ Correct Option:

B. Deploy VMware Live Recovery (VLR)
vSAN Data Protection is powered by and integrated with the VMware Live Recovery appliance. Deploying the VLR OVA is the required action to activate the service, after which administrators can create protection groups for immutable snapshots and replication directly from the vSphere Client.

❌ Incorrect options:

A. Enable vSAN advanced options
Advanced options are not required to enable vSAN Data Protection. This feature operates through the dedicated Live Recovery service.

C. Deploy Data Services Manager
Data Services Manager is used for database-as-a-service capabilities and is unrelated to vSAN Data Protection.

D. Deploy vSphere Replication
vSphere Replication is a separate legacy replication tool. vSAN Data Protection uses its own integrated replication engine through VMware Live Recovery.

🔧 Reference:
→ Using vSAN Data Protection
Requires deployment of the VMware Live Recovery / Snapshot Service appliance.

→ vSAN Data Protection in VMware Cloud Foundation
Confirms deployment of the VMware Live Recovery appliance to enable the service.

Explanation:

This question tests your understanding of vSAN Data Protection (VMware Live Recovery) appliance registration troubleshooting. When the appliance fails to register with vCenter after deploying the OVA, the most common causes are DNS resolution issues (forward and reverse DNS must be properly configured) and insufficient user permissions for the account used during registration.

✔️ Option C (Correct):
The vCenter Server user account used for registration not having the required permissions is a valid cause because the Snapshot Service Appliance requires specific vCenter permissions to register and function properly. The account must have administrative privileges to register the appliance plugin with vCenter Server. If the user account lacks the necessary permissions (such as Global.Plugin, Storage.vsan, or Administrator roles), the registration process will fail even with correct network and DNS configuration. The authentication will fail silently or produce permission error messages, which is why checking the credentials and verifying proper role assignment is a critical troubleshooting step.

✔️ Option E (Correct):
Forward and reverse DNS resolution not being properly configured is a critical cause because the Snapshot Service Appliance requires proper A/PTR DNS records to register with vCenter Server. The appliance must resolve the vCenter FQDN correctly, and vCenter must be able to resolve the appliance's IP address back to its hostname. Without proper forward (A record) and reverse (PTR record) DNS resolution, the appliance cannot authenticate or communicate properly with vCenter Server. DNS replication delays can also cause this issue if DNS records haven't propagated to all DNS servers that vCenter queries.

❌ Option A (Incorrect):
Deploying the vSAN Data Protection appliance to a non-vSAN datastore is incorrect because while vSAN Data Protection provides protection for vSAN VMs, the appliance itself can be deployed to any accessible datastore (including non-vSAN datastores like NFS or VMFS). The appliance deployment location doesn't affect its ability to register with vCenter. The registration failure is typically caused by DNS or permission issues, not datastore type. The appliance manages vSAN snapshots regardless of where the appliance VM itself is deployed.

❌ Option B (Incorrect):
The vCenter Server user account being created locally on the VCSA Photon OS level is incorrect because this is not a typical cause of appliance registration failure. User accounts for vCenter authentication are managed through vCenter's Single Sign-On (SSO) identity sources (local users, Active Directory, LDAP), not directly at the Photon OS level. Even if technically possible to create a Photon OS user, it wouldn't be used for vCenter API authentication during appliance registration. Registration uses SSO credentials, making this option irrelevant to the actual authentication mechanism.

❌ Option D (Incorrect):
The appliance using DHCP IP addresses for management is incorrect because while static IP addresses are recommended for production appliances, using DHCP does not prevent the appliance from registering with vCenter Server. The registration process communicates over the network using whatever IP address (DHCP or static) the appliance has been assigned. DHCP assignment itself doesn't cause registration failures unless there are secondary issues like IP address changes or DNS not resolving the DHCP-assigned address. The primary causes are DNS records and permissions, not the IP addressing method.

🔧 Reference:
→ vSAN Data Protection Plugin Not Visible
Confirms that the issue occurs when vCenter FQDN configured during deployment does not resolve correctly from the appliance, requiring proper DNS resolution