1,576
edits
Changes
m
bindkeys-file "/etc/named.iscdlv.key";
www.isc.org. 60 IN A 149.20.641.6966www.isc.org. 60 IN RRSIG A 5 3 13 2 60 2018112823333420181029233334 19923 20210414183037 20210315174752 27566 isc.org.EzPGoD0DDKUONuWUhXsNqW0xt1q3l8Nwg8Ec3SW9QZafwyQDYj9XA/axENwkfw6IP3mlRBFNz9TDt/dZldecEixafcdUiPMay+4mUQ8D8vUF0 gm1MauongXELJ/Fd4ch3UIQ1oKfHYUtAsev7aVjwbisM5HgHSjGtBMWZngzYZ7F2zv/mBTmy+uVogyBKuXHawR13il4fY6Z68qTZpaq8gH9jKqpPJYomruSxYFZVAI8Ct+tBB 0SE2nqBmxeEg==
ams.sns-pbns1.isc.org. 85775 7131 IN A 199149.620.1.3073ams.sns-pbns2.isc.org. 85775 7131 IN AAAA 2001:500:60::30A 199.6.1.52ord.sns-pbns3.isc.org. 85775 7131 IN A 19951.675.079.30143ord.sns-pbns1.isc.org. 85775 7131 IN AAAA 2001:5004f8:1:71f::3073sfba.sns-pbns2.isc.org. 85775 7131 IN A 149.20.64.3AAAA 2001:500:60:d::52sfba.sns-pbns3.isc.org. 85775 7131 IN AAAA 2001:4f841d0:0701:21100::192c92ams.sns-pbns1.isc.org. 7200 7131 IN RRSIG A 5 4 13 3 7200 2018112823333420181029233334 19923 20210417095734 20210318094252 27566 isc.org.fN6lhMQKcNsl889c8e0n7b0xBLWHnp9oLUn8ji4T7sNykobHObfihcvLLpX2DGqVKUWYCa/4JN/9kIe5hvikVNfiDxjZx89V6jMnhyavSsJdchyv3zuEedxpFa8Kq9y28Na+UBy0sE1ZwfdGxRfN5zpwchZUVjND7olME8SjPgjkHi8o/7v+3eCVpipu kqsJX46yVxm01RYppC2oSl/L0SRx1na88bxiFpLpIk1aIV5pAthgtQSH 9hYkMwyONw==ams.sns-pbns1.isc.org. 7200 7131 IN RRSIG AAAA 5 4 13 3 7200 2018112823333420181029233334 19923 20210420021727 20210321015317 27566 isc.org.mvlEcSyHnq/O1B8+awGkUPp3fHPego6Su9b6sZnyw4i+G7nviQDLkxjPNCL7ZKOKqGDtRcjlweTLqYBcv API02wN+QOHf5Vdeq+vhReo+um8Jg8aks3uYyCMZjCHtU9ztyQf/NAtFPNUzjTyDtirn79/lDan3GgwpICHvWq2DHCslp7hbZC7qRscFQjstONnLcprPS5q8T1TRFs97SuqTS7OK4B3f0Lf0ilC+ohOYQR/1bW Fg8m4ZOSbnlxl7w==ord.sns-pbns2.isc.org. 7200 7131 IN RRSIG A 5 4 13 3 7200 2018112823333420181029233334 19923 20210418124611 20210319123514 27566 isc.org. ZPsHODiOXBRsXN3K1AlL4Lhc6OGZs7rZUFSwYEerC/Nq++dkx0HMaUpSdEMLXwlcASrC8FWjKETiRSNhgXq1u+JiBkXTEWVsR81CSk2uFEAxMlWOfoIKKVnc9Hp7ZNjdHlgIWebLWGweMoCwGa6o6yuRqMjCrceDqTKQSq1RTvQRL3As9J1V4vMY5i+KQy IhYJy2OEWx4sCv5ukBKcv13TdrM37oBj5p4/ sayRB7Y/luRnOCjnSfOIadpTy2mBBg==ord.sns-pbns2.isc.org. 7200 7131 IN RRSIG AAAA 5 4 13 3 7200 2018112823333420181029233334 19923 20210420021727 20210321015317 27566 isc.org.usTQJB2VfLzzfA3TPWTUXiSKM3w7bfK6zGQf1t+LXdJBDLLrjvhmwWTp5DjLDIxIvd77mudcFQsXq7oVvmiJHmnA6zaJhF6cFAIKI7dJm5rGhGFsZkX7OD4x5LxDH1knah7AYTPdme+QDxcLzIsmY5iozQeMh3UKd+gfpork RqI3x6UYIlixFiQW6Yfqo3EedvTHW1H4/5leZwGLBHHc4OamE8k4aE35vd2 pCNi1/cugzbFGhUGDHroBzoRbND9zg==sfba.sns-pbns3.isc.org. 7200 7131 IN RRSIG A 5 4 13 3 7200 2018112823333420181029233334 19923 20210420025339 20210321020638 27566 isc.org.ryZ18IlvB7q/qPwIFHgLU7LSjnTBx3JpzpV2BQtb/2jdDM7zBQ/bnQ28/HTj7v8c4CkATUMYYg7FUlwyAMQUKLLbWFD+MSWoAAKmPEiND2XWqtvdCPwOv4kcQexcTnLoIfieq6HgraO8//AILwMmwUBgZc51tZ1eXcrteO4ySF5mO9kDoYNceP CiR3W2EPAZnYWLe91+k9krCvNlLKZXe92KgGYWwGNxp3Gp1TkdlywRtMUM Y9wUy1mzjmZjqGQ==sfba.sns-pbns3.isc.org. 7106 7131 IN RRSIG AAAA 5 4 13 3 7200 2018112823333420181029233334 19923 20210413142738 20210314141409 27566 isc.org.betjxdRZREj3fMHm7TsE7kn8vrZHRdpzrkJ3mxIe4jdhyUbQytxcIfnJaTOz5JT5ESF5n7kmTNp2I5wcUm1WPPmSsL01Yh5eMSJzgO/pq1Sd1nvrX+UK05ApZFc5b5slX0g5S/ahYm7ynLzz/Uw8/sWuOgsbMuyozpROYR jYWaYKg9yJCdMV8gGTgkedwE0EoF0A==UrPFePNdAxS00mX91rRYG7tVLHq79VOvIt18C69ac+oVGVfIBN/OJzan /gE=;;;;Query time: 85 91 msec;;SERVER: 192.168.8349.153#53(192.168.8349.153);;WHEN: Sun Nov 04 18Tue Mar 30 15:1857:23 EST 201800 EDT 2021;;MSG SIZE rcvd: 16231127
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 VM1co-nfs VM at home:
<ol>
<li>Now that you can spot the differences between authenticated and non-authenticated data, it is time to configure your local recursive DNS server to perform authentication when your client machines request it.</li>
<li>Simply set the dnssec-validation parameter in your /etc/named.conf file to yes (it is already set this way if you didn’t change it in an earlier lab).
*Note that this relies on your server also having the initial key it will use to authenticate the root name servers it communicates with.
*This can be found in /etc/named.iscdlv.key and /etc/named.root.key.*These This too are is included by default when you first install bind. If they are it is not there, add the following lines line to your options statement and restart your service:
<source>
include "/etc/named.root.key";
</source>
</li>
<li>Make sure your dns recursive DNS server is configured to be provide recursive answers to other machines in your network, and that it will allow traffic to udp/tcp port 53.
*All of this should have already been done, so long as you followed the instructions in previous labs, and didn’t deliberately break anything.
</li>
<li>Run the following command from one of your other VMs (making sure to use the ip address of your own DNS server):<source>>dig +tcp +dnssec @instead of 192.168.8349.1 www.isc.org</source>*You should get output similar to the following53 shown):
<source>
[rchan@pri-dns labs]$ dig +tcp +dnssec @192.168.49.53 isc.org ; <<>> DiG 9.911.420-RedHat-9.911.420-615.el7_5el8_3.1 <<>> +tcp +dnssec @192.168.83.1 www49.53 isc.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1351252005
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 8bfb94819923d7d0e71b5f5b6063828c7a5aa6d3baaf88b4 (good)
;; QUESTION SECTION:
;www.isc.org. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
isc.org. 6575 7131 IN NS ordns.isc.snsafilias-pbnst.isc.orginfo.isc.org. 6575 7131 IN NS sfba.sns-pbns1.isc.org.isc.org. 6575 7131 IN NS ams.sns-pbns2.isc.org.isc.org. 6575 7131 IN NS nsns3.isc.afilias-nst.infoorg.isc.org. 6575 7131 IN RRSIG NS 5 13 2 7200 2018112823333420181029233334 19923 20210418013614 20210319004124 27566 isc.org.IzXvpUxVCC15yG74ChGSlUgNOAPtvb6688zZm97SYSB6772gzS09VhmRWfpdOx5IJFwhhIl87bB49yiEHP4SimMrAfoAmGIpe5G4hI8uirhGlWNMRh6SVIMSXdPMCKF8pSqe387ERK9ZcEPfVVTxeAReJ5eOi0Rr+UGwmh6rZ4+nLApVAxVWOzx4FFlSDkRIMc+bKoMJb7SnGd tE+ccLm6gqwalSLxyuBhTR4IW3+/C0Ajygg+KhrwbS4A6 3wUw==
;; ADDITIONAL SECTION:
</source>
*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 Vm1VM2 in the virtual lab:
<ol>
<li>Now that you know your how to configure a recursive nameserver is capable of performing to perform authentication of other domains (so long as they are configured to provide authentication), it is time to set up authentication in configure your own domainto support authentication using DNSSEC.</li><li>First you need ot 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 youryou. 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).*The named account must have write permission to hte the /var/named directory. Again, this is currently the default setting, but double check that it is correct.
*If either of those settings is not configured correctly, fix them now.</li>
<li>Install the <b>haveged </b> service to generate random values for your system.
*It can be found in the epel-release repo. Install that if you have not already done so.
*You would not have to use this service on a ‘real’ server, but our VMs will may not have enough activity to provide normally random data within a reasonable time-frame.*Start, but do not enable <b>haveged </b> service, as we will not need it on a regular basis. Anytime you need to re-generate the random keys from the next step, simply start the service.
</li>
<li>Next, we will use the <b>dnssec-keygen </b> command to generate two sets of paired keys.
<ul>
<li>Create a directory at /etc/named/<yourdomain>-keys
<ul><li>Making sure you replace <yourdomain> with the name of your domain</li>
<li>Make sure it has that only <b>root </b> and the <b>named service user can </b> have read/write access to it.</li>
<li>cd into that directory so the keys you are about to generate get created there.</li>
</ul>
</li>
<li>First, to generate the <b>Zone Signing Key </b> (ZSK) that is used to sign individual records (make sure to use your own zone name):
<source>dnssec-keygen -a RSASHA256 -b 1024 <yourzone></source></li>
<li>And to generate the <b>Key Signing Key </b> (KSK) that is used to create an RRSIG for your DNSKEY (the public half of the ZSK):
<source>dnssec-keygen -a RSASHA256 -b 2048 -f KSK <yourzone></source></li>
<li>Note that the algorithm and number of bytes used here are current standards, but may change over time.</li>
Our machines only have two zone statements (the forward and reverse lookups of your domain), so it won’t make a significant difference where we place them. If your server hosted multiple domains, the placement of these parameters would be something to consider:
*Add the following lines to your two zones (again replacing <yourdomain> with the name of your domain):
<source>key-directory “/etc/named/<yourdomain>-keys”;
inline-signing yes;
auto-dnssec maintain;
key-directory “/etc/named/<yourdomain>-keys”;
</source>
*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.