introduktion

en viktig del av hanteringen av serverkonfiguration och infrastruktur inkluderar att upprätthålla ett enkelt sätt att slå upp nätverksgränssnitt och IP-adresser med namn genom att ställa in ett riktigt domännamnssystem (DNS). Att använda fullständigt kvalificerade domännamn (FQDNs) istället för IP-adresser för att ange nätverksadresser underlättar konfigurationen av tjänster och applikationer och ökar underhållbarheten för konfigurationsfiler. Att konfigurera din egen DNS för ditt privata nätverk är ett utmärkt sätt att förbättra hanteringen av dina servrar.

i denna handledning kommer vi att gå över hur du ställer in en intern DNS-server med BIND name server software (BIND9) på CentOS 7, som kan användas av dina virtuella privata servrar (VPS) för att lösa privata värdnamn och privata IP-adresser. Detta ger ett centralt sätt att hantera dina interna värdnamn och privata IP-adresser, vilket är oumbärligt när din miljö expanderar till mer än några värdar.

Ubuntu-versionen av denna handledning finns här.

förutsättningar

för att slutföra denna handledning behöver du följande:

• vissa servrar som körs i samma datacenter och har privat nätverk aktiverat
• en ny VPS för att fungera som den primära DNS-servern, ns1
• valfritt: en ny VPS för att fungera som en sekundär DNS-server, ns2
• Root-åtkomst till alla ovanstående (steg 1-4 här)

om du inte känner till DNS-koncept rekommenderas att du läser åtminstone de tre första delarna av vår introduktion till hantering av DNS.

exempel värdar

till exempel kommer vi att anta följande:

• Vi har två befintliga VPS som heter ”host1” och ”host2”
• båda VPS finns i nyc3 datacenter
• båda VPS har privat nätverk aktiverat (och finns på 10.128.0.0/16 subnät)
• båda VPS är på något sätt relaterade till vår webbapplikation som kör på ”example.com”

med dessa antaganden bestämmer vi att det är vettigt att använda ett namngivningsschema som använder ”nyc3.example.com” för att hänvisa till vårt privata delnät eller zon. Därför kommer host1s privata fullständigt kvalificerade domännamn (FQDN) att vara ”host1.nyc3.example.com”. se följande tabell relevanta detaljer:

värd	Roll	privat FQDN	privat IP-adress
värd1	Generisk värd 1	host1.nyc3.example.com	10.128.100.101
värd2	Generisk värd 2	host2.nyc3.example.com	10.128.200.102

Obs: din befintliga inställning kommer att vara annorlunda, men exempelnamnen och IP-adresserna används för att visa hur du konfigurerar en DNS-server för att tillhandahålla en fungerande intern DNS. Du bör enkelt kunna anpassa denna inställning till din egen miljö genom att ersätta värdnamn och privata IP-adresser med din egen. Det är inte nödvändigt att använda regionnamnet på datacentret i ditt namnschema, men vi använder det här för att beteckna att dessa värdar tillhör ett visst datacenters privata nätverk. Om du använder flera datacenter kan du ställa in en intern DNS inom respektive datacenter.

vårt mål

i slutet av denna handledning kommer vi att ha en primär DNS-server, ns1, och eventuellt en sekundär DNS-server, ns2, som kommer att fungera som en säkerhetskopia.

här är en tabell med exempelnamn och IP-adresser:

värd	Roll	privat FQDN	privat IP-adress
ns1	primär DNS-server	ns1.nyc3.example.com	10.128.10.11
ns2	sekundär DNS-Server	ns2.nyc3.example.com	10.128.20.12

låt oss komma igång genom att installera vår primära DNS-server, ns1.

installera BIND på DNS-servrar

Obs: Text som är markerad i rött är viktigt! Det används ofta för att beteckna något som behöver bytas ut mot dina egna inställningar eller att det ska ändras eller läggas till i en konfigurationsfil. Till exempel, om du ser något som host1.nyc3.exempel.com, ersätt den med FQDN på din egen server. På samma sätt, om du ser host1_private_IP, ersätt den med din egen servers privata IP-adress.

