Wildcard DNS: sottodomini automatici e rischi

Questa guida approfondisce Wildcard DNS con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.

Che cosa significa

Un record esplicito ha precedenza sul wildcard. Il comportamento dipende dal punto della gerarchia in cui esiste il record e dagli altri nomi presenti.

Il web server deve comunque conoscere l’hostname richiesto. In caso contrario può mostrare un sito predefinito, un errore SSL o una pagina non prevista.

Come riconoscere il problema

• Qualsiasi sottodominio risolve.
• Sottodomini inventati mostrano il sito.
• Il certificato non copre il nome.
• Un record esplicito ha comportamento diverso.
• Cloudflare proxy non gestisce il wildcard come atteso.

Cause più frequenti

1. Wildcard troppo ampio

Tutti i nomi non definiti puntano alla stessa origine. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

2. Virtual host assente

Il server non instrada l’hostname. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

3. Certificato non wildcard

TLS non copre i sottodomini. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

4. Record esplicito

Un nome specifico sostituisce la risposta wildcard. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

5. Applicazione non valida host

Il software accetta hostname arbitrari. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

6. Cache o proxy

CDN e DNS possono avere limitazioni o configurazioni separate. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

Diagnosi passo per passo

1. Interroga un nome inventato. Verifica A, AAAA o CNAME. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
2. Controlla record espliciti. Individua eccezioni. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
3. Verifica certificato. Controlla SAN e wildcard. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
4. Controlla virtual host. Il server deve instradare solo host previsti. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
5. Testa applicazione. Evita host header injection e tenant inesistenti. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
6. Controlla CDN. Verifica proxy e certificati edge. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
7. Analizza email. Il wildcard DNS non crea MX o caselle. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.

Metodo sicuro di intervento

Prima di modificare la configurazione, registra lo stato iniziale: indirizzo o funzione coinvolta, messaggio completo, data e ora, ultima modifica nota e risultato da un secondo dispositivo, rete o strumento. Una diagnosi ripetibile è più utile di molti tentativi eseguiti contemporaneamente.

Applica una sola correzione alla volta e conserva una copia dei file, dei record o dei valori precedenti. Dopo ogni intervento ripeti esattamente il test originale e controlla i log relativi allo stesso intervallo temporale. Se il risultato cambia, annota quale modifica lo ha prodotto.

Evita disattivazioni globali di firewall, WAF, TLS, cache o sistemi di sicurezza. Quando serve una eccezione, deve essere limitata all’URL, al parametro, al processo o al servizio realmente interessato.

Procedura di risoluzione

1. Limita il wildcard al livello necessario. Per esempio `*.app.example.com`. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
2. Crea record espliciti. Per servizi con destinazioni differenti. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
3. Configura routing host. Rifiuta hostname non validi. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
4. Installa certificato adeguato. Wildcard o certificati dinamici con controllo. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
5. Configura CDN. Aggiungi hostname e SSL secondo il provider. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
6. Monitora sottodomini inattesi. Controlla log e traffico. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
7. Rimuovi il wildcard se non serve. Riduce ambiguità e superficie. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.

Controlli finali

• Nome previsto funziona.
• Nome non autorizzato è rifiutato.
• Certificato valido.
• Record espliciti prevalgono.
• Nessun servizio email implicito.

Prevenzione

• Usa scope ristretto.
• Valida Host.
• Documenta eccezioni.
• Monitora log.
• Rimuovi wildcard inutili.

Errori da evitare

• Non usare wildcard per nascondere record mancanti.
• Non presumere che crei siti.
• Non accettare ogni hostname nell’applicazione.
• Non dimenticare SSL.
• Non applicarlo al dominio principale senza necessità.

Come documentare la verifica

Conserva una breve nota con configurazione iniziale, risultato di ogni controllo e modifica applicata. Inserisci sempre data e ora, perché cache, log, code, rate limit e processi pianificati possono cambiare nel tempo. Questa documentazione facilita il rollback e permette all’assistenza di evitare verifiche già eseguite.

Quando confronti due test, usa le stesse condizioni: stesso URL o destinatario, stesso file, stesso client e stessa rete quando possibile. Se cambi più variabili, il risultato non permette di individuare con certezza la causa.

Controllo incrociato

Dopo la correzione esegui almeno un controllo indipendente. Per un sito confronta browser, risposta HTTP e log; per DNS interroga autoritativo e resolver pubblico; per la posta confronta Webmail, intestazioni e Track Delivery; per PHP verifica il valore effettivamente applicato al dominio. Un solo indicatore può essere influenzato da cache o configurazioni locali.

Se il problema ricompare, evita ulteriori modifiche e raccogli nuovamente i dati. La ricorrenza può indicare un processo pianificato, un limite raggiunto, una dipendenza esterna o una configurazione che viene rigenerata automaticamente.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:

• nome wildcard
• esempio hostname
• record DNS
• certificato
• routing server

Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.

Fonti tecniche ufficiali

• IETF RFC 4592: DNS Wildcards
• Cloudflare wildcard records

Domande frequenti su Wildcard DNS