Show page

Differences

This shows you the differences between two versions of the page.

--- scgc:laboratoare:01 [2018/02/27 16:53]
victor.ciurel [2. DNS server] add localhost to DNS listeners for master VM
+++ scgc:laboratoare:01 [2021/10/27 14:07] (current)
maria.mihailescu
@@ Line 1: / Line 1: @@
-====== Laboratory 01. DNS ======
+====== Naming Services: DNS ======
 ===== Lab Setup =====
-  * We will be using two virtual machines in the [[http://cloud.curs.pub.ro/|faculty's cloud]].
+  * We will be using two virtual machines in the [[http://cloud.grid.pub.ro/|faculty's cloud]].
-  * When creating a virtual machine follow the steps in this [[https://cloud.curs.pub.ro/about/tutorial-for-students/|tutorial]].
   * Create two VMs (one will be our DNS master server and one will be our DNS slave server)
   * When creating a virtual machine in the Launch Instance window:
     * Select **Boot from image** in **Instance Boot Source** section
-    * For the master VM select **Debian 8.6** in **Image Name** section
+    * For the master VM select **Debian 10.3** in **Image Name** section
     * For the slave VM select **Centos 7** in **Image Name** section
+    * Select the **m1.small** flavor for both VMs.
+  * The usernames for connecting to the VMs are:
+    * ''debian'' for **Debian 10.3**
+    * ''student'' for **CentOS 7**
+  * For ease of use we recommend adding entries in the ''/etc/hosts'' file corresponding to the slave and master VMs
+    * ''<ip_master> master''
+    * ''<ip_slave> slave''
+    * These two lines will allow using ''master'' instead of the IP address of the master VM for clarity. Likewise, we can use ''slave'' instead of the IP address of the slave VM.
 ===== Tasks ======
-==== 1. DNS resolvers ====
+==== 1. [15p] DNS resolvers ====
 In this task we will examine how we ca use two DNS resolvers to query DNS servers. The two DNS resolvers we will use are **host** and **dig**. However before we use them, we first have to install them.
@@ Line 20: / Line 26: @@
 [...]
 </code>
-=== 1.1 host ===
+=== 1.1 [5p] host ===
 Next, we find out the IP address of a website using **host**.
 <code>
@@ Line 113: / Line 119: @@
 </code>
-=== 1.2 dig ===
+=== 1.2 [10p] dig ===
 Now use **dig** to get the detailed information, the IP address and specific records for a website. Also, use dig to query the Google DNS server ''8.8.8.8''
@@ Line 119: / Line 125: @@
 It is noteworthy, that dig and host do not use ''/etc/nsswitch.conf'' for querying DNS servers and they do not use the system's DNS resolver, which is usually a library. We can see this from the following commands:
 <code>
-root@master:~# strace -e open host acs.pub.ro
+root@master:~# strace -e openat host acs.pub.ro
 [...]
-open("/etc/resolv.conf", O_RDONLY)      = 6
+openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY)      = 6
 acs.pub.ro has address 141.85.227.151
 acs.pub.ro mail is handled by 10 mx.acs.pub.ro.
 [...]
-root@master:~# strace -e open ping -c 1 acs.pub.ro
+root@master:~# strace -e openat ping -c 1 acs.pub.ro
 [...]
-open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4
+openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4
-open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4
+openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4
-open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 4
+openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 4
 [...]
-open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 4
+openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 4
-open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
+openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
-open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
+openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
-open("/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 4
+openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 4
-open("/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 4
+openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 4
 PING acs.pub.ro (141.85.227.151) 56(84) bytes of data.
-open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
+openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
 bytes from acs.pub.ro (141.85.227.151): icmp_seq=1 ttl=62 time=0.688 ms
@@ Line 146: / Line 152: @@
 We can see that host will use the ''/etc/resolv.conf'' file directly, while the ping command reads the resolver configuration first: the ''/etc/nsswitch.conf'' and the ''/etc/resolv.conf'' file are opened and then calls are made to the resolving library (libresolv.so.2).
 </note>
-==== 2. DNS server ====
+==== 2. [30p] DNS server ====
 Now that we have seen how we can query DNS servers, let's configure our very own DNS server on the master VM using **bind**.
@@ Line 162: / Line 168: @@
 We will set up the master VM to respond to queries about our very own domain. Use ''<your_last_name>.ro'' as your very own domain name. In the following examples we will be using ''scgc.ro'' as our domain.
-=== 2.1 Simple DNS configuration ===
+=== 2.1 [10p] Simple DNS configuration ===
 First, we will configure our DNS server to listen for queries received from outside the server. For this we have to add the following line to the ''/etc/bind/named.conf.options'' file:
@@ Line 193: / Line 199: @@
 	type master;
 	file "/etc/bind/db.scgc.ro"; # zone file path
-}
+};
 </file>
@@ Line 263: / Line 269: @@
 </file>
-=== 2.2 Testing our configuration ===
+=== 2.2 [10p] Testing our configuration ===
 Now that we have the a minimal configuration, let us check that it works. Run the following command to check the syntax of the named.conf* files:
@@ Line 287: / Line 293: @@
 Now we should be able to test our DNS server. We will be using //host//, however feel free to use //dig// or any other command to test your server:
 <code>
-root@master:~# host www.scgc.ro 10.9.107.151
+root@master:~# host www.scgc.ro localhost
 Using domain server:
 Name: 10.9.107.151
@@ Line 294: / Line 300: @@
 www.scgc.ro has address 10.9.107.151
-root@master:~# host -t ns scgc.ro 10.9.107.151
+root@master:~# host -t ns scgc.ro localhost
 Using domain server:
 Name: 10.9.107.151
@@ Line 301: / Line 307: @@
 scgc.ro name server ns1.scgc.ro.
-root@master:~# host ns1.scgc.ro 10.9.107.151
+root@master:~# host ns1.scgc.ro localhost
 Using domain server:
 Name: 10.9.107.151
@@ Line 312: / Line 318: @@
 Now let's try to query from outside the server. We will test that the **slave** VM will receive the same response(replace with the appropriate name and IP address):
 <code>
-[root@slave ~]# host www.scgc.ro 10.9.107.151
+[root@slave ~]# host www.scgc.ro master
 Using domain server:
 Name: 10.9.107.151
@@ Line 327: / Line 333: @@
 </note>
-=== 2.3 Additional records ===
+=== 2.3 [10p] Additional records ===
 Add another NS record to the zone corresponding to the slave IP address and two MX records(one for the master with priority 10 and one for the slave with priority 20). Restart your BIND server and test your configurations.
-==== 3. DNS zone transfer ====
+==== 3. [15p] Fine tuning DNS servers ====
+=== 3.1 [10p] Allow only local recursive queries ===
+By default, bind will make recursive queries for any unknown query received. Recursive queries are quite costly, therefore they should only be allowed explicitly. We can check this by quering for ''google.com'' from the master and slave VMs:
+<code>
+root@master:~# host google.com localhost
+Using domain server:
+Name: 10.9.107.151
+Address: 10.9.107.151#53
+Aliases:
+google.com has address 216.58.214.206
+google.com has IPv6 address 2a00:1450:400d:802::200e
+google.com mail is handled by 40 alt3.aspmx.l.google.com.
+google.com mail is handled by 50 alt4.aspmx.l.google.com.
+google.com mail is handled by 30 alt2.aspmx.l.google.com.
+google.com mail is handled by 10 aspmx.l.google.com.
+google.com mail is handled by 20 alt1.aspmx.l.google.com.
+[root@slave ~]# host google.com master
+Using domain server:
+Name: 10.9.107.151
+Address: 10.9.107.151#53
+Aliases:
+google.com has address 216.58.214.206
+google.com has IPv6 address 2a00:1450:400d:802::200e
+google.com mail is handled by 10 aspmx.l.google.com.
+google.com mail is handled by 30 alt2.aspmx.l.google.com.
+google.com mail is handled by 20 alt1.aspmx.l.google.com.
+google.com mail is handled by 40 alt3.aspmx.l.google.com.
+google.com mail is handled by 50 alt4.aspmx.l.google.com.
+</code>
+In order to restrict who can make recursive queries, we have to edit the ''/etc/bind/named.conf.options'' file and add the following lines:
+<file>
+acl goodguys { 10.9.107.151; 127.0.0.1; };
+options {
+[...]
+        allow-recursion { goodguys; };
+        recursion yes;
+[...]
+};
+</file>
+Now, if we query again for ''google.com'', from the master VM the query should suceed and from the slave VM it should now fail.
+<code>
+[root@slave ~]# host google.com master
+Using domain server:
+Name: 10.9.107.151
+Address: 10.9.107.151#53
+Aliases:
+Host google.com.cloud.grid.pub.ro not found: 5(REFUSED)
+</code>
+=== 3.2 [5p] Allow slave recursive queries ===
+Change the ''/etc/bind/named.conf.options file'' on the master VM to allow recursive queries from the slave VM.
+==== 4. [20p] DNS zone transfer ====
 We now want to configure the ''lab1.scgc.ro'' on the slave DNS server(replace with your last name instead of scgc). This domain will be transfered from the master to the slave(DNS zone transfer). In order to correctly configure a zone transfer, we must follow these steps:
@@ Line 337: / Line 409: @@
   - We transfer the ''lab1.scgc.ro'' domain from the master VM to the slave VM
-=== 3.1 Setup master DNS server ===
+=== 4.1 [10p] Setup master DNS server ===
-Configure a DNS server on the client VM similarly to the master VM server, which will answer for queries about ''lab1.scgc.ro''. Your DNS zone must have at least an A record and a NS record for this exercise.
+Configure a new DNS zone on the master VM similarly to the previous one, which will answer for queries about ''lab1.scgc.ro''. Your DNS zone must have at least an A record and a NS record for this exercise.
-=== 3.2 Zone transfer ===
+=== 4.2 [10p] Zone transfer ===
 The slave VM has a Centos 7 operating system, which has some differences in the setup of the DNS server.
-To install the *bind* use the following command:
+To install **BIND** use the following command:
 <code>
 yum install bind
@@ Line 352: / Line 424: @@
 On Red-Hat-based distributions bind will have the following characteristics:
-  * Service name: ''named''
+  * Service name: **named**
-  * Main configuration and zone names file: ''/etc/named.conf''
+  * Main configuration and zone names file: **/etc/named.conf**
-  * Default zone file location: ''/var/named/''
+  * Default zone file location: **/var/named/**
 In order to transfer the zone from the master server, we need to make the following configurations:
-  * on the master VM add the following line in the ''/etc/bind/named.conf.local'' file for the zone created in the preceding subtask (3.1):
+  * on the master VM add the following line in the ''/etc/bind/named.conf.local'' file for the zone created in the preceding subtask (4.1):
 <file>
     allow-transfer { 10.9.107.152; }; // replace with the slave VM IP address
@@ Line 457: / Line 529: @@
 The command has to produce similar output when run on the master VM.
-==== 4. DNSSEC ====
+==== 5. [20p] Paired DNS zone transfer ====
+Pair up with one of your peers. Each student will make the necessary changes in order for his master DNS server to be delegated the DNS zone of his colleague's master DNS server. You should be able to answer for queries about each others DNS domains.
+==== 6. [BONUS - 20p] DNSSEC ====
+DNS is vulnerable to MITM attacks. An attacker can pretend to be a DNS server and supply an unsuspecting victim with the wrong IP address for a URL. In order to combat this, DNSSEC can be used and configured to validate the identity of the DNS server. Using the instructions from [[https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2|here]], setup DNSSEC between the master and slave VM.

Resources

Laboratories

scgc/laboratoare/01.1519743185.txt.gz · Last modified: 2018/02/27 16:53 by victor.ciurel

Show page Old revisions

Media Manager Back to top