Condividi tramite

Risolvere i problemi di risoluzione dei nomi client DNS

Questo articolo consente di risolvere i problemi di risoluzione dei nomi client DNS (Domain Name System).

I problemi di risoluzione DNS (Domain Name System) possono verificarsi per le tre cause principali seguenti:

  • Problemi o configurazioni del client DNS.
  • Problemi o configurazioni del server DNS.
  • Dispositivi o configurazioni intermedi tra un client DNS e un server DNS o tra un server DNS e resolver esterni (ad esempio hint radice, server d'inoltro e server d'inoltro condizionale), che potrebbero richiedere ulteriori indagini.

Note

Questo articolo è incentrato sui problemi di risoluzione DNS causati da problemi o configurazioni del client DNS. Per informazioni sui problemi del server DNS, vedere Risoluzione dei problemi relativi ai server DNS.

I problemi di risoluzione DNS possono verificarsi negli scenari seguenti:

Scenario 1: La regola del firewall blocca le connessioni in uscita sulla porta UDP 53

Si supponga che sia presente una regola del firewall in uscita che blocca le connessioni in uscita sulla porta UDP (User Datagram Protocol) 53.

In questo caso, quando si esegue il Resolve-DnsName contoso.com cmdlet di PowerShell con Wireshark in esecuzione, viene visualizzato l'errore seguente:

