Vantaggi per la sicurezza

Introduzione: minacce e mitigazioni della sicurezza DNS

A causa della progettazione aperta e distribuita di Domain Name System e del suo utilizzo dello standard UDP (User Datagram Protocol), il DNS è vulnerabile a varie forme di attacco. I resolver DNS pubblici o "aperti" sono particolarmente a rischio, poiché non limitano i pacchetti in entrata a un set di indirizzi IP di origine consentiti. I problemi riguardano principalmente due tipi comuni di attacchi:

  • Attacchi di spoofing che portano all'avvelenamento della cache da DNS. Esistono diversi tipi di sfruttamento di spoofing e falsificazione del DNS, che mirano a reindirizzare gli utenti da siti legittimi a siti web dannosi. Tra questi sono chiamati i cosiddetti attacchi Kaminsky, in cui gli utenti malintenzionati assumono il controllo autoritativo di un'intera zona DNS.
  • Attacchi DoS (Denial of Service). Gli utenti malintenzionati possono lanciare attacchi DDoS contro i resolver stessi o dirottare i resolver per lanciare attacchi DoS su altri sistemi. Gli attacchi che utilizzano server DNS per lanciare attacchi DoS su altri sistemi sfruttando le grandi dimensioni dei record/risposte DNS sono noti come attacchi di amplificazione.

Ogni classe di attacco viene discussa più avanti.

Attacchi avvelenanti da cache