på både DNS-servrar, ns1 och ns2, installera BIND med yum:

sudo yum install bind bind-utils

bekräfta prompten genom att angey.

nu när BIND är installerat, låt oss konfigurera den primära DNS-servern.

konfigurera primär DNS-Server

binds konfiguration består av flera filer, som ingår i huvudkonfigurationsfilen,named.conf. Dessa filnamn börjar med ”namngivna” eftersom det är namnet på processen som binder körs. Vi börjar med att konfigurera alternativfilen.

konfigurera Bind

BINDENS process kallas namngiven. Som sådan hänvisar många av filerna till ”namngivna” istället för”binda”.

på ns1 öppnar dunamed.conf fil för redigering:

sudo vi /etc/named.conf

ovanför det befintligaoptions, skapa ett nytt ACL-block som heter ”trusted”. Det är här vi kommer att definiera lista över klienter som vi tillåter rekursiva DNS-frågor från (dvs. servrar som finns i samma datacenter som ns1). Med våra exempel privata IP-adresser lägger vi till ns1, ns2, host1 och host2 till vår lista över betrodda kunder:

acl "trusted" { 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2};

Nu när vi har vår lista över betrodda DNS-klienter vill vi redigeraoptions block. Lägg till den privata IP-adressen för ns1 tilllisten-on port 53 – direktivet och kommenteralisten-on-v6 rad:

