Questa è una domanda canonica sull'opportunità di esternalizzare la risoluzione DNS per i propri domini

Al momento il mio ISP fornisce DNS per il mio dominio, ma impongono limitazioni all'aggiunta di record. Pertanto, sto pensando di eseguire il mio DNS.

Preferisci ospitare il tuo DNS o è meglio che il tuo ISP lo faccia?

Ci sono alternative che posso esaminare?

Non gestirei il mio server DNS: nel mio caso, la società di hosting che ospita il mio sito Web offre un servizio DNS gratuito. Ci sono anche alternative, aziende che non fanno altro che l'hosting DNS (mi viene in mente DNS Made Easy , ma ce ne sono molte altre) che sono il tipo di cose che probabilmente dovresti esaminare.

Il motivo per cui non lo farei da solo è che il DNS dovrebbe essere abbastanza affidabile e, a meno che tu non abbia una tua rete di server distribuita geograficamente, dovresti mettere tutte le uova nello stesso paniere, per così dire. Inoltre, ci sono molti server DNS dedicati là fuori, abbastanza da non doverne avviare uno nuovo.

Ospitiamo sempre il nostro DNS (preferibilmente DNS inverso anche). Questo ci consente di apportare modifiche di emergenza senza affidarci a terzi. Se hai più di una posizione, è facile impostare un livello di ridondanza accettabile per i tuoi server DNS.

Se non hai più siti, prenderei in considerazione qualcuno che fa specificamente l'hosting DNS (NON il tuo ISP) con un'interfaccia web per le modifiche. Cerca anche supporto 24x7 e SLA decenti.

Per una configurazione DNS valida e affidabile per i tuoi domini, dovresti avere ...

• Un minimo di due server DNS autorevoli per il tuo dominio;
• I server DNS devono essere collegati a reti fisiche e alimentatori diversi;
• I server DNS dovrebbero trovarsi in diverse aree geografiche.

Poiché è improbabile che tu abbia accesso all'infrastruttura di rete di cui sopra, è meglio scegliere un provider di hosting DNS affidabile (come altri hanno raccomandato) che abbia l'infrastruttura di rete di cui sopra.

Per molti anni ho gestito i miei server DNS usando BIND (versioni 8 e 9) senza grossi problemi. Ho archiviato le mie configurazioni nel controllo versione con controlli post-commit che avrebbero convalidato i file di zona e quindi i miei server DNS avrebbero verificato i file di zona a intervalli regolari. Il problema consisteva sempre nell'assicurare che il numero di serie SOA fosse aggiornato con ogni commit che veniva espulso altrimenti i server di cache non venivano aggiornati.

Anni dopo ho lavorato con djbdns poiché il formato era ideale per avere script automatici per gestire le zone e non soffriva dello stesso problema con il numero di serie SOA che dovevo affrontare usando BIND. Tuttavia aveva i suoi problemi con la necessità di formattare determinati set di record di risorse per farli accettare.

Come ho scoperto, gran parte del mio traffico era DNS e dover mantenere un server DNS primario e secondario per soddisfare i registrar che da allora mi sono trasferito a utilizzare EasyDNS per le mie esigenze DNS. La loro interfaccia web è facile da gestire e mi dà la flessibilità di cui ho bisogno per gestire i miei set RR. Ho anche trovato facile lavorare con quelli forniti da alcuni provider di hosting come 1 & 1 che limitano i set RR disponibili che puoi inserire, o persino registrar di domini come Network Solutions che funziona solo se usi Windows per gestire il tuo DNS.

Per i miei domini personali (e alcuni domini di amici con cui aiuto) ospitiamo il nostro DNS e il mio registrar (Gandi) fornisce DNS secondario. O un amico su un'altra rete fornisce secondario. Gandi non aggiorna immediatamente le zone, sembrano controllare circa una volta ogni 24 ore circa, ma i cambiamenti sono molto rari; funziona abbastanza bene per noi e il loro server è probabilmente molto più affidabile del nostro.

Nel mio lavoro, facciamo il nostro DNS e il nostro provider di rete upstream fornisce DNS secondario. Tuttavia, siamo un'università e il 99% dei nostri utenti è sul posto; se la rete locale è inattiva, non importa se il DNS è inattivo. Inoltre, abbiamo una classe B completa (/ 16) con circa 25k record DNS (oltre 25k record DNS inversi, ovviamente), che sembra un po 'scomodo da gestire attraverso un'interfaccia web. I nostri server DNS locali sono altamente disponibili e molto veloci.

