Hoe BIND configureren als een privé netwerk DNS-server op Ubuntu 22.04

Inleiding

Een belangrijk onderdeel van het beheren van serverconfiguratie en infrastructuur is het onderhouden van een manier om netwerkinterfaces en IP-adressen op naam te vinden. Een manier om dit te doen, is het instellen van een correct Domain Name System (DNS). Door volledig gekwalificeerde domeinnamen (FQDNs) te gebruiken in plaats van IP-adressen om netwerkadressen op te geven, optimaliseert u de configuratie van services en toepassingen, en verbetert u de onderhoudbaarheid van configuratiebestanden. Het opzetten van uw eigen DNS voor uw privénetwerk is een uitstekende manier om het beheer van uw servers te verbeteren.

In deze tutorial zul je een interne DNS-server opzetten met behulp van twee Ubuntu 22.04-servers. Je zult de BIND-nameserversoftware (BIND9) gebruiken om privéhostnamen en privé-IP-adressen op te lossen. Dit biedt een centrale manier om je interne hostnamen en privé-IP-adressen te beheren, wat onmisbaar is wanneer je omgeving groter wordt dan slechts een paar hosts.

Vereisten

Om deze tutorial te voltooien, heb je de volgende infrastructuur nodig. Zorg ervoor dat je elke server in hetzelfde datacenter met ingeschakelde privénetwerken maakt:

• A fresh Ubuntu 22.04 server to serve as the Primary DNS server, ns1.
• (Aanbevolen) Een tweede Ubuntu 22.04-server om te dienen als Secundaire DNS-server, ns2.
• Minstens één extra server. Deze handleiding gaat ervan uit dat je twee extra servers hebt, die zullen worden aangeduid als client servers. Deze client servers moeten worden aangemaakt in hetzelfde datacenter waar je DNS servers zich bevinden.

Op elk van deze servers, configureer een administratieve sudo gebruiker en stel een firewall in door onze Ubuntu 22.04 initiële server setup handleiding te volgen.

Als je niet bekend bent met DNS concepten, raden we aan om ten minste de eerste drie delen van onze Inleiding tot het beheren van DNS te lezen.

Voorbeeldinfrastructuur en -doelen

Voor de doeleinden van dit artikel gaan we ervan uit dat het volgende geldt:

• Je hebt twee servers die worden aangewezen als je DNS naam servers. In deze handleiding worden deze aangeduid als ns1 en ns2.
• U heeft twee extra client servers die gebruik zullen maken van de DNS-infrastructuur die u creëert, aangeduid als host1 en host2 in deze handleiding. U kunt zoveel client servers toevoegen als u wilt.
• Alle van deze servers bevinden zich in hetzelfde datacenter. Deze tutorial gaat ervan uit dat dit datacenter nyc3 wordt genoemd.
• Alle van deze servers hebben privénetwerken ingeschakeld en bevinden zich in het 10.128.0.0/16 subnet (u moet dit waarschijnlijk aanpassen voor uw servers).
• Alle servers zijn verbonden met een project dat draait op example.com. Deze handleiding beschrijft hoe u een intern, privé-DNS-systeem kunt opzetten, zodat u elke domeinnaam kunt gebruiken die u wilt in plaats van example.com. De DNS-servers zullen altijd eerst proberen verzoeken intern te routeren, wat betekent dat ze niet proberen de gegeven domeinnaam op het openbare internet te bereiken. Het gebruik van een domein dat u bezit, kan echter helpen conflicten te voorkomen met publiek routeerbare domeinen.

Met deze aannames in gedachten, zullen de voorbeelden in deze handleiding een naamgevingsschema gebruiken dat is gebaseerd op het subdomein nyc3.example.com om te verwijzen naar het voorbeeld privé subnet of zone. Daarom zal het privé Fully-Qualified Domain Name (FQDN) van host1 host1.nyc3.example.com zijn. In de volgende tabel vindt u de relevante details die in voorbeelden in deze handleiding worden gebruikt:

Tegen het einde van deze handleiding heb je een primaire DNS-server, ns1, en optioneel een secundaire DNS-server, ns2, die als back-up zal dienen.

Terwijl je deze handleiding volgt, zullen er momenten zijn waarop je bepaalde commando’s moet uitvoeren op een specifieke server in deze configuratie. Alle commando’s die moeten worden uitgevoerd op ns1 hebben een blauwe achtergrond, zoals dit:

Op dezelfde manier hebben alle commando’s die moeten worden uitgevoerd op ns2 een rode achtergrond:

En alle commando’s die moeten worden uitgevoerd op een van je client servers hebben een groene achtergrond:

En alle commando’s die moeten worden uitgevoerd op meerdere servers hebben een standaard marineblauwe achtergrond:

Tot slot, wees ervan bewust dat telkens wanneer een opdracht of codeblok tekst bevat die is gemarkeerd zoals dit, dit betekent dat de tekst belangrijk is. Dit type markering wordt in deze handleiding gebruikt om details aan te geven die moeten worden vervangen door uw eigen instellingen of dat de gemarkeerde tekst moet worden aangepast of toegevoegd aan een configuratiebestand. Bijvoorbeeld, als een voorbeeld iets bevat zoals host1.nyc3.example.com, vervang het dan door de FQDN van uw eigen server.

Laten we beginnen met het installeren van BIND op zowel uw primaire als secundaire DNS-servers, ns1 en ns2.

Stap 1 — BIND installeren op DNS-servers

Op beide DNS-servers, ns1 en ns2, werk de apt-pakketcache bij door het volgende in te typen:

sudo apt update

Installeer vervolgens BIND op elke machine:

sudo apt install bind9 bind9utils bind9-doc

DigitalOcean’s privénetwerk maakt uitsluitend gebruik van IPv4. Als dit voor u het geval is, stel BIND dan in op IPv4-modus. Bewerk op beide servers het standaard instellingenbestand van named met uw favoriete teksteditor. Het volgende voorbeeld gebruikt nano:

sudo nano /etc/default/named

Voeg -4 toe aan het einde van de OPTIONS-parameter:

. . .
OPTIONS="-u bind -4"

Sla het bestand op en sluit het af wanneer u klaar bent. Als u nano hebt gebruikt om het bestand te bewerken, kunt u dit doen door op CTRL + X, Y, vervolgens ENTER te drukken.

Herstart BIND om de wijzigingen door te voeren:

sudo systemctl restart bind9

Nu BIND is geïnstalleerd, laten we de primaire DNS-server configureren.

Stap 2 — Configuratie van de Primaire DNS-server

De configuratie van BIND bestaat uit meerdere bestanden die zijn opgenomen in het hoofdconfiguratiebestand, named.conf. Deze bestandsnamen beginnen met named omdat dat de naam is van het proces dat BIND uitvoert (waarbij named staat voor “namedaemon”, zoals in “domain name daemon”). We beginnen met het configureren van het bestand named.conf.options.

Configuratie van het Opties Bestand

Op ns1, open het bestand named.conf.options voor bewerking:

sudo nano /etc/bind/named.conf.options

Boven de bestaande options blok, maak een nieuwe ACL (toegangscontrolelijst) blok genaamd trusted. Hierin zal je een lijst van clients definiëren van waaruit je recursieve DNS-query’s toestaat (d.w.z. je servers die zich in hetzelfde datacenter bevinden als ns1). Voeg de volgende regels toe om ns1, ns2, host1, en host2 toe te voegen aan je lijst van vertrouwde clients, waarbij je ervoor zorgt dat je de voorbeeld private IP-adressen vervangt door die van je eigen servers:

acl "trusted" {
        10.128.10.11;    # ns1 
        10.128.20.12;    # ns2
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

Nu je je lijst van vertrouwde DNS-clients hebt, kun je het options blok bewerken. Dit is momenteel het begin van het blok:

        . . .
};

options {
        directory "/var/cache/bind";
        . . .
}

Onder de directory directive, voeg de gemarkeerde configuratieregels toe (en vervang het juiste ns1 private IP-adres in):

        . . .

};

options {
        directory "/var/cache/bind";
        
        recursion yes;                 # enables recursive queries
        allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
        listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
        allow-transfer { none; };      # disable zone transfers by default

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };

        . . .
};

Merk het forwarders blok op, dat twee IP-adressen bevat: 8.8.8.8 en 8.8.4.4. Dit blok definieert forwarders, een speciaal mechanisme dat BIND gebruikt om het verkeer naar externe nameservers te verminderen. BIND kan ook forwarders gebruiken om query’s toe te staan door servers die geen directe toegang hebben tot het internet. Dit kan helpen om de reacties op deze query’s sneller te maken door de belasting op het lokale netwerk te verminderen.

De twee IP-adressen in dit blok vertegenwoordigen de openbare DNS-resolvers van Google, maar het IP-adres van elke openbare recursieve nameserver zal hier werken. Bijvoorbeeld, je zou het IP-adres van Cloudflare’s DNS-server (1.1.1.1) kunnen gebruiken.

Wanneer je klaar bent, sla dan het bestand named.conf.options op en sluit het. De bovenstaande configuratie specificeert dat alleen jouw eigen servers (de ‘vertrouwde’ servers) in staat zullen zijn om jouw DNS-server te bevragen voor externe domeinen.

Vervolgens zul je jouw DNS-zones specificeren door het bestand named.conf.local te configureren.

Het Configureren van het Lokale Bestand

Op ns1, open het bestand named.conf.local om te bewerken:

sudo nano /etc/bind/named.conf.local

Behalve een paar opmerkingen zal het bestand leeg zijn. Hier zul je je voorwaartse en achterwaartse zones specificeren. DNS-zones duiden een specifiek bereik aan voor het beheren en definiëren van DNS-records. Omdat de voorbeeld domeinen in deze handleiding allemaal binnen de subdomein nyc3.example.com zullen zijn, zullen we dat gebruiken als onze voorwaartse zone. Omdat de privé IP-adressen van onze voorbeeldservers zich elk in de 10.128.0.0/16 IP-ruimte bevinden, zal het volgende voorbeeld een achterwaartse zone opzetten zodat we achterwaartse zoekopdrachten binnen dat bereik kunnen definiëren.

Voeg de voorwaartse zone toe met de volgende regels, waarbij je de zone naam vervangt door die van jou en het prive-IP-adres van de secundaire DNS-server in de allow-transfer directive:

. . .

zone "nyc3.example.com" {
    type primary;
    file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
    allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary
};

Als onze privésubnet 10.128.0.0/16 is, voeg dan de achterwaartse zone toe met de volgende regels (let op dat onze achterwaartse zone naam begint met 128.10 wat de octet omkering is van 10.128):

    . . .
};

zone "128.10.in-addr.arpa" {
    type primary;
    file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
    allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
};

Als uw servers meerdere private subnets bestrijken maar zich in hetzelfde datacenter bevinden, zorg er dan voor dat u een extra zone en zonebestand specificeert voor elk afzonderlijk subnet. Wanneer u klaar bent met het toevoegen van al uw gewenste zones, slaat u het bestand named.conf.local op en sluit u het.

Nu uw zones zijn gespecificeerd in BIND, moet u de overeenkomstige forward- en reverse-zonbestanden maken.

Het maken van het Forward Zone-bestand

Het forward zone-bestand is waar u DNS-records definieert voor forward DNS-lookups. Dat wil zeggen, wanneer de DNS een naamquery ontvangt, bijvoorbeeld host1.nyc3.example.com, zal het in het forward zone-bestand kijken om het overeenkomstige privé-IP-adres van host1 op te lossen.

Maak de map waarin uw zonebestanden zich zullen bevinden. Volgens de configuratie van named.conf.local moet die locatie /etc/bind/zones zijn:

sudo mkdir /etc/bind/zones

We zullen ons voorbeeld forward zone-bestand baseren op het voorbeeld zonebestand db.local. Kopieer het naar de juiste locatie met de volgende commando’s:

sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com

Bewerk nu uw forward zone-bestand:

sudo nano /etc/bind/zones/db.nyc3.example.com

In eerste instantie bevat het inhoud zoals hieronder:

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.      ; delete this line
@       IN      A       127.0.0.1       ; delete this line
@       IN      AAAA    ::1             ; delete this line

Allereerst wil je de SOA-record bewerken. Vervang de eerste `localhost` met ns1’s FQDN, vervolgens vervang je `root.localhost` met `admin.nyc3.example.com`. Elke keer dat je een zonebestand bewerkt, moet je de `Serial` waarde verhogen voordat je het `named`-proces herstart. Hier verhoog je het naar `3`:

. . .
;
$TTL    604800
@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial

                              . . .

Vervolgens verwijder je de drie records aan het einde van het bestand (na de SOA-record). Als je niet zeker weet welke regels je moet verwijderen, zijn ze gemarkeerd met opmerkingen die `delete this line` lezen in het vorige voorbeeld.

Voeg aan het einde van het bestand je nameserver-records toe met de volgende regels (vervang de namen met jouw eigen namen). Let op dat de tweede kolom aangeeft dat dit `NS`-records zijn:

. . .

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

Voeg nu de A-records toe voor je hosts die bij deze zone horen. Dit omvat elke server waarvan je de naam wilt laten eindigen op `.nyc3.example.com` (vervang de namen en privé-IP-adressen). Met behulp van onze voorbeeldnamen en privé-IP-adressen voegen we A-records toe voor ns1, ns2, host1 en host2 zoals dit:

. . .

; name servers - A records
ns1.nyc3.example.com.          IN      A       10.128.10.11
ns2.nyc3.example.com.          IN      A       10.128.20.12

; 10.128.0.0/16 - A records
host1.nyc3.example.com.        IN      A      10.128.100.101
host2.nyc3.example.com.        IN      A      10.128.200.102

Ons uiteindelijke voorbeeldvoorwaartse zonebestand zal de volgende inhoud bevatten:

$TTL    604800
@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                  3     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;
; name servers - NS records
     IN      NS      ns1.nyc3.example.com.
     IN      NS      ns2.nyc3.example.com.

; name servers - A records
ns1.nyc3.example.com.          IN      A       10.128.10.11
ns2.nyc3.example.com.          IN      A       10.128.20.12

; 10.128.0.0/16 - A records
host1.nyc3.example.com.        IN      A      10.128.100.101
host2.nyc3.example.com.        IN      A      10.128.200.102

Sla het bestand `db.nyc3.example.com` op en sluit het.

Latenn we nu doorgaan naar het (de) omgekeerde zonebestand(en).

Het maken van het omgekeerde zonebestand(en)

Omgekeerde zonebestanden zijn waar u DNS PTR-records definieert voor omgekeerde DNS-opzoekingen. Dat wil zeggen, wanneer de DNS een query ontvangt op basis van een IP-adres, bijvoorbeeld 10.128.100.101, zal het in de omgekeerde zonebestand(en) zoeken om de overeenkomstige FQDN op te lossen, bijvoorbeeld host1.nyc3.example.com in dit geval.

Op ns1, voor elke omgekeerde zone die is gespecificeerd in het bestand named.conf.local, maakt u een omgekeerd zonebestand aan. We zullen ons voorbeeld omgekeerde zonebestand(en) baseren op het voorbeeldzonebestand db.127. BIND gebruikt dit bestand om informatie op te slaan voor de lokale loopback-interface; 127 is het eerste octet van het IP-adres dat localhost vertegenwoordigt (127.0.0.1). Kopieer dit bestand naar de juiste locatie met de volgende opdrachten (vervang de bestemmingsbestandsnaam zodat deze overeenkomt met uw definitie van de omgekeerde zone):

sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128

Bewerk het omgekeerde zonebestand dat overeenkomt met de omgekeerde zone(s) gedefinieerd in named.conf.local:

sudo nano /etc/bind/zones/db.10.128

In eerste instantie bevat het bestand inhoud zoals het volgende:

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.      ; delete this line
1.0.0   IN      PTR     localhost.      ; delete this line

Op dezelfde manier als het voorwaartse zonebestand, wilt u het SOA-record bewerken en de seriewaarde verhogen:

@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial

                              . . .

Verwijder nu de twee records aan het einde van het bestand (na het SOA-record). Als u niet zeker weet welke regels u moet verwijderen, zijn ze gemarkeerd met een delete this line-opmerking in het vorige voorbeeld.

Voeg aan het einde van het bestand uw nameserverrecords toe met de volgende regels (vervang de namen door uw eigen namen). Let op dat de tweede kolom aangeeft dat dit NS-records zijn:

. . .

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

Voeg vervolgens PTR-records toe voor al uw servers waarvan de IP-adressen zich op het subnet van het zonebestand bevinden dat u aan het bewerken bent. In ons voorbeeld omvat dit al onze hosts omdat ze zich allemaal op het subnet 10.128.0.0/16 bevinden. Let op dat de eerste kolom bestaat uit de laatste twee octetten van de privé-IP-adressen van uw servers in omgekeerde volgorde. Zorg ervoor dat u namen en privé-IP-adressen vervangt om overeen te komen met uw servers:

. . .

; PTR Records
11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

Uw uiteindelijke voorbeeld van een omgekeerd zonebestand zal lijken op het volgende:

$TTL    604800
@       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
; name servers
      IN      NS      ns1.nyc3.example.com.
      IN      NS      ns2.nyc3.example.com.

; PTR Records
11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

Sla het omgekeerde zonebestand op en sluit het. Als u meer omgekeerde zonebestanden moet toevoegen, herhaalt u dit gedeelte.

U bent klaar met het bewerken van uw bestanden, dus vervolgens kunt u uw bestanden controleren op fouten.

Het controleren van de syntaxis van de BIND-configuratie

Voer de volgende opdracht uit om de syntaxis van de named.conf*-bestanden te controleren:

sudo named-checkconf

Als uw genoemde configuratiebestanden geen syntaxisfouten hebben, worden er geen foutmeldingen weergegeven en keert u terug naar uw shell-prompt. Als er problemen zijn met uw configuratiebestanden, controleer dan de foutmelding en de sectie Configureer Primaire DNS-server, probeer vervolgens opnieuw named-checkconf.

De opdracht named-checkzone kan worden gebruikt om de juistheid van uw zonebestanden te controleren. Het eerste argument geeft de zonenaam aan, en het tweede argument geeft het overeenkomstige zonebestand aan, die beide gedefinieerd zijn in named.conf.local.

Bijvoorbeeld, om de configuratie van de forward zone nyc3.example.com te controleren, voert u de volgende opdracht uit (wijzig de namen om overeen te komen met uw forward zone en bestand):

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

Output
zone nyc3.example.com/IN: loaded serial 3
OK

En om de configuratie van de reverse zone 128.10.in-addr.arpa te controleren, voert u de volgende opdracht uit (wijzig de getallen om overeen te komen met uw reverse zone en bestand):

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

Als al uw configuratie- en zonebestanden geen fouten bevatten, bent u klaar om de BIND-service te herstarten.

Herstarten van BIND

Herstart BIND:

sudo systemctl restart bind9

Als u de UFW-firewall hebt geconfigureerd, open dan de toegang tot BIND door het volgende in te typen:

sudo ufw allow Bind9

Uw primaire DNS-server is nu ingesteld en klaar om te reageren op DNS-vragen. Laten we verder gaan met het configureren van de secundaire DNS-server.

Stap 3 — Configuratie van de Secundaire DNS-server

In de meeste omgevingen is het een goed idee om een secundaire DNS-server in te stellen die reageert op verzoeken als de primaire niet beschikbaar is. Gelukkig is het configureren van de secundaire DNS-server veel minder ingewikkeld dan het opzetten van de primaire.

Op ns2, bewerk het bestand named.conf.options:

sudo nano /etc/bind/named.conf.options

Voeg bovenaan het bestand de ACL toe met de privé-IP-adressen van al uw vertrouwde servers:

acl "trusted" {
        10.128.10.11;   # ns1
        10.128.20.12;   # ns2 
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

Onder de directory-richtlijn voegt u de volgende regels toe:

    . . .

        recursion yes;
        allow-recursion { trusted; };
        listen-on { 10.128.20.12; };      # ns2 private IP address
        allow-transfer { none; };          # disable zone transfers by default

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };

    . . .

Sla het bestand named.conf.options op en sluit het af. Dit bestand moet identiek zijn aan het named.conf.options-bestand van ns1, behalve dat het geconfigureerd moet zijn om te luisteren op het privé-IP-adres van ns2.

Bewerk nu het bestand named.conf.local:

sudo nano /etc/bind/named.conf.local

Definieer secundaire zones die overeenkomen met de primaire zones op de primaire DNS-server. Let op dat het type secondary is, het bestand geen pad bevat, en er een primaries-richtlijn is die moet worden ingesteld op het privé-IP-adres van de primaire DNS-server. Als u meerdere omgekeerde zones hebt gedefinieerd in de primaire DNS-server, zorg er dan voor dat u ze hier allemaal toevoegt:

zone "nyc3.example.com" {
    type secondary;
    file "db.nyc3.example.com";
    primaries { 10.128.10.11; };  # ns1 private IP
};

zone "128.10.in-addr.arpa" {
    type secondary;
    file "db.10.128";
    primaries { 10.128.10.11; };  # ns1 private IP
};

Sla nu het bestand named.conf.local op en sluit het af.

Voer de volgende opdracht uit om de geldigheid van uw configuratiebestanden te controleren:

sudo named-checkconf

Als deze opdracht geen fouten retourneert, herstart BIND:

sudo systemctl restart bind9

Sta vervolgens DNS-verbindingen naar de server toe door de UFW-firewallregels aan te passen:

sudo ufw allow Bind9

Met dat, heb je nu primaire en secundaire DNS-servers voor de naam- en IP-adresresolutie van het particuliere netwerk. Nu moet je je clientservers configureren om je privé-DNS-servers te gebruiken.

Stap 4 — Configuratie van DNS-clients

Voordat al je servers in de trusted-ACL je DNS-servers kunnen bevragen, moet je elk van hen configureren om ns1 en ns2 als nameservers te gebruiken.

Als je clientservers draaien op Ubuntu, moet je ontdekken welk apparaat is gekoppeld aan je privénetwerk. Je kunt dit doen door het privé-subnet te bevragen met het ip address-commando. Voer het volgende commando uit op elk van je clientmachines, waarbij je het gemarkeerde subnet vervangt door je eigen subnet:

ip address show to 10.128.0.0/16

Output
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    altname enp0s4
    altname ens4
    inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
       valid_lft forever preferred_lft forever

In dit voorbeeld is de privé-interface eth1. De voorbeelden in deze sectie verwijzen naar eth1 als de privé-interface, maar je moet deze voorbeelden aanpassen aan de privéinterfaces van je eigen servers.

Op Ubuntu 22.04 wordt networking geconfigureerd met Netplan, een abstractielaag waarmee je gestandaardiseerde netwerkconfiguratie kunt schrijven en toepassen op compatibele backend-netwerksoftware. Om DNS te configureren, moet je een Netplan-configuratiebestand schrijven.

Maak een nieuw bestand aan in /etc/netplan met de naam 00-private-nameservers.yaml:

sudo nano /etc/netplan/00-private-nameservers.yaml

Binnenin, voeg de volgende inhoud toe. U moet de interface van het privénetwerk aanpassen, de adressen van uw DNS-servers ns1 en ns2, en de DNS-zone:

network:
    version: 2
    ethernets:
        eth1:                                    # Private network interface
            nameservers:
                addresses:
                - 10.128.10.11                # Private IP for ns1
                - 10.132.20.12                # Private IP for ns2
                search: [ nyc3.example.com ]    # DNS zone

Sla het bestand op en sluit het af wanneer u klaar bent.

Vervolgens vertelt u Netplan om te proberen het nieuwe configuratiebestand te gebruiken door netplan try te gebruiken. Als er problemen zijn die leiden tot verlies van netwerkconnectiviteit, zal Netplan de wijzigingen automatisch terugdraaien na een time-out:

sudo netplan try

Output
Warning: Stopping systemd-networkd.service, but it can still be activated by:
  systemd-networkd.socket
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 120 seconds

Als de teller onderaan correct wordt bijgewerkt, is de nieuwe configuratie ten minste functioneel genoeg om uw SSH-verbinding niet te verbreken. Druk op ENTER om de nieuwe configuratie te accepteren.

Controleer nu of de DNS-resolver van het systeem om te bepalen of uw DNS-configuratie is toegepast:

sudo resolvectl status

Scroll naar beneden totdat u de sectie voor uw privénetwerkinterface vindt. De privé-IP-adressen voor uw DNS-servers moeten eerst worden vermeld, gevolgd door enkele fallback-waarden. Uw domein moet worden vermeld na DNS Domain:

Output
. . .

Link 3 (eth1)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.3
       DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.3 67.207.67.2
        DNS Domain: nyc3.example.com

Uw Ubuntu-client is nu geconfigureerd om uw interne DNS-servers te gebruiken.

Stap 5 — Clients testen

Gebruik nslookup om te testen of uw clients uw nameservers kunnen bevragen. Dit zou moeten lukken op alle clients die u hebt geconfigureerd en die zich in de trusted-ACL bevinden.

U kunt beginnen met het uitvoeren van een voorwaartse opzoeking.

Voorwaartse Opzoeking

Om een voorwaartse opzoeking uit te voeren en het IP-adres van host1.nyc3.example.com op te halen, voert u het volgende commando uit:

nslookup host1

Het opvragen van host1 wordt uitgebreid naar host1.nyc3.example.com omdat de search-optie is ingesteld op uw privé-subdomein, en DNS-opvragingen zullen eerst op dat subdomein proberen te zoeken voordat ze elders naar de host zoeken. Het vorige commando zal output retourneren zoals het volgende:

Output
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   host1.nyc3.example.com
Address: 10.128.100.101

Vervolgens kunt u omgekeerde opzoekingen controleren.

Omgekeerde Opzoeking

Om de omgekeerde opzoeking te testen, bevraag de DNS-server met het privé-IP-adres van host1:

nslookup 10.128.100.101

Dit zou output zoals het volgende moeten retourneren:

Output
11.10.128.10.in-addr.arpa   name = host1.nyc3.example.com.

Authoritative answers can be found from:

Als alle namen en IP-adressen naar de juiste waarden verwijzen, betekent dit dat uw zonebestanden correct zijn geconfigureerd. Als u onverwachte waarden ontvangt, moet u de zonebestanden op uw primaire DNS-server controleren (bijv. db.nyc3.example.com en db.10.128).

Als laatste stap zal deze handleiding uitleggen hoe u uw zone-records kunt onderhouden.

Stap 6 — DNS-records onderhouden

Nu u een werkende interne DNS hebt, moet u uw DNS-records onderhouden zodat ze nauwkeurig uw serveromgeving weerspiegelen.

Een host toevoegen aan DNS

Telkens wanneer u een host aan uw omgeving toevoegt (in hetzelfde datacenter), wilt u deze aan DNS toevoegen. Hier is een lijst met stappen die u moet nemen:

Primaire naamserver

• Forward zonebestand: Voeg een A-record toe voor de nieuwe host, verhoog de waarde van Serial
• Reverse zonebestand: Voeg een PTR-record toe voor de nieuwe host, verhoog de waarde van Serial
• Voeg het privé-IP-adres van uw nieuwe host toe aan de trusted-ACL (named.conf.options)

Test uw configuratiebestanden:

sudo named-checkconf
sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

Vervolgens herladen BIND:

sudo systemctl reload bind9

Uw primaire server moet nu geconfigureerd zijn voor de nieuwe host.

Secundaire Naamserver

• Voeg het privé IP-adres van uw nieuwe host toe aan de trusted ACL (named.conf.options)

Controleer de syntax van de configuratie:

sudo named-checkconf

Vervolgens herladen BIND:

sudo systemctl reload bind9

Uw secundaire server zal nu verbindingen van de nieuwe host accepteren.

Configureer Nieuwe Host om Uw DNS te Gebruiken

• Configureer /etc/resolv.conf om uw DNS-servers te gebruiken
• Test met behulp van nslookup

Een Host Verwijderen uit DNS

Als u een host uit uw omgeving verwijdert of deze gewoon uit DNS wilt halen, verwijder dan gewoon alles wat is toegevoegd toen u de server aan DNS toevoegde (d.w.z. het tegenovergestelde van de vorige stappen).

Conclusie

Nu kunt u verwijzen naar de privénetwerkinterfaces van uw servers op naam, in plaats van op IP-adres. Dit maakt het configureren van services en applicaties eenvoudiger omdat u niet langer de privé-IP-adressen hoeft te onthouden, en de bestanden zullen minder moeilijk te lezen en te begrijpen zijn. Ook kunt u nu uw configuraties wijzigen om naar een nieuwe server te wijzen op één plek, uw primaire DNS-server, in plaats van meerdere gedistribueerde configuratiebestanden te moeten bewerken, wat het onderhoud optimaliseert.

Zodra u uw interne DNS hebt ingesteld en uw configuratiebestanden privé-FQDN’s gebruiken om netwerkverbindingen aan te geven, is het essentieel dat uw DNS-servers goed worden onderhouden. Als ze beide niet beschikbaar zijn, zullen uw services en applicaties die erop vertrouwen niet goed functioneren. Daarom wordt aanbevolen om uw DNS in te stellen met minstens één secundaire server, en om werkende back-ups van allemaal te onderhouden.

Als u meer wilt weten over DNS, raden we u aan ons artikel Een Inleiding tot DNS Terminologie, Componenten en Concepten te bekijken.