DNS External Resolution TSG: quick-fix, full admin-surface discoverability, validator table#332
Conversation
…ility, validator table - Add a 'Quick fix (start here)' block: auto-identify the management adapter and give the exact reversible Set-DnsClientServerAddress command, gated by 'do not guess DNS servers', so the ~90% case is unblocked in one screen without reading the full decision tree first. - Add a 'Where it appears across the admin surfaces' subsection covering all eight admin surfaces (node PowerShell, event log, portal, on-disk result JSON = shown; Get-ClusterLog, Failover Cluster Manager, WAC standalone, WAC-in-portal = explicitly not evident), so admins do not hunt in the wrong place. - Add a validator metadata table (Name / Validator-test / Component / Severity) under the H1. No change to the diagnosis or remediation logic; documentation completeness and time-to-fix only.
There was a problem hiding this comment.
Pull request overview
Expands the external DNS resolution TSG to improve remediation speed and failure discoverability.
Changes:
- Adds validator metadata.
- Introduces a quick-fix PowerShell workflow.
- Documents visibility across eight administrative surfaces.
| # 1. Identify the management adapter (the up adapter holding the node's management IP) | ||
| $mgmt = (Get-NetIPConfiguration | Where-Object { $_.IPv4Address -and $_.NetAdapter.Status -eq 'Up' } | | ||
| Select-Object -First 1).InterfaceAlias | ||
| "Management adapter: $mgmt" |
There was a problem hiding this comment.
Fixed in b0b170e: the quick-fix now selects the management adapter by the node's known management IP and throws unless exactly one up adapter owns it, so enumeration order can no longer target a storage or other interface.
| Get-DnsClientServerAddress -InterfaceAlias $mgmt -AddressFamily IPv4 | ||
|
|
||
| # 3. Set the correct servers (replace with YOUR deployment's documented management DNS servers) | ||
| Set-DnsClientServerAddress -InterfaceAlias $mgmt -ServerAddresses '<dns1>','<dns2>' |
There was a problem hiding this comment.
Good catch, fixed in b0b170e. The node DNS-client change is now scoped to deployment / add-node only. An already-deployed cluster is explicitly told not to change the node DNS client (Azure Local does not support modifying DNS server settings post-deployment) and is directed to the supported upstream DNS/forwarder fix, with a link to Test-ManagementAdapterReadiness.
| Set-DnsClientServerAddress -InterfaceAlias $mgmt -ServerAddresses '<dns1>','<dns2>' | ||
|
|
||
| # 4. Confirm external resolution now works on this node | ||
| Resolve-DnsName -Name management.azure.com -Type A |
There was a problem hiding this comment.
Fixed in b0b170e: the verify step now queries every configured server with -Server (matching the validator's behavior), so a working default resolver can no longer mask another server that still returns zero records.
| | | | | ||
| |---|---| | ||
| | **Name** | `AzStackHci_DNS_ExternalDnsResolution` | | ||
| | **Validator / test** | `Invoke-AzStackHciDNSValidation -Include Test-ExternalDnsResolution` | | ||
| | **Component** | Environment Validator (DNS) | |
There was a problem hiding this comment.
Fixed in b0b170e: the metadata block is now the Troubleshoot-Template HTML <table> including Applicable Scenarios (Deployment, AddNode, Update) and Affected Versions (All versions), with Name/Validator retained as additional rows.
…elect, per-server verify, template table - Quick fix now distinguishes deployment/add-node (node DNS-client change OK) from an already-deployed cluster, where changing DNS servers is UNSUPPORTED post-deployment; deployed clusters are directed to the supported upstream DNS/forwarder fix. - Management adapter is selected by the node's known management IP and fails closed unless exactly one up adapter owns it (multihomed nodes: no enumeration-order guessing). - Verify step now queries every configured server with -Server, matching the validator, so a working default resolver cannot mask a still-failing server. - Metadata block converted to the Troubleshoot-Template HTML table with Applicable Scenarios and Affected Versions.
Summary
Documentation-completeness improvements to
TSG/EnvironmentValidator/Troubleshooting-DNS-External-DNS-Resolution.md. No change to the diagnosis or remediation logic — this makes the common fix faster to reach and rounds out where the failure is (and is not) visible.Changes
Set-DnsClientServerAddresscommand for the ~90% case (a node pointed at a DNS server that cannot resolve external names), gated by a bold "do not guess DNS server IP addresses" so a literal follower stays safe. Readers who need the full decision tree are pointed to Remediation.HealthCheckResultJSON are shown;Get-ClusterLog, Failover Cluster Manager, and Windows Admin Center (standalone and in-portal) are called out as not evident, so admins do not hunt in the wrong tool.Invoke-AzStackHciDNSValidation -Include Test-ExternalDnsResolution.Why
Testing