Ho fatto entrambe le cose. Ci possono essere dei vantaggi con l'hosting dei tuoi: sicuramente imparerai molto su come funziona il DNS quando il tuo capo ti sta chiedendo perché impiega così tanto tempo. Inoltre, hai molto più controllo delle tue zone. Questo non è sempre così potente come dovrebbe essere, in gran parte a causa della natura gerarchica distribuita del DNS - ma ogni tanto torna utile. Doppiamente se riesci a far sì che il tuo provider ti assegni come SOA per il DNS inverso del tuo blocco IP, supponendo che tu ne abbia uno.

Tuttavia, tutti i commenti sopra su come dovresti davvero avere un sacco di resistenza ai guasti incorporati sopra sono scoppiati. È importante server in diversi data center in diverse aree geografiche. Dopo aver gestito l'enorme interruzione di corrente nel nord-est del 2003, abbiamo appreso che avere una scatola in due diversi data center nella stessa città, o addirittura provincia o stato, non è necessariamente una protezione sufficiente. L'euforia che si manifesta quando ti rendi conto delle tue batterie e quindi dei generatori diesel che ti hanno salvato il sedere è rapidamente sostituita dal terrore causato dalla consapevolezza che ora stai guidando sulla tua ruota di scorta.

Tuttavia, eseguo sempre il nostro server DNS interno per la LAN. Può essere molto utile avere il controllo completo sul DNS che la tua rete utilizza internamente - e se l'alimentazione si spegne nel tuo ufficio, il tuo server DNS interno in virtù del fatto che si trova nel rack del server è probabilmente a batteria o batteria e diesel, mentre il tuo PC non lo farà, quindi i tuoi client rimarranno offline molto prima del server.

Sto leggendo tutte queste soluzioni con un certo divertimento perché siamo riusciti a adattarci accidentalmente a tutti questi "requisiti" ospitando il nostro DNS primario da una linea DSL statica e facendo in modo che il registrar (che si trovava in un altro continente) fornisse un DNS secondario su un connessione molto più seria e affidabile. In questo modo, otteniamo tutta la flessibilità di utilizzare il bind e di impostare tutti i record nel mentre siamo ragionevolmente certi che il secondario viene aggiornato per rispecchiare questi cambiamenti e sarà disponibile in caso di un tombino che prende fuoco, per citare un evento.

Ciò soddisfa effettivamente:
"Un minimo di due server DNS autorevoli per il tuo dominio;"
"I server DNS dovrebbero essere collegati a reti fisiche e alimentatori diversi;"
"I server DNS dovrebbero trovarsi in diverse aree geografiche".

Dai un'occhiata a Dyn.com ; hanno tutti i tipi di servizi relativi al DNS come hosting DNS, DNS dinamico, MailHop, ecc. ecc. Li ho trovati affidabili e li uso probabilmente da 5 anni.

Dipende.

Ho gestito il mio DNS per i miei vari lavori dalla fine degli anni '80 (BSD 4.3c). Per lavoro, ho sempre ospitato il mio DNS, ma ho sempre avuto più posizioni di datacenter o sono stato in grado di scambiare DNS secondario con un partner. Ad esempio, nel mio ultimo lavoro abbiamo eseguito DNS secondari per un diverso .EDU (erano in MN, siamo in CA) e hanno fatto lo stesso per noi. Diversità geografica e di rete.

Oppure, nel mio lavoro attuale, abbiamo i nostri datacenter della costa orientale e occidentale (USA). L'hosting del nostro DNS ci consente di inserire qualsiasi record DNS insolito di cui potremmo aver bisogno (SVR, TXT, ecc.) Che potrebbe non essere supportato da alcuni dei servizi DNS della GUI. E, possiamo cambiare i TTL quando vogliamo; abbiamo praticamente la massima flessibilità, al costo di farlo da soli.

