Perché vorresti eseguire i server DNS esternamente?

Quando si parla di server DNS, è importante distinguere tra resolver ricorsivi (quei server che forniscono servizi di risoluzione dei nomi) e nameserver autorevoli (quei server che rispondono alle query finali dai file di zona locali).

Se si parla di risolutori ricorsivi (server di caching DNS), quindi, con ogni mezzo, se un'organizzazione ha una intranet, i resolver ricorsivi dovrebbero essere lì, non su Internet. E se l'organizzazione non ha una rete Intranet o una rete interna segregata, i risolutori ricorsivi che consentono query da un insieme limitato di fonti sono certamente una buona idea. Come dici tu, un ISP potrebbe avere un caso per un resolver aperto, in parte perché non ci si aspetta che le query per nomi non pubblici siano gestite da un tale server, in parte a causa della difficoltà di elencare quantità molto elevate di indirizzi IP consentiti e in parte per ragioni storiche (è sempre stato fatto in passato).

Se stai parlando di server dei nomi autorevoli, un buon motivo per avere quei server su Internet è per un eccellente tempo di risposta. Ogni singolo cliente che vuole raggiungere il tuo sito web, il tuo server di posta elettronica, il tuo server SIP o qualsiasi altra cosa tu possa pensare di offrire per nome sotto il tuo nome di dominio, prima o poi genererà una query sul tuo server dei nomi autorevole (eccetto se la risposta è già stata memorizzata nella cache). Il tempo di risposta di questo server influirà sul tempo di risposta di ogni servizio che offri. Se si desidera, la query deve essere inoltrata a un server reattivo in un centro di hosting ben collegato. Se non si dispone di server propri in tali luoghi, è probabilmente una buona idea affidare a fornitori DNS un autorevole servizio di nomi. Al giorno d'oggi, quasi ogni registrar di domini offre anche un servizio di nomi autorevole in outsourcing, se lo desideri. Esagero un po 'l'importanza di un server dei nomi autorevole molto reattivo, ma ottieni il messaggio.

Sempre sull'argomento dei nameserver autorevoli, dovrei notare che almeno una delle minacce menzionate, avvelenamento della cache, non è applicabile: un server dei nomi autorevole è configurato per non rispondere alle query dalla cache. Per quanto riguarda gli attacchi di amplificazione (dove vengono inviati pacchetti spoofati con una domanda, la risposta è più grande della domanda, e questa risposta viene indirizzata a una vittima), la posizione del nameserver (dietro un firewall o meno) non sta andando a fare una differenza. In una certa misura, il nameserver deve rispondere a queste domande, indipendentemente dal caso in cui i client non trovino i servizi nel tuo dominio.

Una configurazione comune per le organizzazioni con intranet è divisa DNS: ci sono due serie di server DNS autorevoli. Un set ha la versione pubblica della zona e appartiene a Internet. L'altro set ha la versione interna (che probabilmente ha un superset dei contenuti della versione pubblica) e appartiene alla intranet. Questo caso è piuttosto semplice. I server pubblici autorevoli non sono in grado di perdere accidentalmente informazioni DNS private perché non dispongono di una copia del file di zona interno e non possono ottenerne una poiché sono in Internet. (Ovviamente questo presuppone che il processo di distribuzione del file di zona non invierà un file zona non pubblicizzato alla versione pubblica del server durante un aggiornamento!)

Se disponi di indirizzi IP accessibili pubblicamente sulla tua rete interna e desideri che le persone sulla rete pubblica siano in grado di accedere a tali risorse, hanno bisogno di accedere al tuo server DNS. Ovviamente, molte cose dovrebbero essere nella DMZ, ma potrebbe esserci una connessione partner o extranet all'interno della rete che è consentita attraverso il firewall su una rete interna isolata. Sarebbe questione di volere che le informazioni siano pubbliche; è anche possibile una sua errata configurazione.

Oltre alla risposta di Celada, i server di posta elettronica che utilizzano DNS per eseguire operazioni AntiSpam (SPF e così via) non dovrebbero utilizzare lo stesso set di server utilizzato dal resolver interno ricorsivo.

Molte persone che utilizzano l'e-mail in outsourcing, come Postini, Microsoft Office 365, Proofpoint ospitato da PoD, ecc., sono isolate in virtù dell'outsourcing.

Se si ospitano i messaggi di posta elettronica in-house, è necessario considerare i relay SMTP edge point (qualsiasi cosa esegua un controllo SPF o DKIM) su qualsiasi server DNS diverso dal resolver ricorsivo interno.