1,576
edits
Changes
m
Protected "OPS535-online-L8": OER transfer ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))
* For Investigation 3, you should do it on your VM2 in the Virtual Lab.
==Investigation 1: Performing queries using DNSSecDNSSEC==
Perform the following steps on your own pri-dns CentOS 8.x at home:
<ol>
</li>
<li>Once you have a response, can you be sure it is reliable?
*Re-run the previous dig command, but this time add +dnssec to request authentication of the results using DNSSecDNSSEC.
<source>
[rchan@pri-dns labs]$ dig senecacollege.ca @1.1.1.1 +dnssec
</source>
*Notice the addition of the <b>flags: do</b> flag (<font color='blue'>DNSSec DNSSEC Ok</font>, that is the server we queried is willing to perform authentication), but no other difference in output. This information is '''not''' authenticated.
</li>
<li>Now we will run a query that does get authenticated:
</source>
*Notice that in addition to the <b>do</b> flag, the answer to this query also has an <b>ad</b> flag (<font color='blue'>Authenticated Data</font>), along with extra information in the answer itself (the <b>RRSIG</b> record). This result '''is''' authenticated.
*If you want to see this result without the DNSSec DNSSEC information, simply re-run the query without the +dnssec request.
</li>
</ol>
==Investigation 2: Configuring DNSSec DNSSEC on a Recursive Server==
Perform the following steps as root on your co-nfs VM at home:
<ol>
*Again, note the <b>do</b> and <b>ad</b> flags, along with the RRSIG record (and similar data for the nameservers in the isc.org domain).
</li>
<li>Your server is now able to request DNSSec DNSSEC records from other zones, and authenticate them.</li>
</ol>
==Investigation 3: Configuring DNSSec DNSSEC on an Authoritative Server==
Perform the following steps as sudoer or root on your VM2 in the virtual lab:
<ol>
<li>Now that you know how to configure a recursive nameserver to perform authentication of other domains (so long as they are configured to provide authentication), it is time to configure your own domain to support authentication using DNSSecDNSSEC.</li>
<li>First you need to make sure that the named service is able to modify the master zone files, as it will need to do so in order to add the RRSIG records it generates for you. This requires two things:
*The SELinux boolean <b>named_write_master_zones</b> must be set to on to (this should have already been done in a previous lab, and is currently the default setting).
*Double check that the value you put in the key-directory parameter matches the directory you created your key files in.
</li>
<li>Make sure the dnssec-enable parameter in /etc/named.conf is set to yes so that your server will provide the extra DNSSec DNSSEC records if a client requests them.
*This is the default value, so unless you took it out, it should already be there.
*Note that this parameter is different from the dnssec-validation parameter which only controls whether or not your server will request those records from other servers when a client asks for them.
</li>
<li>Restart the named service. If you have dynamic DNS set up from the earlier labs, you can use named-journalprint to view the journal files for your zones in order to see the new records.</li>
<li>In order to confirm that your server will provide the extra records when requested, use the dig command to obtain a zone transfer (including the DNSSec DNSSEC records) from your server:
*Making sure to replace <yourzone> with the name of your zone, and <ip-of-server> with the ip address of your server.
<source>dig AXFR <yourzone> @<ip-of-server></source></li>
==Completing the Lab==
Your DNS server is now capable of performing recursive queries using DNSSec DNSSEC when client machines request it. It has also been configured to provide the extra DNSSec DNSSEC records when clients request them.Note that it is not yet truly providing DNSSec DNSSEC answers, as it is not being authenticated through the domain above yours.
Follow the instructions on blackboard to submit the lab.