Delegare un sottodominio a un provider DNS esterno (DNS Made Easy)

questo articolo è basato sulla guida ufficiale DME e rivisitato con il supporto dell’AI

---

In scenari reali (microservizi, CDN, SaaS, ambienti separati), è spesso necessario delegare la gestione DNS di un sottodominio a un provider differente rispetto al dominio principale.

Questa guida mostra come effettuare una delegazione DNS di sottodominio tramite record NS su DNS Made Easy, mantenendo il pieno controllo del dominio root.

---

Contesto e use case

Delegare un sottodominio significa rendere un’altra infrastruttura DNS autoritativa per una specifica zona.

Esempio:

• Dominio principale: example.com (gestito su DNS Made Easy)
• Sottodominio delegato: api.example.com (gestito su altro provider)

Quando usarlo

• Separazione ambienti (dev, staging, prod)
• Delega a team diversi
• Integrazione con provider esterni (es. CDN, email, SaaS)
• Migrazione progressiva DNS (zero downtime)

---

Prerequisiti

• Zona DNS attiva su DNS Made Easy
• Lista nameserver del provider target (minimo 2)
• Accesso al provider DNS esterno

Verifica preliminare

Controlla l’assenza di wildcard:

dig *.example.com

Un record wildcard (*) può interferire con la delega.

---

Architettura della delega

Prima:

example.com → DNS Made Easy
api.example.com → DNS Made Easy

Dopo:

example.com → DNS Made Easy
api.example.com → Provider esterno (via NS delegation)

---

Procedura

1. Creazione record NS (delegazione)

Nel pannello DNS Made Easy:

• Seleziona il dominio
• Vai su NS Records
• Aggiungi un record per il sottodominio

Esempio

api   NS   ns1.external-dns.net.
api   NS   ns2.external-dns.net.

Note operative

• Il nome (api) è relativo alla zona (example.com)
• Il FQDN dei nameserver deve terminare con .
• TTL consigliato: basso durante setup (es. 300)

---

2. Configurazione lato provider esterno

Sul provider target:

• Crea una nuova zona DNS:

api.example.com

• Aggiungi i record necessari:

@     A      203.0.113.10
www   CNAME  @

---

3. Verifica della delega

Usa dig per verificare i NS:

dig NS api.example.com

Output atteso:

api.example.com.   300   IN   NS   ns1.external-dns.net.
api.example.com.   300   IN   NS   ns2.external-dns.net.

Verifica autoritatività:

dig @ns1.external-dns.net api.example.com

---

Come funziona (livello DNS)

Il resolver segue questo flusso:

1. Query a example.com
2. Il server autoritativo restituisce i record NS per api.example.com
3. Il resolver interroga i nuovi NS
4. Risposta finale dal provider esterno

In pratica, si crea una zone cut nel namespace DNS.

---

Edge case e problemi comuni

1. Missing trailing dot

ns1.external-dns.net   ❌
ns1.external-dns.net.  ✅

Senza il punto finale, il resolver può interpretare:

ns1.external-dns.net.example.com

---

2. Record sovrapposti

Non devono esistere record sullo stesso nome:

api   A    1.2.3.4   ❌
api   NS   ns1...    ✅

---

3. Glue records (caso avanzato)

Se i nameserver sono sotto lo stesso dominio delegato:

ns1.api.example.com

Serve configurare i glue record sul parent zone.

---

4. Propagazione

• Tipico: pochi minuti (TTL)
• Worst case: fino a 24h (cache resolver)

---

Debug avanzato

Trace completo

dig +trace api.example.com

Verifica SOA

dig SOA api.example.com

Deve rispondere il provider esterno.

---

Best practice

• TTL basso durante rollout, poi aumentare
• Sempre almeno 2 NS
• Monitoraggio DNS (health check)
• Versionamento configurazioni DNS (Infrastructure as Code)

---

Conclusione

La delegazione di sottodomini tramite NS è una tecnica fondamentale per:

• architetture distribuite
• multi-provider DNS
• gestione scalabile di servizi

Se implementata correttamente, permette isolamento totale senza impattare il dominio principale.

---