options { listen-on port 53 { 127.0.0.1; 10.128.10.11; };# listen-on-v6 port 53 { ::1; };...

under dessa poster ändrar du allow-transfer direktivet till från ”none” till ns2: s privata IP-adress. Ändra ocksåallow-query direktiv från ”localhost” till ”trusted”:

i slutet av filen lägger du till följande rad:

include "/etc/named/named.conf.local";

spara nu och avsluta named.conf. Ovanstående konfiguration anger att endast dina egna servrar (de ”betrodda”) kommer att kunna fråga din DNS-server.

därefter konfigurerar vi den lokala filen för att ange våra DNS-zoner.

konfigurera lokal fil

på ns1 öppnar du filen named.conf.local för redigering:

sudo vi /etc/named/named.conf.local

filen ska vara tom. Här kommer vi att ange våra framåtriktade och omvända zoner.

Lägg till framåtzonen med följande rader (ersätt zonnamnet med ditt eget):

zone "nyc3.example.com" { type master; file "/etc/named/zones/db.nyc3.example.com"; # zone file path};

förutsatt att vårt privata delnät är 10.128.0.0/16, Lägg till omvänd zon med följande rader (Observera att vårt omvända zonnamn börjar med ”128.10” som är oktettomvandlingen av ”10.128”):

zone "128.10.in-addr.arpa" { type master; file "/etc/named/zones/db.10.128"; # 10.128.0.0/16 subnet };

om dina servrar spänner över flera privata undernät men är i samma datacenter, var noga med att ange en ytterligare zon-och zonfil för varje distinkt delnät. När du är klar med att lägga till alla önskade zoner, spara och avsluta filen named.conf.local.

Nu när våra zoner anges i BIND måste vi skapa motsvarande framåt-och bakåtzonfiler.

skapa framåt zonfil

framåt zonfilen är där vi definierar DNS-poster för framåt DNS-sökningar. Det vill säga när DNS tar emot en namnfråga, ”host1.nyc3.example.com” det kommer till exempel att se ut i forward zone-filen för att lösa host1s motsvarande privata IP-adress.

Låt oss skapa katalogen där våra zonfiler kommer att finnas. Enligt vår namngivna.conf.lokal konfiguration, den platsen ska vara /etc/named/zones:

 
sudo chmod 755 /etc/named
 
sudo mkdir /etc/named/zones
 

låt oss nu Redigera vår forward zone-fil:

sudo vi /etc/named/zones/db.nyc3.example.com 

först vill du lägga till SOA-posten. Ersätt den markerade ns1 FQDN med din egen FQDN, ersätt sedan den andra ”nyc3.example.com” med din egen domän. Varje gång du redigerar en zonfil bör du öka serievärdet innan du startar om named –processen-vi ökar det till ”3”. Det ska se ut så här:

därefter lägger du till dina namnserverposter med följande rader (ersätt namnen med dina egna). Observera att den andra kolumnen anger att dessa är ”NS” — poster:

; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.

lägg sedan till A-posterna för dina värdar som hör hemma i den här zonen. Detta inkluderar alla servrar vars namn vi vill avsluta med”. nyc3.example.com ” (ersätt namn och privata IP-adresser). Med hjälp av våra exempelnamn och privata IP-adresser lägger vi till en post för ns1, ns2, host1 och host2 som så:

spara och avsluta filendb.nyc3.example.com.

vårt sista exempel framåt zonfil ser ut som följande:

låt oss nu gå vidare till omvänd zonfil(er).

skapa omvänd zonfil (er)

omvänd zonfil är där vi definierar DNS PTR-poster för omvänd DNS-sökning. Det vill säga när DNS tar emot en fråga via IP-adress, ”10.128.100.101”, kommer det till exempel att se ut i omvänd zonfil(er) för att lösa motsvarande FQDN, ”host1.nyc3.example.com ” i det här fallet.

på ns1 skapar du en omvänd zonfil för varje omvänd zon som anges i named.conf.local.

redigera den omvända zonfilen som motsvarar den omvända zonen(er) som definieras i named.conf.local:

sudo vi /etc/named/zones/db.10.128 

på samma sätt som den främre zonfilen, ersätt den markerade ns1 FQDN med din egen FQDN och ersätt sedan den andra ”nyc3.example.com” med din egen domän. Varje gång du redigerar en zonfil bör du öka serievärdet innan du startar om named –processen-vi ökar det till ”3”. Det ska se ut så här:

därefter lägger du till dina namnserverposter med följande rader (ersätt namnen med dina egna). Observera att den andra kolumnen anger att dessa är ”NS” – poster:

; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.

lägg sedan till PTR poster för alla dina servrar vars IP-adresser finns på delnätet i zonfilen som du redigerar. I vårt exempel inkluderar detta alla våra värdar eftersom de alla finns på delnätet 10.128.0.0/16. Observera att den första kolumnen består av de två sista oktetterna i dina serverns privata IP-adresser i omvänd ordning. Var noga med att ersätta namn och privata IP-adresser för att matcha dina servrar:

spara och avsluta filen med omvänd zon (upprepa detta avsnitt om du behöver lägga till fler filer med omvänd zon).

vårt sista exempel på omvänd zonfil ser ut som följande:

kontrollera BIND Konfigurationssyntax

kör följande kommando för att kontrollera syntaxen för named.conf* filer:

sudo named-checkconf

om dina namngivna konfigurationsfiler inte har några syntaxfel återgår du till din skalprompt och ser inga felmeddelanden. Om det finns problem med dina konfigurationsfiler, granska felmeddelandet och avsnittet Konfigurera primär DNS-Server och försök sedan named-checkconf igen.

kommandotnamed-checkzone kan användas för att kontrollera att dina zonfiler är korrekta. Dess första argument anger ett zonnamn och det andra argumentet anger motsvarande zonfil, som båda definieras i named.conf.local.

till exempel för att kontrollera ”nyc3.example.com” framåt zon konfiguration, kör följande kommando (ändra namnen för att matcha din framåt zon och fil):

sudo named-checkzone nyc3.example.com /etc/named/zones/db.nyc3.example.com 

och för att kontrollera ”128.10.in-addr.arpa” omvänd zonkonfiguration, kör följande kommando (ändra siffrorna för att matcha din omvänd zon och fil):

sudo named-checkzone 128.10.in-addr.arpa /etc/named/zones/db.10.128 

När alla dina konfigurations-och zonfiler inte har några fel i dem, bör du vara redo att starta om BIND-tjänsten.

Start BIND

Start BIND:

sudo systemctl start named

nu vill du aktivera det, så det börjar vid start:

sudo systemctl enable named

din primära DNS-server är nu inställd och redo att svara på DNS-frågor. Låt oss gå vidare till att skapa den sekundära DNS-servern.

konfigurera sekundär DNS-Server

i de flesta miljöer är det bra att ställa in en sekundär DNS-server som svarar på förfrågningar om primären blir otillgänglig. Lyckligtvis är den sekundära DNS-servern mycket lättare att konfigurera.

på ns2, redigeranamed.conf fil:

sudo vi /etc/named.conf

Obs: Om du föredrar att hoppa över dessa instruktioner kan du kopiera ns1snamed.conf fil och ändra den för att lyssna på ns2s privata IP-adress och inte tillåta överföringar.

ovanför det befintligaoptions block, skapa ett nytt ACL-block som heter ”trusted”. Det är här vi kommer att definiera lista över klienter som vi tillåter rekursiva DNS-frågor från (dvs. dina servrar som finns i samma datacenter som ns1). Med våra exempel privata IP-adresser lägger vi till ns1, ns2, host1 och host2 till vår lista över betrodda kunder:

acl "trusted" { 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2};

Nu när vi har vår lista över betrodda DNS-klienter vill vi redigeraoptions block. Lägg till den privata IP-adressen för ns1 tilllisten-on port 53 – direktivet och kommenteralisten-on-v6 rad:

options { listen-on port 53 { 127.0.0.1; 10.128.20.12; };# listen-on-v6 port 53 { ::1; };...

ändra allow-query direktiv från” localhost ”till”trusted”:

...options {... allow-query { trusted; }; # allows queries from "trusted" clients...

i slutet av filen lägger du till följande rad:

include "/etc/named/named.conf.local";

spara nu och avsluta named.conf. Ovanstående konfiguration anger att endast dina egna servrar (de ”betrodda”) kommer att kunna fråga din DNS-server.

därefter konfigurerar vi den lokala filen för att ange våra DNS-zoner.

spara och avsluta named.conf.

redigera nunamed.conf.local fil:

 
sudo chmod 755 /etc/named
 
sudo vi /etc/named/named.conf.local
 

definiera slavzoner som motsvarar huvudzonerna på den primära DNS-servern. Observera att typen är ”slav”, filen innehåller inte en sökväg och det finns ett masters – direktiv som ska ställas in på den primära DNS-serverns privata IP. Om du definierade flera omvända zoner i den primära DNS-servern, se till att lägga till dem alla här:

spara nu och avslutanamed.conf.local.

kör följande kommando för att kontrollera giltigheten av dina konfigurationsfiler:

sudo named-checkconf

När du checkar ut, starta BIND:

sudo systemctl start named

Aktivera BIND för att starta vid start:

sudo systemctl enable named

nu har du primära och sekundära DNS-servrar för privat nätverksnamn och IP-adressupplösning. Nu måste du konfigurera dina servrar för att använda dina privata DNS-servrar.

konfigurera DNS-klienter

innan alla dina servrar i ”trusted” ACL kan fråga dina DNS-servrar måste du konfigurera var och en av dem för att använda ns1 och ns2 som namnservrar. Denna process varierar beroende på operativsystem, men för de flesta Linux-distributioner innebär det att du lägger till dina namnservrar till /etc/resolv.conf – filen.

CentOS-klienter

på CentOS, RedHat och Fedora Linux VPS redigerar du bararesolv.conf – filen:

sudo vi /etc/resolv.conf

lägg sedan till följande rader till toppen av filen (ersätt din privata domän och ns1 och ns2 privata IP-adresser):

search nyc3.example.com # your private domainnameserver 10.128.10.11 # ns1 private IP addressnameserver 10.128.20.12 # ns2 private IP address

spara och avsluta nu. Din klient är nu konfigurerad att använda dina DNS-servrar.

Ubuntu-klienter

På Ubuntu och Debian Linux VPS kan du redigerahead – filen, som är prepended till resolv.conf vid start:

sudo vi /etc/resolvconf/resolv.conf.d/head

Lägg till följande rader i filen (ersätt din privata domän och ns1 och ns2 privata IP-adresser):

search nyc3.example.com # your private domainnameserver 10.128.10.11 # ns1 private IP addressnameserver 10.128.20.12 # ns2 private IP address

kör nu resolvconf för att skapa ett nytt resolv.conf fil:

sudo resolvconf -u

din klient är nu konfigurerad att använda din DNS servrar.

Testklienter

användnslookup—ingår i paketet ”bind-utils”—för att testa om dina klienter kan fråga dina namnservrar. Du bör kunna göra detta på alla klienter som du har konfigurerat och är i ”trusted” ACL.

framåt Lookup

till exempel kan vi utföra en framåt lookup för att hämta IP-adressen för host1.nyc3.example.com genom att köra följande kommando:

nslookup host1

fråga ”host1” expanderar till ”host1.nyc3.example.com på grund av search alternativet är inställt på din privata underdomän, och DNS-frågor kommer att försöka titta på den underdomänen innan du letar efter värden någon annanstans. Utmatningen av kommandot ovan skulle se ut som följande:

Output:
Server: 10.128.10.11Address: 10.128.10.11#53Name: host1.nyc3.example.comAddress: 10.128.100.101

omvänd sökning

för att testa omvänd sökning, fråga DNS-servern med host1s privata IP-adress:

nslookup 10.128.100.101

Du bör se utdata som ser ut som följande:

Output:
Server: 10.128.10.11Address: 10.128.10.11#5311.10.128.10.in-addr.arpa name = host1.nyc3.example.com.

om alla namn och IP-adresser löser sig till rätt värden betyder det att dina zonfiler är korrekt konfigurerade. Om du får oväntade värden, se till att granska zonfilerna på din primära DNS-server (t. ex. db.nyc3.example.comoch db.10.128).

Grattis! Dina interna DNS-servrar är nu inställda på rätt sätt! Nu kommer vi att täcka underhålla din zon register.

underhålla DNS-poster

Nu när du har en fungerande intern DNS måste du behålla dina DNS-poster så att de korrekt återspeglar din servermiljö.

lägga till värd till DNS

När du lägger till en värd i din miljö (i samma datacenter) vill du lägga till den i DNS. Här är en lista över steg som du behöver ta:

primär Namnserver

• Forward zone file: Lägg till en ”a” – post för den nya värden, öka värdet på ”Serial”
• omvänd zonfil: Lägg till en ”PTR” – post för den nya värden, öka värdet på ”Serial”
• Lägg till din nya värdens privata IP-adress till ”trusted” ACL (named.conf.options)

sedan ladda bind:

sudo systemctl reload named

sekundär namnserver

• Lägg till din nya värdens privata IP-adress till den ”betrodda” ACL (named.conf.options)

sedan ladda bind:

sudo systemctl reload named

konfigurera ny värd för att använda din DNS

• konfigurera resolv.conf för att använda dina DNS-servrar
• Test med nslookup

ta bort värd från DNS

om du tar bort en värd från din miljö eller bara vill ta den ur DNS, ta bara bort alla saker som lades till när du lade till servern i DNS (dvs. baksidan av stegen ovan).

slutsats

Nu kan du hänvisa till dina serverns privata nätverksgränssnitt med namn, snarare än med IP-adress. Detta gör konfigurationen av tjänster och applikationer enklare eftersom du inte längre behöver komma ihåg de privata IP-adresserna, och filerna blir lättare att läsa och förstå. Nu kan du också ändra dina konfigurationer för att peka på en ny server på en enda plats, din primära DNS-server, istället för att behöva redigera en mängd distribuerade konfigurationsfiler, vilket underlättar underhållet.

När du har konfigurerat din interna DNS och dina konfigurationsfiler använder privata FQDNs för att ange nätverksanslutningar är det viktigt att dina DNS-servrar underhålls ordentligt. Om de båda blir otillgängliga upphör dina tjänster och applikationer som är beroende av dem att fungera korrekt. Det är därför det rekommenderas att ställa in din DNS med minst en sekundär server och för att upprätthålla fungerande säkerhetskopior av dem alla.