Il DNS non è una semplice traduzione da hostname a indirizzo IP
Per anni, molte applicazioni .NET hanno trattato la risoluzione DNS come un'operazione elementare: chiamare Dns.GetHostAddressesAsync(), ottenere uno o più indirizzi e lasciare al sistema operativo il resto. In un'applicazione distribuita moderna questa astrazione è insufficiente per diagnosticare failover, errori intermittenti, divergenze tra resolver e connessioni HTTP persistenti.
.NET 11 introduce due tasselli complementari: API DNS tipizzate in System.Net e una politica programmabile di eliminazione delle connessioni nel pool di SocketsHttpHandler. Non sono la stessa funzionalità: la prima osserva la risoluzione, la seconda influenza il riutilizzo delle connessioni.
Stato al 12 ottobre 2026: .NET 11 è ancora prerelease. Le API e i dettagli di comportamento vanno ricontrollati prima della release stabile. Gli esempi qui riportati si basano sulle API documentate da Microsoft; dove indicato, il codice è uno scheletro architetturale e non una libreria pronta per la produzione.
1. Il problema reale: tre stati che possono divergere
Authoritative DNS Zone
|
v
Recursive Resolver / Cache
|
v
Application DNS Lookup
|
v
HttpClient Connection Pool
|
v
Established TCP/TLS Connection
|
v
Remote ServiceIl record pubblicato dal DNS autorevole non coincide necessariamente con la risposta osservata da un resolver ricorsivo. E la risposta del resolver non coincide necessariamente con l'indirizzo remoto di una connessione TCP/TLS già aperta. Il DNS risolve nomi; non interrompe le connessioni esistenti.
Questo è cruciale per Azure, servizi dietro bilanciatori, ArcGIS Enterprise, API distribuite e ambienti con DNS privati. Un cambiamento di record può essere normale, ma può anche spiegare un degrado se coincide con errori applicativi. La correlazione temporale non è però una prova di causalità.
2. Cosa cambia in System.Net.Dns
Le nuove API comprendono ResolveAddresses, ResolveSrv, ResolveMx, ResolveTxt, ResolveCName, ResolvePtr e ResolveNs, insieme alle varianti asincrone. Il risultato è tipizzato come DnsResult<T>.
| API | Record | Scenario |
|---|---|---|
ResolveAddressesAsync | A / AAAA | Risoluzione degli endpoint IPv4/IPv6 |
ResolveCNameAsync | CNAME | Alias e dipendenze di naming |
ResolveSrvAsync | SRV | Service discovery con porta, priorità e peso |
ResolveMxAsync | MX | Routing della posta |
ResolveTxtAsync | TXT | Record testuali, configurazioni e verifiche |
ResolvePtrAsync | PTR | Reverse lookup |
ResolveNsAsync | NS | Deleghe e name server |
Il vantaggio non è soltanto evitare parsing manuale. È ottenere una rappresentazione del risultato DNS con informazioni sullo stato della risposta, che consente diagnosi più accurate rispetto al semplice successo/fallimento di GetHostAddressesAsync.
3. DnsResult<T>: distinguere risposta, record e cache negativa
Microsoft documenta tre informazioni chiave: Records, ResponseCode e NegativeCacheTtl. Questo permette di distinguere almeno tre condizioni: risposta senza errori con record; risposta senza errori ma senza record del tipo richiesto; risposta DNS negativa o con errore.
using System.Net;
DnsResult<SrvRecord> result =
await Dns.ResolveSrvAsync("_ldap._tcp.example.com");
if (result.ResponseCode == DnsResponseCode.NoError)
{
if (result.Records.Count == 0)
{
Console.WriteLine("Nessun record SRV restituito.");
}
else
{
foreach (SrvRecord record in result.Records)
{
Console.WriteLine(
$"{record.Target}:{record.Port} " +
$"priority={record.Priority} weight={record.Weight}");
}
}
}
else
{
Console.WriteLine($"DNS response: {result.ResponseCode}");
}
Il codice riprende la superficie pubblica mostrata nelle release notes Microsoft. Un monitor non dovrebbe considerare automaticamente un risultato vuoto come errore infrastrutturale: potrebbe non esistere alcun record di quel tipo per il nome interrogato.
4. Negative caching: il dettaglio che cambia la diagnostica
Quando un nome non esiste, o non è disponibile il tipo di record richiesto, un resolver può conservare temporaneamente una risposta negativa. Il caching negativo è descritto dal protocollo DNS e impedisce di ripetere continuamente interrogazioni inutili.
NegativeCacheTtl espone metadati relativi a questa durata. Non va confuso con il TTL dei record positivi né interpretato come una promessa assoluta del tempo di propagazione globale. Cache del sistema operativo, resolver intermedi, policy locali e comportamento dei client possono introdurre differenze.
Un alerting engine dovrebbe perciò distinguere:
- NXDOMAIN persistente;
- assenza del record richiesto con nome esistente;
- errore temporaneo del resolver;
- timeout di rete;
- risposta positiva che cambia nel tempo.
Una classificazione grossolana in Up / Down perde informazioni diagnostiche essenziali.
5. DnsResolver: query verso server DNS specifici
Il nuovo DnsResolver, configurato tramite DnsResolverOptions, introduce un modello a istanza e la possibilità di utilizzare una lista di server DNS personalizzati anziché affidarsi esclusivamente alla configurazione del sistema.
Questo cambia il modo in cui si può progettare un monitor. Per lo stesso hostname è possibile confrontare la prospettiva del resolver aziendale, di un resolver pubblico e di un resolver raggiungibile da una rete Azure, purché tali interrogazioni siano consentite dalla rete e dalla policy di sicurezza.
Hostname: gis.example.com
|
+--------+---------+
| | |
v v v
Resolver A Resolver B Resolver C
| | |
v v v
A/AAAA A/AAAA A/AAAA
| | |
+--------+---------+
|
v
Compare Answer SetsAttenzione: due resolver che restituiscono IP differenti non sono necessariamente incoerenti. GeoDNS, CDN, split-horizon DNS, round-robin e bilanciamento geografico possono produrre risposte diverse per scelta progettuale. Serve una policy per endpoint, non una regola universale di uguaglianza.
Secondo la documentazione Microsoft aggiornata a settembre 2026, le API di risoluzione tipizzata e DnsResolver supportano Windows, Linux e macOS. Le note iniziali della Preview 7 descrivevano invece un'implementazione inizialmente Windows-only: è un esempio concreto del perché occorre leggere lo stato più recente della documentazione prerelease.
6. DNS TTL, cache e misurazione della latenza: tre trappole
Primo: il TTL osservato in una risposta ricorsiva può essere il tempo residuo della cache, non quello originariamente pubblicato dalla zona autorevole.
Secondo: una query completata in un millisecondo potrebbe aver utilizzato una cache locale; non prova che il server autorevole sia raggiungibile in un millisecondo.
Terzo: il tempo della query DNS non misura il tempo di connessione TCP, l'handshake TLS o la latenza HTTP. Questi indicatori vanno raccolti e rappresentati separatamente.
Per un monitor di qualità, i risultati dovrebbero contenere almeno timestamp UTC, identificativo della probe, resolver utilizzato, tipo di record, durata osservata, codice di risposta, record normalizzati e classificazione dell'errore.
7. DNS e HttpClient: perché PooledConnectionLifetime non basta a spiegare tutto
HttpClient utilizza connessioni persistenti per ridurre handshake e overhead. Se il DNS cambia, una connessione già stabilita può continuare a servire richieste verso il precedente indirizzo remoto.
Per questo Microsoft raccomanda da tempo di gestire la durata delle connessioni, per esempio con PooledConnectionLifetime. Ma una durata fissa ricicla connessioni anche quando il DNS non è cambiato.
var handler = new SocketsHttpHandler
{
PooledConnectionLifetime = TimeSpan.FromMinutes(5)
};
using var client = new HttpClient(handler);
Questa è una strategia semplice, consolidata e generalmente prevedibile. Non è però equivalente a una politica DNS-aware.
8. .NET 11: ShouldEvictConnection
SocketsHttpHandler.ShouldEvictConnection introduce un callback asincrono per decidere se una connessione del pool debba essere ritirata. Il contesto include, fra le altre proprietà, età della connessione, endpoint DNS, endpoint remoto, versione HTTP e identificativo della connessione.
Microsoft presenta un esempio che controlla se l'indirizzo IP della connessione sia ancora presente fra quelli restituiti dal DNS:
using System.Net;
var handler = new SocketsHttpHandler
{
PooledConnectionLifetime = Timeout.InfiniteTimeSpan,
ShouldEvictConnection = async (context, ct) =>
{
if (context.RemoteEndPoint is IPEndPoint connectionIp)
{
var addresses = await Dns.GetHostAddressesAsync(
context.DnsEndPoint.Host,
connectionIp.AddressFamily,
ct);
return !addresses.Contains(connectionIp.Address);
}
return context.Age > TimeSpan.FromMinutes(10);
}
};
È un esempio didattico, non una configurazione che adotterei automaticamente in produzione. Eseguire una risoluzione DNS all'interno di una decisione di eviction può aumentare lavoro e latenza; bisogna comprendere frequenza di invocazione, timeout, eccezioni, cache e possibili oscillazioni delle risposte.
Inoltre la proprietà è stata introdotta come sperimentale nelle release notes della Preview 7. Occorre verificare gli attributi e le eventuali diagnostiche del compilatore nella build di SDK effettivamente utilizzata.
9. Progettare una policy DNS-aware senza creare un nuovo problema
Un approccio robusto dovrebbe evitare interrogazioni ripetitive verso il DNS a ogni decisione del pool. Una possibile architettura applicativa prevede un servizio separato che mantiene snapshot DNS periodici, con TTL e limiti di aggiornamento, e una policy di eviction che legge uno snapshot immutabile.
DNS Poller --> Immutable DNS Snapshot
|
v
Eviction Policy
|
v
Connection Pool
Questa è una proposta di design: non è un comportamento automatico del runtime. La policy deve gestire il caso in cui lo snapshot sia vecchio, non disponibile o temporaneamente vuoto. Evitare che un errore DNS transitorio provochi l'eliminazione massiva di connessioni ancora sane è spesso più importante che reagire immediatamente a ogni variazione.
Una politica ragionevole potrebbe prevedere: tempo minimo di permanenza, snapshot validi, più osservazioni consecutive, limiti alla frequenza di eviction e fallback a una durata massima fissa. I parametri vanno misurati con benchmark e fault injection.
10. A/AAAA e IPv6: il risultato DNS non determina da solo la connessione
Quando un hostname dispone di record IPv4 e IPv6, il sistema può scegliere l'indirizzo remoto secondo policy di rete e strategie di connessione. Un monitor che verifica soltanto A può risultare verde mentre i client IPv6 incontrano problemi, o viceversa.
Conviene conservare distintamente gli insiemi A e AAAA e, quando si monitorano le connessioni HTTP, osservare l'effettivo RemoteEndPoint. L'ordine degli indirizzi nella risposta DNS non va considerato un identificatore stabile della configurazione.
11. CNAME: non confondere alias e indirizzi finali
Una catena di CNAME può essere parte della configurazione normale di servizi cloud. Monitorare l'alias è utile per diagnosticare errori di configurazione, ma non bisogna presumere che ogni nome esponga sempre un record CNAME esplicito. Alcuni provider utilizzano record sintetizzati, alias proprietari o risposte che dipendono dal resolver.
Un buon monitor distingue il nome richiesto, gli eventuali alias osservati e l'insieme finale degli indirizzi. In presenza di variazioni, registra gli eventi senza classificarli automaticamente come incidenti.
12. SRV: service discovery, priority e weight
I record SRV sono interessanti perché includono un endpoint di servizio e non soltanto un nome host. Ogni record può specificare target, porta, priorità e peso.
La priorità più bassa viene preferita; il peso contribuisce alla selezione tra record della stessa priorità secondo le regole del protocollo. Un client non dovrebbe trattare l'elenco come un semplice array ordinato di server equivalenti.
Un monitor può verificare che i target siano risolvibili e che le porte siano raggiungibili, ma deve distinguere la validità del record DNS dalla disponibilità effettiva del servizio pubblicato.
13. MX, TXT, NS e PTR: non soltanto endpoint web
MX: permette di osservare variazioni dei server di posta e delle preferenze; non dimostra che SMTP funzioni.
TXT: utile per verificare la presenza di configurazioni testuali attese. Non ogni stringa TXT è un record SPF o una configurazione di sicurezza.
NS: utile per analizzare deleghe e modifiche dei name server; la diagnosi completa delle deleghe può richiedere query iterative e verifiche della catena DNS.
PTR: associa indirizzi a nomi in reverse DNS; la sua presenza non dimostra automaticamente l'identità o l'affidabilità di un host.
14. Diagnostica: NXDOMAIN, NODATA, SERVFAIL e timeout
Un monitor DNS serio deve distinguere le risposte del protocollo dalle eccezioni di trasporto. Un nome inesistente, un record mancante, un errore del resolver e un timeout non descrivono lo stesso incidente.
| Condizione | Interpretazione operativa |
|---|---|
| Risposta positiva | Record ricevuti, senza garanzia sulla raggiungibilità applicativa |
| Risposta senza record del tipo richiesto | Possibile configurazione normale o record mancante |
| NXDOMAIN | Nome inesistente nella vista DNS interrogata |
| SERVFAIL | Il resolver non è riuscito a completare la risoluzione |
| Timeout | Assenza di risposta nei limiti configurati |
| Risposte divergenti | Possibile GeoDNS, split-horizon, cache o problema da indagare |
Non assocerei mai automaticamente NXDOMAIN a un errore HTTP 404: il primo riguarda il DNS, il secondo è una risposta di un server HTTP raggiunto con successo.
15. Un laboratorio riproducibile: la baseline compatibile con .NET 10
Prima di sperimentare le nuove API, è utile costruire una baseline con API consolidate. Questo esempio misura la durata osservata della risoluzione A/AAAA attraverso il resolver di sistema, senza pretendere di misurare il tempo del server autorevole.
dotnet new console -n DnsBaseline -f net10.0
cd DnsBaselineusing System.Diagnostics;
using System.Net;
using System.Net.Sockets;
string hostname = args.Length > 0
? args[0]
: "example.com";
using var cts = new CancellationTokenSource(
TimeSpan.FromSeconds(5));
var sw = Stopwatch.StartNew();
try
{
IPAddress[] addresses =
await Dns.GetHostAddressesAsync(hostname, cts.Token);
sw.Stop();
var normalized = addresses
.Distinct()
.OrderBy(ip => ip.AddressFamily)
.ThenBy(ip => ip.ToString(), StringComparer.Ordinal)
.ToArray();
Console.WriteLine($"Host: {hostname}");
Console.WriteLine($"Elapsed: {sw.Elapsed.TotalMilliseconds:F2} ms");
foreach (IPAddress address in normalized)
{
string family = address.AddressFamily ==
AddressFamily.InterNetwork ? "A" : "AAAA";
Console.WriteLine($"{family}: {address}");
}
}
catch (OperationCanceledException)
{
Console.Error.WriteLine("DNS lookup timed out/cancelled.");
}
catch (SocketException ex)
{
Console.Error.WriteLine(
$"DNS lookup failed: {ex.SocketErrorCode}");
}
La baseline è intenzionalmente semplice. Non espone il DNS response code completo, la cache negativa, il resolver interrogato né i record SRV/MX/TXT. È proprio questa lacuna che le API .NET 11 iniziano a colmare.
16. Laboratorio .NET 11: record SRV e classificazione
Con un SDK .NET 11 prerelease installato, il seguente frammento illustra l'uso delle API tipizzate:
using System.Net;
string service = "_ldap._tcp.example.com";
DnsResult<SrvRecord> response =
await Dns.ResolveSrvAsync(service);
Console.WriteLine($"Response: {response.ResponseCode}");
Console.WriteLine($"Records: {response.Records.Count}");
foreach (SrvRecord srv in response.Records)
{
Console.WriteLine(
$"target={srv.Target} port={srv.Port} " +
$"priority={srv.Priority} weight={srv.Weight}");
}
Per una prova reale è necessario utilizzare un nome SRV effettivamente pubblicato nell'ambiente di test. La stringa example.com è illustrativa e non implica l'esistenza del servizio LDAP.
Una suite completa dovrebbe includere query separate per record A/AAAA, CNAME, MX, TXT, PTR e NS, raccogliendo gli stessi campi diagnostici in un formato comune.
17. Benchmark: non misurare soltanto la media
Un benchmark DNS affidabile dovrebbe separare query cold e warm, distinguere cache locale e remota, confrontare più resolver e misurare percentili di latenza. La sola media può nascondere code molto lunghe.
Metriche suggerite: dns_lookup_duration_ms (p50/p95/p99), dns_lookup_failures_total per classificazione, dns_answer_set_changes_total, dns_negative_responses_total e dns_resolver_disagreement_total.
Non utilizzare il nome host grezzo come label ad alta cardinalità in un sistema multi-tenant: una crescita incontrollata delle serie temporali può diventare più costosa del monitoraggio stesso. Usare identificativi di monitor stabili e metadata separati.
18. Fault injection: testare la diagnosi prima dell'incidente
Un laboratorio avanzato dovrebbe includere un resolver DNS di test controllato, ad esempio in un ambiente isolato, capace di rispondere con:
- un set A/AAAA stabile;
- un cambio di IP dopo un intervallo definito;
- NXDOMAIN;
- SERVFAIL;
- risposte ritardate;
- record multipli e rotazione dell'ordine;
- TTL differenti.
Il client HTTP dovrebbe essere testato separatamente con un server raggiungibile ai diversi indirizzi, in modo da distinguere cambio DNS, errore di connessione, handshake TLS e risposta HTTP. Non è sufficiente cambiare un record e osservare che il client prima o poi raggiunge un altro server: occorre misurare tempi di convergenza e richieste fallite.
19. Da availability check a DNS observability: architettura di un servizio enterprise
Un sistema di osservabilità può integrare un DNS Health Check come controllo autonomo, mantenendo separati i monitor HTTP e TLS. Questo permette di diagnosticare le cause dei problemi senza confondere la risoluzione dei nomi con la disponibilità applicativa.
Monitoring Scheduler
|
+-- HTTP Monitor
|
+-- TLS Certificate Monitor
|
+-- DNS Monitor
|
+-- A / AAAA
+-- CNAME / SRV / MX / TXT / NS / PTR
+-- Resolver Comparison
+-- Answer Set History
+-- Response Classification
|
v
Correlation / Alert Engine
|
v
Dashboard + NotificationsIl monitor dovrebbe registrare la prospettiva di ciascuna probe. Un resolver interno Azure può restituire indirizzi privati dove un resolver pubblico restituisce indirizzi pubblici o nessuna risposta. Questo può essere un comportamento corretto in presenza di Private Endpoint e Private DNS Zone.
La correlazione DNS/HTTP deve restare diagnostica. Non è opportuno forzare HttpClient a utilizzare gli IP raccolti dal monitor DNS: ciò altererebbe il normale percorso di risoluzione, la selezione degli endpoint e potenzialmente le garanzie TLS.
20. Schema dati proposto per il monitor
{
"monitorId": "api-production-dns",
"hostname": "api.example.com",
"recordType": "A",
"probeId": "azure-italynorth-01",
"resolverProfile": "system",
"timestampUtc": "2026-10-12T08:00:00Z",
"durationMs": 13.4,
"responseClass": "Positive",
"answers": ["192.0.2.10", "192.0.2.11"],
"answerSetChanged": false,
"status": "Healthy"
}Gli indirizzi 192.0.2.0/24 appartengono allo spazio riservato agli esempi documentali. Il JSON è una proposta di contratto applicativo, non un formato nativo di .NET 11.
Le modifiche del set di indirizzi devono essere confrontate come insiemi normalizzati, non come stringhe concatenate nell'ordine ricevuto. Per servizi con GeoDNS o CDN conviene introdurre una modalità di baseline dinamica, per evitare falsi positivi.
21. Alerting: distinguere change event e incident
Un cambio IP è un evento; un servizio non raggiungibile è un possibile incidente. Non devono essere sinonimi.
Una classificazione operativa può prevedere tre livelli:
- Informational: variazione dell'answer set, nuovo CNAME, modifica del TTL osservato.
- Warning: divergenza persistente rispetto a una policy esplicita, aumento del p95, errori intermittenti.
- Critical: impossibilità persistente di risolvere un nome essenziale, confermata da più campioni e correlata a fallimenti del servizio.
Le soglie vanno parametrizzate per monitor e ambiente. Un nome interno risolvibile soltanto nella VNet non dovrebbe essere considerato guasto perché non si risolve da Internet.
22. Sicurezza: un DNS monitor può diventare uno strumento di scansione
Se un servizio di monitoraggio accetta hostname e resolver arbitrari, occorre evitare che utenti non autorizzati possano utilizzarlo per enumerare reti interne, interrogare server riservati o generare carico verso infrastrutture DNS.
Le contromisure comprendono validazione degli hostname, policy di autorizzazione per i resolver, limiti di frequenza, timeout, limiti di concorrenza, audit log e separazione delle probe per rete/tenant. Non assumere che un hostname innocuo rimanga sempre associato agli stessi IP.
23. Strategia di adozione: non migrare a .NET 11 soltanto per il DNS
Questa è la distinzione più importante dal punto di vista architetturale. Una nuova API di runtime non impone automaticamente l'aggiornamento dell'intera applicazione.
Per un sistema in esecuzione su una versione LTS stabile, è consigliabile definire un'astrazione IDnsProbe con implementazione compatibile con il runtime corrente e un adapter opzionale specifico per .NET 11. L'adozione della versione prerelease dovrebbe rimanere confinata al laboratorio.
La funzionalità può essere progettata oggi con contratti stabili e test indipendenti dal provider DNS. Quando .NET 11 sarà stabile, sarà possibile valutare se le nuove API riducono davvero dipendenze, codice e complessità operativa.
24. Checklist per un DNS Health Monitor enterprise
- Distinguere resolver di sistema e resolver esplicito.
- Registrare record A e AAAA separatamente.
- Gestire NXDOMAIN, NODATA, SERVFAIL, timeout ed errori locali.
- Separare TTL positivo e negative caching.
- Conservare lo storico degli answer set normalizzati.
- Identificare probe e rete di provenienza.
- Misurare p50, p95 e p99 senza creare cardinalità incontrollata.
- Non generare alert critici per ogni cambio IP.
- Non sostituire il controllo HTTP con il controllo DNS.
- Testare failover, split-horizon e Azure Private DNS.
- Proteggere i resolver configurabili da abusi.
- Verificare API e attributi sperimentali prima della release stabile.
Conclusioni: DNS-aware non significa automaticamente resilient
.NET 11 migliora l'osservabilità del DNS e rende più espressiva la gestione delle connessioni HTTP. Ma un sistema resiliente non nasce da una singola API. Nasce da politiche di cache, controllo delle dipendenze, gestione dei fallimenti, osservabilità e test riproducibili.
L'obiettivo di un sistema DNS-aware non è mostrare semplicemente l'indirizzo IP risolto, ma ricostruire la storia di un incidente: quale resolver ha risposto, quali record erano visibili, quali connessioni HTTP erano in uso e quando sono comparsi gli errori.
Il DNS dice dove un servizio dovrebbe essere raggiungibile. Il connection pool rivela dove il client è ancora connesso. L'observability deve raccontare la differenza.