Esistono diverse varianti di attacchi di spoofing DNS che possono comportare il peering della cache, ma lo scenario generale è il seguente:

  1. L'utente malintenzionato invia a un resolver DNS di destinazione più query per un nome di dominio per cui il server non è autorevole, ed è improbabile che si trovi nella cache del server.
  2. Il resolver invia richieste ad altri server dei nomi (il cui indirizzo IP può anche prevedere l'utente malintenzionato).
  3. Nel frattempo, l'utente malintenzionato riempie il server della vittima con risposte falsificate che sembrano provenire dal server dei nomi delegato. Le risposte contengono record che risolvono il dominio richiesto in indirizzi IP controllati dall'utente malintenzionato. Potrebbero contenere record di risposte per il nome risolto o, peggio, potrebbero delegare ulteriormente l'autorità a un server dei nomi di proprietà dell'utente malintenzionato, in modo che assuma il controllo di un'intera zona.
  4. Se una delle risposte falsificate corrisponde alla richiesta del resolver (ad esempio per nome query, tipo, ID e porta sorgente del resolver) e viene ricevuta prima di una risposta dal server dei nomi originali, il resolver accetta la risposta contraffatta e la memorizza nella cache ed elimina la risposta autentica.
  5. Le risposte alle query future per il dominio o la zona compromessi vengono risolte con le risoluzioni DNS contraffatte dalla cache. Se l'utente malintenzionato ha specificato una durata di vita molto lunga sulla risposta contraffatta, i record contraffatti rimangono nella cache per il più a lungo possibile senza essere aggiornati.

Per un'eccellente introduzione agli attacchi di Kaminsky, consulta la guida illustrata alla vulnerabilità DNS di Kaminsky.

Attacchi DoS e amplificazione

I resolver DNS sono soggetti alle consuete minacce DoS che affliggono qualsiasi sistema in rete. Tuttavia, gli attacchi di amplificazione sono particolarmente preoccupanti perché i resolver DNS sono bersagli allettanti per gli utenti malintenzionati che sfruttano i resolver; le proporzioni grandi della risposta alla richiesta vengono richieste per ottenere una larghezza di banda senza costi aggiuntiva. I resolver che supportano EDNS0 (Extension Mechanisms for DNS) sono particolarmente vulnerabili a causa delle dimensioni dei pacchetti sostanzialmente più grandi che possono restituire.

In uno scenario di amplificazione, l'attacco procede nel seguente modo:

  1. L'utente malintenzionato invia query al server DNS della vittima tramite un indirizzo IP di origine falsificato. Le query possono essere inviate da un singolo sistema o da una rete di sistemi, utilizzando lo stesso indirizzo IP contraffatto. Le query sono per record che l'utente malintenzionato sa che genereranno risposte molto più lunghe, fino a diverse decine di volte1 le dimensioni delle query originali (da cui il nome "amplificazione").
  2. Il server della vittima invia le grandi risposte all'indirizzo IP di origine passate nelle richieste falsificate, sovraccaricando il sistema e causando una situazione DoS.

Mitigazioni

La soluzione standard a livello di sistema per le vulnerabilità DNS è DNSSEC. Tuttavia, finché non saranno implementati universalmente, i resolver DNS aperti dovranno adottare in modo indipendente alcune misure per mitigare le minacce note. Sono state proposte molte tecniche; consulta IETF RFC 5452: Misure per rendere il DNS più resiliente alle risposte contraffatte per una panoramica della maggior parte di queste. In Google Public DNS, abbiamo implementato e consigliamo i seguenti approcci:

  • Protezione del codice rispetto agli extra del buffer, in particolare il codice responsabile dell'analisi e della serializzazione dei messaggi DNS.
  • Esegui il provisioning eccessivo delle risorse della macchina per proteggerti dagli attacchi DoS diretti ai resolver. Poiché gli indirizzi IP possono essere falsificati per i malintenzionati, è impossibile bloccare le query in base all'indirizzo IP o alla subnet; l'unico modo efficace per gestire tali attacchi è assorbire il carico.
  • Implementare la verifica di validità di base dei pacchetti di risposta e della credibilità del server dei nomi, per evitare un semplice avvelenamento della cache. Si tratta di meccanismi standard e controlli di integrità che devono essere eseguiti da qualsiasi resolver conforme agli standard.
  • Aggiunta dell'entropia ai messaggi di richiesta, per ridurre le probabilità di attacchi di avvelenamento da spoofing/cache più sofisticati come gli attacchi di Kaminsky. Esistono molte tecniche consigliate per aggiungere l'entropia. Di seguito forniamo una panoramica dei vantaggi, delle limitazioni e delle difficoltà di ciascuna di queste tecniche e spieghiamo come le abbiamo implementate nel DNS pubblico di Google.
  • Rimozione delle query duplicate per combattere la probabilità di "attacchi di compleanno".
  • Richieste con limitazione di frequenza, per impedire attacchi DoS e amplificazione.
  • Monitoraggio del servizio per gli IP client che utilizzano la larghezza di banda massima e il più alto rapporto di dimensioni richiesta/risposta.

DNSSEC

Lo standard Domain Name Security Extensions (DNSSEC) è specificato in diverse RFC IEIE: 4033, 4034, 4035 e 5155.

I resolver che implementano gli attacchi di avvelenamento della cache dal contatore DNSSEC verificando l'autenticità delle risposte ricevute dai server dei nomi. Ogni zona DNS mantiene un set di coppie di chiavi private/pubbliche e per ogni record DNS viene generata e criptata una firma digitale univoca utilizzando la chiave privata. La chiave pubblica corrispondente viene quindi autenticata tramite una catena di attendibilità dalle chiavi appartenenti alle zone padre. I resolver conformi a DNSSEC rifiutano le risposte che non contengono le firme corrette. DNSSEC impedisce efficacemente che le risposte vengano manomesse, perché in pratica è impossibile falsificare le firme senza accedere alle chiavi private.

A partire da gennaio 2013, Google Public DNS supporta completamente DNSSEC. Accettiamo e inoltramo i messaggi in formato DNSSEC e convalidiamo le risposte per una corretta autenticazione. Consigliamo vivamente di fare lo stesso con altri risolutori.

Archiviamo anche le risposte NSEC come specificato in IETF RFC 8198: Aggressive Use of DNSSEC-Validated Cache. Questo può ridurre le query NXDOMAIN nei server dei nomi che implementano DNSSEC e utilizzano NSEC per le risposte negative.

Trasferimenti criptati lato client

Google Public DNS offre supporto per i protocolli di trasporto criptati, DNS su HTTPS e DNS su TLS. Questi protocolli impediscono le manomissioni, l'intercettazione e lo spoofing, migliorando notevolmente la privacy e la sicurezza tra un client e Google Public DNS. Completano DNSSEC per fornire ricerche DNS autenticate end-to-end.

Implementare il controllo di base della validità

Alcuni danni della cache DNS possono essere dovuti a errate corrispondenze non intenzionali e non necessariamente dannose tra richieste e risposte (ad esempio a causa di un server dei nomi configurato in modo errato, di un bug nel software DNS e così via). Come minimo, i resolver DNS dovrebbero effettuare controlli per verificare la credibilità e la pertinenza dei server dei nomi. Consigliamo (e implementa) tutte le seguenti difese:

  • Non impostare il bit ricorrente nelle richieste in uscita e segui sempre le catene di delega in modo esplicito. La disabilitazione del bit ricorrente assicura che il resolver operi in modalità iterativa in modo da eseguire query su ogni server dei nomi nella catena di delega in modo esplicito, anziché consentire a un altro server dei nomi di eseguire queste query per tuo conto.
  • Rifiutare i messaggi di risposta sospetti. Vedi di seguito per i dettagli di ciò che consideriamo "sospetto".
  • Non restituire i record A ai client in base ai glue record memorizzati nella cache delle richieste precedenti. Ad esempio, se ricevi una query client per ns1.example.com, devi risolvere nuovamente l'indirizzo, anziché inviare un record A basato su glue record memorizzati nella cache restituiti da un server dei nomi di dominio TLD .com.

Rifiuto di risposte che non soddisfano i criteri richiesti

Google Public DNS rifiuta tutti i seguenti elementi:

  • Risposte non analizzabili o con formato non corretto.
  • Risposte in cui i campi chiave non corrispondono ai campi corrispondenti nella richiesta. tra cui ID query, IP di origine, porta di origine, IP di destinazione o nome della query. Consulta RFC 5452, Sezione 3 per la descrizione completa del comportamento di spoofing DNS.
  • Record non pertinenti alla richiesta.
  • Record di risposte per i quali non possiamo ricostruire la catena CNAME.
  • Registri (nella risposta, autorità o sezioni aggiuntive) per i quali il server dei nomi responsabile non è credibile. Determiniamo la "credibilità" di un server dei nomi in base al suo posto nella catena di delega per un dato dominio. Google Public DNS memorizza nella cache le informazioni sulla catena di delega e verifichiamo ogni risposta in arrivo in base alle informazioni memorizzate nella cache per determinare la credibilità del server dei nomi rispondibili per la risposta a una determinata richiesta.

Aggiunta dell'entropia alle richieste

Nel momento in cui un resolver applica i controlli di integrità di base, un utente malintenzionato deve inondare il resolver della vittima nel tentativo di trovare una corrispondenza con l'ID query, la porta UDP (della richiesta), l'indirizzo IP (della risposta) e il nome della query originale prima che avvenga il server dei nomi legittimo.

Sfortunatamente, questo non è difficile da ottenere, poiché l'ID query univoco, l'ID query, ha una lunghezza di soli 16 bit (ad esempio per una possibilità di 1/65.536 di correggerlo). Anche gli altri campi sono limitati, pertanto il numero totale di combinazioni uniche è relativamente basso. Consulta il documento RFC 5452, Sezione 7 per un calcolo dei combinatori coinvolti.

Pertanto, la sfida consiste nell'aggiungere quanta entropia al pacchetto di richiesta possibile, all'interno del formato standard del messaggio DNS, per rendere più difficile per gli utenti malintenzionati associare correttamente una combinazione di campi valida all'interno della finestra di opportunità. Consigliamo e abbiamo implementato tutte le tecniche discusse nelle sezioni seguenti.

Alla luglio 2022, abbiamo presentato una revisione aggiornata delle tecniche qui menzionate alla conferenza DNS OARC 38. La presentazione include anche suggerimenti per gli operatori dei server dei nomi.

randomizzazione delle porte di origine

Come passaggio di base, non consentire mai ai pacchetti di richieste in uscita di utilizzare la porta UDP predefinita 53 o di utilizzare un algoritmo prevedibile per l'assegnazione di più porte (ad es. semplice incremento). Utilizza un intervallo di porte da 1024 a 65535 ampio come consentito nel tuo sistema e utilizza un generatore di numeri casuali affidabile per assegnare le porte. Ad esempio, Google Public DNS utilizza circa 15 bit per consentire circa 32.000 numeri di porta diversi.

Tieni presente che se il deployment dei tuoi server avviene tramite firewall, bilanciatori del carico o altri dispositivi che eseguono la traduzione degli indirizzi di rete (NAT), tali dispositivi potrebbero randomizzare le porte sui pacchetti in uscita. Assicurati di configurare i dispositivi NAT per disabilitare la randomizzazione delle porte.

Scelta casuale dei server dei nomi

Alcuni resolver, quando inviano richieste a server radice, TLD o altri server dei nomi, seleziona l'indirizzo IP del server dei nomi in base alla distanza più breve (latenza). Ti consigliamo di randomizzare gli indirizzi IP di destinazione per aggiungere entropia alle richieste in uscita. In Google Public DNS, scegliamo un server dei nomi in modo casuale tra i server dei nomi configurati per ciascuna zona, preferendo in qualche modo i server dei nomi veloci e affidabili.

Se hai dubbi sulla latenza, puoi utilizzare il banding trip-time time (RTT), che consiste nella randomizzazione in un intervallo di indirizzi che sono al di sotto di una determinata soglia di latenza (ad es. 30 ms, 300 ms e così via).

Cookie DNS

RFC 7873 definisce un'opzione EDNS0 per l'aggiunta di cookie a 64 bit ai messaggi DNS. Un client che supporta i cookie DNS include un cookie casuale a 64 bit e, facoltativamente, un cookie di server nella richiesta. Se un server di supporto trova l'opzione del cookie valida in una richiesta, riflette il cookie del client e il cookie corretto del server nella risposta. Il client di supporto può quindi verificare che la risposta provenga dal server previsto verificando il cookie del client nella risposta.

Se un server dei nomi non supporta i cookie DNS, le due opzioni seguenti possono essere utilizzate per aggiungere l'entropia.

Maiuscole/minuscole in nomi query

Gli standard DNS richiedono che i server dei nomi trattino i nomi con distinzione tra maiuscole e minuscole. Ad esempio, i nomi example.com e EXAMPLE.COM devono corrispondere allo stesso indirizzo IP2. Inoltre, tutti i server dei nomi tranne una piccola minoranza fanno eco al nome nella risposta, come mostrato nella richiesta, mantenendo il caso originale.

Pertanto, un altro modo per aggiungere entropia alle richieste è modificare in modo casuale il caso delle lettere nei nomi di dominio oggetto della query. Questa tecnica, nota anche come "0x20", poiché il bit 0x20 viene utilizzato per impostare il caso delle lettere US-ASCII, è stata proposta per la prima volta nella bozza Internet IETF Uso di Bit 0x20 nelle etichette DNS per migliorare l'identità delle transazioni. Con questa tecnica, la risposta del server dei nomi deve corrispondere non solo al nome della query, ma anche a ogni lettera nella stringa del nome, ad esempio wWw.eXaMpLe.CoM o WwW.ExamPLe.COm. Questo potrebbe aggiungere poca entropia alle query per i domini di primo livello e principali, ma è efficace per la maggior parte dei nomi host.

Una sfida significativa che abbiamo scoperto durante l'implementazione di questa tecnica è che alcuni server dei nomi non seguono il comportamento di risposta previsto:

  • Alcuni server dei nomi rispondono con una distinzione tra maiuscole e minuscole: restituiscono correttamente gli stessi risultati indipendentemente dal caso nella richiesta, ma la risposta non corrisponde esattamente al nome della richiesta.
  • Altri server dei nomi rispondono con una distinzione tra maiuscole e minuscole completa (in violazione degli standard DNS): gestiscono nomi equivalenti in modo diverso a seconda del caso nella richiesta, non rispondendo a tutti o restituiscono risposte NXDOMAIN errate che corrispondono esattamente al nome del nome nella richiesta.
  • Alcuni server dei nomi funzionano correttamente, ad eccezione delle query PTR nella zona arpa.

Per entrambi questi tipi di server dei nomi, la modifica del caso del nome query produrrebbe risultati indesiderati: per il primo gruppo, la risposta sarebbe indistinguibile da una risposta contraffatta; per il secondo gruppo, la risposta (se presente) potrebbe essere completamente errata.

La nostra soluzione attuale è utilizzare la randomizzazione dei casi solo per i server dei nomi che sappiamo che applicano gli standard correttamente. Elenchiamo inoltre i sottodomini di eccezione appropriati per ciascuno di essi, in base all'analisi dei nostri log. Se una risposta che sembra provenire da tali server non contiene la risposta corretta, viene rifiutata. I server dei nomi abilitati gestiscono più del 70% del nostro traffico in uscita.

Ritiro delle etichette nonce in base ai nomi delle query

Se un resolver non può risolvere direttamente un nome dalla cache o non può eseguire una query direttamente su un server dei nomi autorevole, deve seguire i referral da un server dei nomi root o TLD. Nella maggior parte dei casi, le richieste ai server dei nomi radice o TLD comporteranno un referral a un altro server dei nomi, anziché un tentativo di risolvere il nome in un indirizzo IP. Per tali richieste, quindi, dovrebbe essere sicuro associare un'etichetta casuale al nome di una query per aumentare l'entropia della richiesta, senza rischiare di non riuscire a risolvere un nome inesistente. In altre parole, l'invio di una richiesta a un server dei nomi referente per un nome preceduto da un'etichetta "nonce", ad esempio entriih-f10r3.www.google.com, dovrebbe restituire lo stesso risultato di una richiesta per www.google.com.

Sebbene nella pratica queste richieste rappresentino meno del 3% delle richieste in uscita, supponendo che il traffico sia normale (poiché la maggior parte delle query può rispondere direttamente dalla cache o da una singola query), questi sono esattamente i tipi di richieste che un attacco tenta di forzare un resolver. Di conseguenza, questa tecnica può essere molto efficace nel prevenire gli attacchi in stile Kaminsky.

L'implementazione di questa tecnica richiede che le etichette nonce vengano utilizzate solo per le richieste che hanno la garanzia di generare referral; in altre parole, le risposte che non contengono record nella sezione delle risposte. Tuttavia, abbiamo riscontrato diverse difficoltà nel tentativo di definire l'insieme di richieste di questo tipo:

  • Alcuni server dei nomi di domini di primo livello nazionali (ccTLD) sono in realtà autorevoli per altri TLD di secondo livello (2LD). Anche se hanno due etichette, i documenti 2LD si comportano come i TLD ed è per questo che vengono spesso gestiti dai server dei nomi ccTLD. Ad esempio, i server dei nomi .uk sono autoritativi anche per le zone mod.uk e nic.uk, quindi i nomi host contenuti in tali zone, come www.nic.uk, www.mod.uk e così via, In altre parole, le richieste ai server dei nomi ccTLD per la risoluzione di tali nomi host non genereranno referral, ma risposte autorevoli. L'aggiunta di etichette nonce a tali nomi host renderà irrisolvibili.
  • A volte i server dei nomi di dominio di primo livello generici (gTLD) restituiscono risposte non autorevoli per i server dei nomi. In altre parole, esistono nomi host di server dei nomi che si trovano in una zona gTLD anziché nella zona del loro dominio. Un gTLD restituisce una risposta non autorevole per questi nomi host, utilizzando qualsiasi glue record presente nel proprio database, anziché restituire un referral. Ad esempio, il server dei nomi ns3.indexonlineserver.com si trovava nella zona .COM gTLD anziché nella zona indexonlineserver.com. Quando abbiamo inviato una richiesta a un server gTLD n3.indexonlineserver.com, abbiamo ricevuto un indirizzo IP anziché un referral. Tuttavia, se anteponevamo un'etichetta nonce, abbiamo ricevuto un referral a indexonlineserver.com, che non è riuscito a risolvere il nome host. Pertanto, non possiamo aggiungere etichette nonce per i server dei nomi che richiedono una risoluzione da un server gTLD.
  • Le autorità per le zone e i nomi host cambiano nel tempo. Questo può causare un nome host senza privilegi che prima era risolvibile e diventava irrisolvibile se la catena di delega cambia.

Per affrontare queste sfide, abbiamo configurato le eccezioni per i nomi host per i quali non possiamo aggiungere etichette nonce. Questi sono nomi host per i quali i server dei nomi di dominio di primo livello restituiscono risposte non referral, in base ai nostri log del server. Esaminiamo continuamente l'elenco delle eccezioni per garantire che rimanga valido nel tempo.

Rimozione delle query duplicate

I resolver DNS sono vulnerabili agli "attacchi di compleanno", così chiamati perché sfruttano il paradosso di matematica, in cui la probabilità di una corrispondenza non richiede un numero elevato di input. Gli attacchi di compleanno includono inondazione del server della vittima non solo con le risposte contraffatte, ma anche con le query iniziali, facendo affidamento sul resolver per inviare più richieste per la risoluzione di un singolo nome. Maggiore è il numero di richieste in uscita inviate, maggiore è la probabilità che l'utente malintenzionato corrisponda a una di queste richieste con una risposta contraffatta: un utente malintenzionato ha bisogno solo dell'ordine di 300 richieste in corso per una probabilità di successo del 50% che corrisponde a una risposta contraffatta e 700 richieste per ottenere quasi il 100% di successo.

Per proteggerti da questa strategia di attacco, devi assicurarti di ignorare tutte le query duplicate dalla coda in uscita. Ad esempio, Google Public DNS non consente mai più di una singola richiesta in sospeso per lo stesso nome query, tipo di query e indirizzo IP di destinazione,

Query con limitazione di frequenza

La prevenzione degli attacchi di tipo denial of service pone diverse sfide specifiche per i resolver DNS ricorsivi aperti:

  • I resolver ricorsivi aperti sono obiettivi allettanti per lanciare attacchi di amplificazione. Sono server ad alta capacità e ad alta affidabilità e possono produrre risposte più grandi di un tipico server dei nomi autorevole, soprattutto se un attacco può inserire una risposta grande nella propria cache. Spetta a qualsiasi sviluppatore un servizio DNS aperto per impedire che i suoi server vengano utilizzati per lanciare attacchi su altri sistemi.
  • Gli attacchi di amplificazione possono essere difficili da rilevare mentre si verificano. Gli utenti malintenzionati possono lanciare un attacco tramite migliaia di resolver aperti, in modo che ogni risolutore veda solo una piccola parte del volume totale di query e non possa estrarre un chiaro segnale che sia stato compromesso.
  • Il traffico dannoso deve essere bloccato senza alcuna interruzione o riduzione del servizio DNS per gli utenti normali. Il DNS è un servizio di rete essenziale, quindi l'arresto dei server per bloccare un attacco non è un'opzione, né negare il servizio a un dato IP client per troppo tempo. I resolver devono essere in grado di bloccare rapidamente un attacco non appena inizia e di ripristinare il servizio pienamente operativo non appena termina l'attacco.

Il miglior approccio per combattere gli attacchi DoS è imporre un meccanismo di limitazione della frequenza o limitazione. Google Public DNS implementa due tipi di controllo delle tariffe:

  • Controllo della frequenza delle richieste in uscita verso altri server dei nomi. Per proteggere altri server dei nomi DNS dagli attacchi DoS che potrebbero essere avviati dai nostri server resolver, Google Public DNS applica limiti QPS sulle richieste in uscita da ogni cluster di gestione per ogni indirizzo IP del server dei nomi.

  • Controllo della frequenza delle risposte in uscita ai client. Per proteggere altri sistemi dall'amplificazione e dagli attacchi DoS (botnet) distribuiti in modo tradizionale che potrebbero essere avviati dai nostri server resolver, Google Public DNS esegue due tipi di limitazione della frequenza sulle query client:

    • Per proteggersi dagli attacchi tradizionali basati sul volume, ogni server impone QPS per IP client e limiti di larghezza di banda media.
    • Per proteggersi dagli attacchi di amplificazione, in cui vengono sfruttate grandi risposte a piccole query, ogni server applica un fattore di amplificazione medio per client IP. Il fattore di amplificazione medio è un rapporto configurabile di dimensioni della risposta alla query, determinato dai modelli di traffico storici osservati nei log del server.

    Se le query DNS da un indirizzo IP di origine superano la frequenza QPS massima, le query in eccesso verranno ignorate. Se le query DNS su UDP da un indirizzo IP di origine superano la larghezza di banda media o il limite di amplificazione in modo coerente (passerà occasionalmente la risposta grande), le query potrebbero essere ignorate o potrebbe essere inviata solo una risposta piccola. Può trattarsi di una risposta di errore o di una risposta vuota con il bit di troncamento impostato (in modo che la maggior parte delle query legittime venga riprovata tramite TCP e abbia esito positivo). Non tutti i sistemi o i programmi tenteranno di nuovo tramite TCP e il DNS su TCP potrebbe essere bloccato dai firewall lato client, quindi alcune applicazioni potrebbero non funzionare correttamente quando le risposte vengono troncate. Tuttavia, il troncamento consente ai client conformi alla RFC di funzionare correttamente nella maggior parte dei casi.

  1. Per un esempio, consulta l'articolo DNS Amplification Attacks e una buona discussione sul problema in generale.↩

  2. RFC 1034, la sezione 3.5 dice: ↩

    Tieni presente che, benché le lettere maiuscole e minuscole siano consentite nei nomi di dominio, non è collegata alcuna distinzione tra maiuscole e minuscole. In altre parole, due nomi con la stessa ortografia ma con un caso diverso devono essere trattati come identici.