Per le cose di casa, l'ho fatto in entrambi i modi. Per alcuni domini in cui sto facendo cose insolite, o ho bisogno di molta flessibilità, gestisco ancora i miei server DNS "nascosti" e scambio servizi DNS pubblici con altri che fanno lo stesso. Uso RCS per controllare i file di zona della versione per la gestione della configurazione, in modo da poter vedere l'intera cronologia dei cambiamenti di zona all'inizio del tempo. Per cose semplici come un dominio con un singolo blog o server Web generici (un record A o un CNAME), è più semplice utilizzare un servizio DNS di registrar di domini ove disponibile e ora preoccuparsi di CM.

È un compromesso. Il controllo e la flessibilità massimi hanno il costo di gestire la diversità da soli, eseguire più server, gestire guasti hardware / software, ecc. Se non è necessaria la flessibilità o il controllo totale, nessuno dei provider DNS di livello superiore lo farà risolvi il problema, probabilmente a un costo totale inferiore.

Come già accennato in questo thread, esistono diversi casi speciali con DNS, la differenza più significativa è tra le distribuzioni di server dei nomi autorevoli e di cache.

1. Se hai bisogno di un server DNS solo per risolvere le risorse di Internet, un risolutore DNS incassante gratuito è una scelta saggia. Personalmente uso PowerDNS recursor (pdns-recursor) su Linux.

2. Per la manutenzione della tua infrastruttura esterna, come siti web o MX, non userei NS interni (se stiamo parlando di SOHO qui). Utilizza un servizio valido, affidabile e a prova di proiettile come DNSmadeasy . Uso il loro pacchetto business e oscilla pur essendo molto conveniente.

Ho usato Zonedit o anni. È economico (o gratuito) e ho aggiunto molti record CNAME, A, MX, TXT, SRV e altri.

Recentemente abbiamo portato il nostro DNS pubblico in casa quando abbiamo portato tutti i nostri servizi in casa. Questo ci consente di aggiornare tutto il più rapidamente possibile. Avere DNS distribuito geograficamente non è un requisito per noi al momento in quanto i server Web sono tutti nello stesso sito.

Ho il meglio di entrambi i mondi.

Ospito il mio DNS pubblico per i miei siti Web e i miei record MX "altrove". È affidabile, è sicuro, funziona, posso modificarlo a piacimento. Pago per il servizio e sono contento del valore.

Ma a casa, eseguo il mio server DNS di cache piuttosto che fare affidamento sul mio ISP. Il mio ISP ha l'abitudine di perdere il DNS, avere DNS lento, DNS non valido, e talvolta vogliono rovesciare il DNS in modo che gli errori vadano in posti che ritengono possano interessarmi. Non mi interessa usare il DNS del mio ISP. Quindi ho i miei server DNS di cache e lo faccio da solo. Iniziare (forse 2 ore) è stato un po 'faticoso, ma è pulito e ho DNS affidabile. Una volta al mese, un cron job interroga i server root e aggiorna la tabella dei suggerimenti. Forse una volta all'anno devo giocarci, come inviare doubleclick.com a 127.0.0.1 o simili. A parte questo, non richiede alcun intervento e funziona benissimo.

Se decidi di ospitare il tuo DNS per amore di Dio, disponi di DUE server DNS per sito. Uno per il tuo DNS esterno, direttamente collegato al tuo firewall affinché il mondo possa trovarti. E uno separato all'interno della tua rete per il tuo DNS interno.

Non posso ancora commentare, ma sto facendo lo stesso di Freiheit. Eseguiamo il nostro DNS primario qui nella nostra DMZ e il nostro ISP ha diversi server DNS slave in tutto il paese che si aggiornano immediatamente dopo aver apportato una modifica al DNS primario.

Dà il meglio di entrambi i mondi; controllo immediato più ridondanza.

Ci sono pro e contro per ogni approccio, ma preferisco decisamente ospitare internamente il tuo DNS interno. L'elenco delle cose su cui fai affidamento per i servizi di rete di base se lo host esternamente è sbalorditivo. Il CEO potrebbe pensare che sia intelligente risparmiare sui server DNS ospitando esternamente, ma cosa penserà quando non riesce a ricevere la sua e-mail se il collegamento a Internet non funziona?

Per esperienza, se si desidera attirare un attacco denial of service, ospitare il proprio DNS. E il tuo sito web.

Credo che ci siano alcune cose che non dovresti fare da solo. L'hosting DNS è uno di questi. Come molte persone hanno detto, avresti bisogno di server ridondanti, connessioni e posizioni fisiche e non ti avvicineresti ancora alla resilienza delle aziende di hosting più piccole.

Il principale vantaggio dell'hosting del proprio DNS è che le modifiche possono essere apportate immediatamente. Devi abbreviare i tuoi TTL per una migrazione imminente? Probabilmente potresti scrivere uno script che lo fa sui tuoi server; per il DNS ospitato potrebbe essere necessario accedere e modificare manualmente i record o, peggio ancora, chiamare il provider, passare attraverso 3 livelli di supporto fino a quando non si raggiunge finalmente qualcuno in grado di scrivere il DNS, solo per far loro dire che invieranno il cambia in 2-3 giorni.

Gestisco il mio DNS usando BIND su server Linux. Attualmente ne ho quattro situate a Londra, Regno Unito, Miami FL, San Jose CA e Singapore. Funziona alla grande e ho il controllo completo. La stabilità del data center è molto importante, quindi ho selezionato buoni controller di dominio per eseguire i server (non affidandosi all'ISP o ad altre infrastrutture "sconosciute"). Sono in grado di configurare server DNS e altri servizi in qualsiasi parte del mondo utilizzando i controller di dominio di classe mondiale che seleziono in base a criteri rigorosi. Il solido DNS è essenziale per i servizi di posta elettronica e web che eseguo.

Dovremmo ospitare i nostri server dei nomi?

Sì, e dovresti anche usare uno o più dei grandi provider DNS di terze parti. Una soluzione ibrida è probabilmente l'approccio a lungo termine più sicuro per diversi motivi, soprattutto se si è un'azienda che ha una manor di SLA o requisiti contrattuali per i propri clienti. Ancora di più se sei b2b.

Se i tuoi server DNS master (nascosti o pubblici) sono la tua fonte di verità, allora ti proteggi operativamente dal rimanere bloccato nelle funzionalità specifiche del fornitore. Una volta che inizi a utilizzare le loro eleganti funzionalità che vanno oltre il DNS di base, potresti scoprire che passare a un altro provider o ospitare il tuo DNS è problematico, poiché ora devi replicare quelle funzionalità. Esempi potrebbero essere i controlli di integrità del sito e il failover DNS forniti da Dyn e UltraDNS. Quelle caratteristiche sono fantastiche, ma dovrebbero essere considerate una tantum e non una dipendenza. Queste funzionalità inoltre non si replicano bene da provider a provider.

Se hai solo fornitori di terze parti, il tuo tempo di attività potrebbe essere influenzato quando sono sotto un attacco DDoS mirato. Se hai solo i tuoi server DNS, il tempo di attività potrebbe essere influenzato quando sei il bersaglio di un attacco DDoS.

Se hai uno o più provider DNS e i tuoi server DNS distribuiti che eseguono lo slave su server DNS master nascosti che controlli, allora ti assicurerai di non essere bloccato in un determinato fornitore e di mantenere il controllo delle tue zone in ogni momento e che gli attacchi devono smantellare sia i tuoi server che uno o più provider principali che sono schiavi dei tuoi server. Nulla di meno sarà un degrado del servizio rispetto a un'interruzione critica.

Un altro vantaggio di avere i tuoi server master (idealmente nascosti, non pubblicati) è che puoi costruire la tua API e aggiornarli in qualsiasi proprietà adatta alle tue esigenze aziendali. Con provider DNS di terze parti, dovrai adattarti alla loro API. Ogni venditore ha il suo; o in alcuni casi, ha solo un'interfaccia utente Web.

Inoltre, se il tuo master è sotto il tuo controllo e un fornitore ha un problema, tutti i tuoi server slave che possono ancora raggiungere il tuo master riceveranno gli aggiornamenti. Questo è qualcosa che vorresti avere dopo aver realizzato che avere una terza parte come master era un errore durante un grosso incidente DDoS e non sei in grado di cambiare nessuno dei server su provider che non sono sotto attacco.

Dal punto di vista legale, la prevenzione del blocco dei fornitori può anche essere importante per la tua azienda. Ad esempio, Dyn viene potenzialmente acquistata da Oracle. Ciò li mette in una posizione unica per raccogliere le statistiche DNS su tutti i clienti di Dyn. Ci sono aspetti competitivi di ciò che possono comportare rischi legali. Detto questo, non sono un avvocato, quindi dovresti consultare i tuoi team legali e PR in merito.

Ci sono molti altri aspetti di questo argomento se volessimo scavare nelle erbacce.

[Modifica] Se questo è solo per un piccolo dominio personale / hobby, allora 2 VM che non si trovano nello stesso datacenter l'una con l'altra, eseguire un piccolo demone DNS è più che sufficiente. Lo faccio per i miei domini personali. Non mi era chiaro se il tuo dominio significasse un'attività commerciale o solo per hobby. Qualunque sia la VM più piccola che puoi ottenere è più che sufficiente. Uso rbldnsd per i miei domini; usando un TTL molto alto nei miei archivi, poiché occupa 900 KB di RAM e può gestire qualsiasi abuso che la gente ci metta.

Pensa all'hosting DNS come base per i tuoi servizi pubblici. Nel mio caso l'email è fondamentale per la nostra attività. Se ospiti il ​​tuo DNS internamente e la tua connessione Internet vacilla, i tuoi record DNS possono diventare obsoleti, costringendo il tuo dominio a non essere disponibile.

Quindi nel mio caso, se non è possibile trovare un record MX per il nostro dominio, l'e-mail viene immediatamente respinta.

Quindi, ho il nostro DNS ospitato esternamente.

Se il record MX è disponibile, ma la nostra connessione Internet non è attiva, la posta continuerà a fare la coda sui server che tentano di inviare e-mail al nostro dominio.

Dipende. ™

Gestisco i miei server e gestisco domini almeno dal 2002.

Ho spesso usato il server DNS del mio provider.

Il numero di volte in cui il mio server sul mio IP era disponibile, ma il mio DNS no, era un numero eccessivo.

Ecco le mie storie di guerra:

• Un enorme fornitore a Mosca (uno dei primi basati su VZ) aveva il mio VPS in un controller "value" economico, ma il suo DNS era in un controller DC all'avanguardia con traffico costoso, in due diverse / 24 subnet, come richiesto da alcuni TLD al momento . Ad un certo punto, un disastro (probabilmente l' interruzione di corrente del 2005? ) E il loro costoso DC sono andati offline, e il mio sito (ancora a Mosca, ma in un "valore" DC) è stato accessibile solo dal suo indirizzo IP.

  È interessante notare che, anche prima di qualsiasi incidente, ricordo chiaramente di aver fatto traceroutee, notando la stessa DC per entrambi ns1e ns2per il mio ISP, chiedendo loro di spostarne uno anche nella "mia" DC, per ridondanza geografica; hanno respinto l'idea della ridondanza geografica, poiché i server erano già nel controller di dominio più premium possibile.