resolve-dnsname : contoso.com : This operation returned because the timeout period expired
At line:1 char:1
+ resolve-dnsname contoso.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationTimeout: (contoso.com:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : ERROR_TIMEOUT,Microsoft.DnsClient.Commands.ResolveDnsName

Quando si controlla la traccia wireshark, non è presente alcun traffico DNS in uscita verso il controller di dominio (DC).

In questo caso, esaminare le regole di Windows Firewall e controllare eventuali prodotti di sicurezza di terze parti per le eliminazioni di pacchetti sulla porta UDP o TCP (Transmission Control Protocol) 53.

Se si nota una richiesta di risoluzione DNS senza risposta, è utile raccogliere le tracce wireshark da un commutatore usando il mirroring delle porte per verificare che il pacchetto UDP DNS abbia lasciato il computer client. Le richieste sono simili alle seguenti:

139 3.149039    10.0.1.10   10.0.1.2    DNS 71  Standard query 0xcdc6 A contoso.com
140 3.149192    10.0.1.10   10.0.1.2    DNS 71  Standard query 0x8168 AAAA contoso.com

Si tratta di richieste di query standard per l'host A e l'host AAAA senza risposta. La verifica della traccia può isolare il problema. Se viene visualizzato il pacchetto UDP sul commutatore, significa che il pacchetto ha già lasciato il computer client e il problema è oltre il computer client.

Scenario 2: Esiste una voce per il nome di dominio nel file Hosts

Si supponga che il file Hosts che si trova in C:\Windows\System32\drivers\etc abbia una voce per il nome di dominio che si desidera risolvere. Ad esempio:

192.168.1.10 contoso.com

In questo caso, quando si risolve il nome contoso.com di dominio con Wireshark in esecuzione, viene visualizzato l'output seguente:

PS C:\Windows\System32\drivers\etc> Resolve-DnsName contoso.com

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
contoso.com                                    A      60440 Answer     192.168.1.10

Inoltre, non è possibile rilevare traffico in Wireshark.

Il motivo è che il client DNS usa la sequenza seguente per la risoluzione dei nomi:

  1. Controllare la cache.
  2. Controllare il file Hosts.
  3. Inviare la query al server DNS.

Poiché è presente una voce nel file Hosts, il servizio client DNS non esegue query sul server DNS.

Scenario 3: il client punta a un server DNS non corretto o non raggiungibile

Si supponga che il server DNS nella scheda di interfaccia di rete (NIC) del client DNS sia configurato con l'INDIRIZZO IP di un server DNS non raggiungibile. La configurazione IP client è simile all'esempio seguente:

IPv4 Address. . . . . . . . . . . : 10.0.1.10<Preferred>
Default Gateway . . . . . . . . . : 10.0.1.1
DNS Servers . . . . . . . . . . . : 192.168.0.1

Poiché il server DNS non è raggiungibile, il client non riceve una risposta, causando il timeout della query. Questo timeout può essere osservato in Wireshark. Query standard DNS senza risposta:

439 14.482923   10.0.1.10   192.168.0.1 DNS 71  Standard query 0xa384 A contoso.com
440 14.482923   10.0.1.10   192.168.0.1 DNS 71  Standard query 0x4fe0 AAAA contoso.com

In questo caso, quando si esegue il Resolve-DnsName contoso.com cmdlet di PowerShell, viene visualizzato l'output seguente:

PS C:\Windows\System32\drivers\etc> Resolve-DnsName contoso.com
Resolve-DnsName : contoso.com : This operation returned because the timeout period expired
At line:1 char:1
+ Resolve-DnsName contoso.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationTimeout: (contoso.com:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : ERROR_TIMEOUT,Microsoft.DnsClient.Commands.ResolveDnsName

Scenario 4: nella scheda di interfaccia di rete sono configurati diversi server DNS, alcuni dei quali non raggiungibili

Si supponga che le impostazioni DNS del client siano configurate con alcuni server DNS non raggiungibili come indicato di seguito:

DNS Servers . . . . . . . . . . . : 192.168.0.1
                                    172.16.1.1
                                    192.168.1.20
                                    10.0.1.2

In questo caso, quando si esegue una risoluzione DNS usando il Resolve-DnsName contoso.com cmdlet di PowerShell, tutti gli indirizzi del server DNS ad eccezione 10.0.1.2 di non sono raggiungibili.

Per impostazione predefinita, il client DNS inizierà a inviare questa query ai server DNS configurati in un ordine specifico e attenderà una risposta entro un periodo di tolleranza specifico.

Questo processo può essere visualizzato in Wireshark con il filtro dns.qry.name == contoso.com.

L'output di Wireshark mostra che il completamento della query richiede quasi quattro secondi. Dal punto di vista della rete, questa durata può essere lunga e potrebbe causare un timeout di alcune applicazioni.

30  03:56:58.634623 10.0.1.10   192.168.0.1  DNS 71  Standard query 0x9f32 A contoso.com
33  03:56:59.643171 10.0.1.10   172.16.1.1   DNS 71  Standard query 0x9f32 A contoso.com
38  03:57:02.646443 10.0.1.10   192.168.0.1  DNS 71  Standard query 0x9f32 A contoso.com
42  03:57:02.646556 10.0.1.10   172.16.1.1   DNS 71  Standard query 0x9f32 A contoso.com
43  03:57:02.646573 10.0.1.10   192.168.1.20 DNS 71  Standard query 0x9f32 A contoso.com
47  03:57:02.646684 10.0.1.10   10.0.1.2     DNS 71  Standard query 0x9f32 A contoso.com

Note

In questo scenario, l'uso nslookup di non è applicabile e avrà sempre esito negativo. Questo perché nslookup usa nslookup.exe per contattare solo il server DNS primario configurato, che in questo caso è 192.168.0.1.

Scenario 5: Elenco di ricerca suffisso DNS lungo

Si supponga che l'elenco di ricerca del suffisso DNS nel client DNS sia configurato come segue:

Note

contoso.com è il suffisso DNS corretto.

DNS Suffix Search List. . . . . . : microsoft.com
                                    ms.com
                                    azure.com
                                    ms.local
                                    contoso.local
                                    contoso.com

In questo caso, quando si esegue una risoluzione dei nomi usando il Resolve-DnsName internal cmdlet di PowerShell, il client DNS aggiungerà i suffissi DNS in ordine, causando potenzialmente ritardi se la query necessaria è inferiore all'elenco. Usando il filtro dns.qry.name contains internal in Wireshark, la query viene visualizzata come segue:

116 04:33:38.164251 10.0.1.10   10.0.1.2    DNS 82  Standard query 0xc557 A internal.microsoft.com
120 04:33:38.177186 10.0.1.10   10.0.1.2    DNS 75  Standard query 0x0a4b A internal.ms.com
124 04:33:38.453625 10.0.1.10   10.0.1.2    DNS 78  Standard query 0x4245 A internal.azure.com
128 04:33:38.466154 10.0.1.10   10.0.1.2    DNS 77  Standard query 0xfaca A internal.ms.local
131 04:33:38.471033 10.0.1.10   10.0.1.2    DNS 82  Standard query 0xa9d6 A internal.contoso.local
136 04:33:38.476248 10.0.1.10   10.0.1.2    DNS 80  Standard query 0x611f A internal.contoso.com

Note

Se è necessario testare una query specifica, è possibile aggiungere un punto finale (.) alla fine. Ad esempio, internal.contoso.com.

Misurare il tempo impiegato da una query di risoluzione DNS

Per misurare il tempo impiegato per il completamento di una query di risoluzione DNS, eseguire il cmdlet di PowerShell seguente:

Note

Un risultato inferiore a un secondo è considerato accettabile.

(Measure-Command {Resolve-DnsName -Name contoso.com -Server <IP Address> -DnsOnly}).TotalMilliseconds

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti