cmNOG wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

Source : https://nsrc.org/workshops/2023/icann-tr-dnssec/dns/materials/labs/en/New-lab-setup-configure-zone.html






Lab Topology (Group 32)

lab-topo-resolver-authoritative

  DEVICE NAME        IPv4 ADDRESS              IPv6 ADDRESS
+--------------+-----------------------+-----------------------------+
| grp32-cli     | 100.100.32.2 (eth0)    | fd89:59e0:32::2 (eth0)       |
+--------------+-----------------------+-----------------------------+
| grp32-ns1     | 100.100.32.130 (eth0)  | fd89:59e0:32:128::130 (eth0) |
+--------------+-----------------------+-----------------------------+
| grp32-ns2     | 100.100.32.131 (eth0)  | fd89:59e0:32:128::131 (eth0) |
+--------------+-----------------------+-----------------------------+
| grp32-resolv1 | 100.100.32.67 (eth0)   | fd89:59e0:32:64::67 (eth0)   |
+--------------+-----------------------+-----------------------------+
| grp32-resolv2 | 100.100.32.68 (eth0)   | fd89:59e0:32:64::68 (eth0)   |
+--------------+-----------------------+-----------------------------+
| grp32-rtr     | 100.64.1.32 (eth0)     | fd89:59e0:32::1 (eth1)       |
|              | 100.100.32.65 (eth2)   | fd89:59e0:32:64::1 (eth2)    |
|              | 100.100.32.193 (eth4)  | fd89:59e0:32:192::1 (eth4)   |
|              | 100.100.32.129 (eth3)  | fd89:59e0:32:128::1 (eth3)   |
|              | 100.100.32.1 (eth1)    | fd89:59e0:0:1::32 (eth0)     |
+--------------+-----------------------+-----------------------------+
| grp32-soa     | 100.100.32.66 (eth0)   | fd89:59e0:32:64::66 (eth0)   |
+--------------+-----------------------+-----------------------------+

During this practice we are only going to access the following equipment:

    grp32-cli : client
    grp32-soa : hidden authoritative servers (primary)
    grp32-ns1 & grp32-ns2 : secondary authoritative servers

NOTE: In all this lab, be carefull to always replace 32 by your Group number in IP addresses, server name and any other place where required. Same for yaounde to be replace by the domain name registered for the class.
Configure primary authoritative server (BIND)
Intro

We are going to configure a hidden authoritative server and create the authoritative zone grp32.yaounde.te-labs.training.
What we already know

Our "parent" (yaounde.te-labs.training) has already created the following in its own zone:

; grp32
grp32             NS          ns1.grp32.yaounde.te-labs.training.
grp32             NS          ns2.grp32.yaounde.te-labs.training.
; ---Placeholder for grp32 DS record (DO NOT MANUALLY EDIT THIS LINE)---
ns1.grp32         A           100.100.32.130
ns1.grp32         AAAA        fd89:59e0:32:128::130
ns2.grp32         A           100.100.32.131
ns2.grp32         AAAA        fd89:59e0:32:128::131

Our zone configuration must be compatible with this.
Setting the authoritative zone

We use the container "SOA" (hidden primary authoritative) [grp32-soa]

We go to the /etc/bind directory and clone the db.empty file into a new directory that we create for our zones:

$ sudo mkdir -p /etc/bind/zones
$ cp db.empty zones/db.grp32

The content of the zone should be at the least:

; grp32 

$TTL    300
@       IN      SOA     grp32.yaounde.te-labs.training. dnsadmin.yaounde.te-labs.training. (                                            
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; E32pire
                          86400 )       ; Negative Cache TTL
;

; grp32 
@             NS           ns1.grp32.yaounde.te-labs.training.
@             NS           ns2.grp32.yaounde.te-labs.training.

ns1         A           100.100.32.130
ns1         AAAA        fd89:59e0:32:128::130
ns2         A           100.100.32.131
ns2         AAAA        fd89:59e0:32:128::131

    You can add more records as you like.

When we are done, it is important to verify the zone file format. Use named-checkzone command with appropriate parameters to do that.

In the configuration file /etc/bind/named.conf.local we put the statement "zone":

zone "grp32.yaounde.te-labs.training" {                                                                               
        type master;                                                                                                  
        file "/etc/bind/zones/db.grp32";                                                                                     
        allow-transfer { any; };                                                                                      
}; 

We restart the server and verify:

rndc reload

root@soa:/etc/bind# dig @localhost soa grp32.yaounde.te-labs.training.                                                

; <<>> DiG 9.16.1-Ubuntu <<>> @localhost soa grp32.yaounde.te-labs.training.
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64339
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 270e2c46ed443c1c01000000609c59f04ba85015ff71998d (good)
;; QUESTION SECTION:
;grp32.yaounde.te-labs.training.        IN      SOA

;; ANSWER SECTION:
grp32.yaounde.te-labs.training. 30 IN   SOA     grp32.yaounde.te-labs.training. dnsadmin.yaounde.te-labs.training. 1 604800 86400 2419200 86400

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed May 12 22:42:56 UTC 2021
;; MSG SIZE  rcvd: 170

Configure secondary authoritative servers

These servers are the ones that e32pose our zone publicly (so they will be open-to-all servers).
We configure the first server ns1 [ns1.grp32]

Server ns1 runs BIND (from ISC)

We go to the /etc/bind directory and create a file that will contain our zone file in the nameserver:

$ sudo mkdir -p /etc/bind/zones
$ touch /etc/bind/zones/db.grp32.slave

To do this, in the /etc/bind/named.conf.local file we configure the following parameters:

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "grp32.yaounde.te-labs.training" {
        type slave;
        file "/etc/bind/zones/db.grp32.slave";
        masters { 100.100.32.66; };
};

We verify the configuration and if there are no errors we restart the server:

# named-checkconf
# systemctl restart bind9

We verify that it restarted correctly:

# systemctl status bind9

● named.service - BIND Domain Name Server
     Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/service.d
             └─l32c.conf
     Active: active (running) since Thu 2021-05-13 04:25:43 UTC; 9s ago
       Docs: man:named(8)
   Main PID: 739 (named)
      Tasks: 50 (limit: 152822)
     Memory: 103.9M
     CGroup: /system.slice/named.service
             └─739 /usr/sbin/named -f -u bind

May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: all zones loaded
May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: running
May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: zone grp32.yaounde.te-labs.training/IN: Transfer started.
May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: transfer of 'grp32.yaounde.te-labs.training/IN' from 100.100.2.66#53: connec>
May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: zone grp32.yaounde.te-labs.training/IN: transferred serial 1
May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: transfer of 'grp32.yaounde.te-labs.training/IN' from 100.100.2.66#53: Transf>
May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: transfer of 'grp32.yaounde.te-labs.training/IN' from 100.100.2.66#53: Transf>
May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: zone grp32.yaounde.te-labs.training/IN: sending notifies (serial 1)
May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer com>
May 13 04:25:43 ns1.grp32.yaounde.te-labs.training named[739]: resolver priming query complete

We now configure the server ns2 [ns2.grp32]

Server ns2 runs NSD (from NLnet Labs)

To do this, in the /etc/nsd/nsd.conf file we configure the following parameters:

# NSD configuration file for Debian.
#
# See the nsd.conf(5) man page.
#
# See /usr/share/doc/nsd/e32amples/nsd.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/nsd/nsd.conf.d directory.

include: "/etc/nsd/nsd.conf.d/*.conf"

server:
    zonesdir: "/etc/nsd"

pattern:
    name: "fromprimary"
    allow-notify: 100.100.32.66 NOKEY
    request-32fr: A32FR 100.100.32.66 NOKEY

zone:
    name: "grp32.yaounde.te-labs.training"
    zonefile: "grp32.yaounde.te-labs.training.forward"
    include-pattern: "fromprimary"

We verify the configuration and if there are no errors restart the server:

# nsd-checkconf /etc/nsd/nsd.conf
# systemctl restart nsd

We verify that It restarted correctly:

# systemctl status nsd

● nsd.service - Name Server Daemon
     Loaded: loaded (/lib/systemd/system/nsd.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/service.d
             └─l32c.conf
     Active: active (running) since Thu 2021-05-13 05:02:35 UTC; 1min 22s ago
       Docs: man:nsd(8)
   Main PID: 638 (nsd)
      Tasks: 3 (limit: 152822)
     Memory: 114.5M
     CGroup: /system.slice/nsd.service
             ├─638 /usr/sbin/nsd -d
             ├─639 /usr/sbin/nsd -d
             └─640 /usr/sbin/nsd -d

May 13 05:02:35 ns2.grp32.yaounde.te-labs.training systemd[1]: Starting Name Server Daemon...
May 13 05:02:35 ns2.grp32.yaounde.te-labs.training nsd[638]: nsd starting (NSD 4.1.26)
May 13 05:02:35 ns2.grp32.yaounde.te-labs.training nsd[638]: [2021-05-13 05:02:35.865] nsd[638]: notice: nsd starting (NSD 4.1.26)
May 13 05:02:35 ns2.grp32.yaounde.te-labs.training nsd[639]: nsd started (NSD 4.1.26), pid 638
May 13 05:02:35 ns2.grp32.yaounde.te-labs.training nsd[639]: [2021-05-13 05:02:35.922] nsd[639]: notice: nsd started (NSD 4.1.26), pid 638
May 13 05:02:35 ns2.grp32.yaounde.te-labs.training systemd[1]: Started Name Server Daemon.

Test your zone configuration and propagation.
Use dig tool to test the domain

We will now use dig tool to verify our own zone configuration and propagation, then do the same for one or two other groups in the class and share comments. From your client, run the following dig queries. All should return answer otherwise you should review your configurations before continiuing:

    dig soa grp32.yaounde.te-labs.training. @100.100.32.66
    dig soa grp32.yaounde.te-labs.training. @100.100.32.130
    dig soa grp32.yaounde.te-labs.training. @100.100.32.131
    dig soa grp32.yaounde.te-labs.training. @100.100.32.131 +short
    dig soa grp32.yaounde.te-labs.training. @100.100.32.131 +multi
    dig NS grp32.yaounde.te-labs.training. @100.100.32.130
    dig NS grp32.yaounde.te-labs.training. @100.100.32.130 +multi

Zone transfer

Now we try to do a manual zone transfer using ns1, ns2 and SOA server IP address from our client machine. What do you notice ?

How can we protect our zone file to prevent people get its entire content ?
Fi32 the open zone transfer

Apply a change to fi32 the issue discussed above.
Then, test again the zone transfer. Is the issue resolved ?
A moment of refle32ion

Is your hidden SOA really "hidden" ? Try to query it from any other server and confirm wheather it replies or not. After this test, can you confirm if it is really "hidden" ?
How to make it a real "hidden" SOA ? Do not forget that for troubleshooting purpose, you may always need to query it from some e32ternal IP addresses.
Discuss with other participants and propose a solution.

Apply the solution after you have agreed on a consensus.




Source : https://nsrc.org/workshops/2023/icann-tr-dnssec/dns/materials/labs/en/New-lab-setup-configure-zone.html
cmNOG wiki

User Tools

Site Tools

Page Tools
