Med tanke på DNS-server Design

July 15

Inte alla har den erfarenhet som krävs för att utforma lösningar för applikationer infrastruktur nivå, såsom DNS (eller för webb och e-post, men det är ett annat ämne). Om du följer en grundläggande uppsättning riktlinjer, men kan du ha en stabil och skalbar DNS-server utan mycket krångel. Stabilitet och skalbarhet är de två egenskaper som alla arkitekter strävar efter. Naturligtvis kan DNS-servrar implementeras på andra sätt; varje systemadministratör har till synes hennes egna knep för att konfigurera ett system. Tänk på att varje smart trick som du använder i konfigurera ett system är ett mer huvudvärk du har när du felsöker systemet senare. Sträva efter enkelhet, och ditt förnuft kommer att tacka dig.

Att hålla servern säker

Säkerhet är av största vikt när du konfigurerar en DNS-server. Du kanske tror att säkerheten är verkligen viktigt bara i en miljö Internet Service Provider (ISP), för att undvika webbsida kapning eller e-post spoofing, men det är lika viktigt i ett företags inställning. DNS säkerhet är ganska viktigt i en ISP. Om en inkräktare får tillgång till din DNS-server, kan han peka A-poster till andra servrar som innehåller vandaliserats webbsidor, vilket är lika bra som att få tillgång till den ursprungliga webbservern själv och defacing sidan. Inkräktarens åtkomst kan också användas för att ändra MX-posten för en domän, som har ännu värre konsekvenser. Genom att peka MX-posten till en e-postserver, inkräktaren kontroller och även tar ägandet av domänen genom att skicka in ändringar i domänregistret. Observera att denna osäkerhet är inte så mycket fel på DNS-infrastruktur som det är fel av domänadministratörer som använder POST-TO som autentiseringsmetod för sina domäner.

DNS säkerhet är lika viktigt i ett företags inställning, även om den har en mer subtil betydelse. Problemet i en företagsmiljö är densamma som i en ISP: En inkräktare kan ändra DNS-poster till punkt till en server som han kontrollerar. I detta fall kan han stjäla viktiga data genom att användarna tror att det kommer att en riktig server när det verkligen kommer att oseriösa servern. Kom ihåg att de flesta attacker mot företagsnätverk kommer inifrån företaget, så DNS ​​säkerhet är viktigt även om du har en brandvägg eller ingen Internet-anslutning.

DNS körs inte i ett vakuum. Inte bara din DNS-tjänst måste säkras, men det operativsystem du använder och den fysiska servern måste också noggrant undersökas och testas. Även om du har säkrat de DNS-tjänster på rätt sätt, allt är för intet om ett nätverk inkräktare kan få administrative- eller rot-nivåkontroll för den server som är värd DNS.

Kanske mest uppenbara, bör du fysiskt säkra server på en plats där endast auktoriserade användare kan få tillgång till. Du bör också begränsa, använder operativsystem politik, nonadministrative personal från att kunna logga in på servern. Kontrollera regelbundet med operativsystemet leverantör för programuppdateringar och säkerhetsvarningar. Säkerheten för den server som är värd DNS är "Job # 1" - om du låter den glida, kommer du förmodligen att ångra.

I nödfall

När du planerar ut din DNS-infrastruktur, måste du alltid ha minst två DNS-servrar i syfte att redundans. Om en server går ner, kan den andra fortfarande betjäna kunder. DNS-servrar i många fall inte är överflödiga, men att situationen är absolut inte att rekommendera. Om du använder en enda DNS-server och det misslyckas, kommer du förmodligen få den föga avundsvärda uppgiften att svara massor av otäcka telefonsamtal.

Du kan ge DNS redundans på två sätt:

  • Master / slave: I den traditionella master / slave DNS relation, (en eller flera) DNS slavservrar lastzonen data från huvudservern vid start och vid intervaller som anges i början av myndighet (SOA) rekord för varje zon. Denna metod för redundans har en stor fördel: När en zon-fil ändras, är ändringarna automatiskt vidare till slavservrar. Denna process sker normalt så snart ändringar görs om MEDDELA DNS funktion stöds, och det som händer efter det tidsintervall i SOA posten om Meddela inte stöds.

Master / slav DNS-server relationen har en nackdel också: Om befälhavaren går ner, är slaven startas, och zondata kan inte överföras. Dessutom, om befälhavaren går ner och är inte återställd när DNS-posten blir gammal (eftersom den inte kan uppdatera från huvudservern), är zonen inte längre tillgänglig.

  • Flera herre: Om du är mer intresserad av att ha DNS tillgänglig hela tiden i stället för att ha bekvämligheten tillhandahålls av en master / slav konfiguration kan du använda en multipel mästare konfiguration. Detta koncept är enkelt: Alla DNS-servrar är huvudservrar för varje zon. Den svåraste delen av att ha flera mästare DNS-servrar kommer när en ändring görs till en zon-fil eller DNS-konfiguration. Ändringen skall göras till varje mästare DNS-server och är inte automatiskt förökas.

Lägg inte alla ägg i samma korg

Placeringen av de DNS-servrar är viktig för ett antal skäl. (Detta avsnitt lappar något med de föregående två avsnitt.) De flesta miljöer använder två DNS-servrar - en mästare och en slav eller två mästare om de är bara caching - även om ingen gräns finns på antalet servrar kan du ha.

Du måste tänka på två separata men relaterade frågor för DNS serverplats:

  • Placering i förhållande till en brandvägg: I de flesta fall är interna DNS-servrar placerade på det interna nätverket och externt tillgängliga servrar är placerade i den demilitariserade zonen (DMZ) av brandväggen, vilket är säker men också tillgänglig från det publika nätet. Om du bara har en uppsättning av DNS-servrar för både intern och extern DNS (även om detta arrangemang inte rekommenderas), ska du placera dem i DMZ och har interna användare komma åt dem från det interna nätverket i stället placera dem i det interna nätverket och öppna ett hål i din brandvägg för externa DNS-förfrågningar.
  • Placering på dina nätverkssegment geografiskt eller på annat logiskt sätt: Du har ett antal skäl för att placera dina DNS-servrar på separata nätverkssegment och separata platser -primarily, redundans. Om en nätverkssegment går ner, eller ens en hel plats går förlorad eftersom en katastrof av något slag, du fortfarande kan ge DNS-tjänst. Dessutom kan prestandaökningar för interna DNS-servrar uppstå om du konfigurerar system för att använda den lokala DNS-servern först och använda fjärrkontrollen DNS-servern om den lokala servern är nere. Som har åtminstone en intern DNS-server vid varje geografisk plats är vanlig praxis.