• Ho avuto un altro fornitore (uno dei primi basati sul sistema ISP), dove avevano uno in loco e un altro all'estero. Per farla breve, l'intera installazione era ridicolmente difettosa e il server "all'estero" spesso non riusciva a mantenere le sue zone, quindi il mio dominio aveva effettivamente un punto in più di errore e non sarebbe accessibile anche se il mio intero server continuava a funzionare senza problemi.

• Ho avuto un registrar che gestiva la propria rete. Ogni tanto si spegneva, anche se i miei server fuori sede erano attivi. Il mio DNS era inattivo.

• Di recente ho usato diversi grandi fornitori di cloud per il secondario, dove avrei gestito un master nascosto. Entrambi i provider hanno modificato la configurazione almeno una volta; mai con annunci pubblici; alcuni dei miei domini hanno smesso di risolversi. È successo anche a un mio amico, con uno degli stessi fornitori. Ciò accade più spesso con servizi di terze parti di quanto le persone si preoccupino di ammettere in pubblico.

In breve, http://cr.yp.to/djbdns/third-party.html è assolutamente corretto sull'argomento.

I costi di dover preoccuparsi di DNS di terze parti spesso non valgono i vantaggi.

Gli aspetti negativi di avere un DNS di terze parti sono spesso ingiustamente trascurati.

Direi che a meno che il tuo dominio non utilizzi già servizi di terze parti (ad esempio, per web, posta, voce o testo), l'aggiunta di un DNS di terze parti sarebbe quasi sempre controproducente e non è affatto la migliore pratica in ogni circostanza .