OPS535-lab-dnssec

From CDOT Wiki
Revision as of 14:04, 9 October 2019 by Peter.callaghan (talk | contribs) (Investigation 1: Performing queries using DNSSec: - Inserting investigation 1 body)
Jump to: navigation, search

OPS535 Lab 6

Purpose

In this lab you will learn to configure a DNS server to provide responses authenticated with DNSSec, first by querying other servers for their DNSSec records, then by adding DNSSec records to your own zones.

Pre-Requisites

Labs 1 through 4 should be complete so that your machines have functioning network connections between each other, and to the outside world. You also need a functioning DNS domain (configured in lab 4) in order for mail to be properly transported between your machines (and potentially other domains).

Investigation 1: Performing queries using DNSSec

Perform the following steps on your VM2:

  1. Ensure you have bind-utils installed.
  2. Run the command dig senecacollege.ca
    • You should get output similar to the following:
    >dig senecacollege.ca @1.1.1.1
    
    ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> senecacollege.ca @1.1.1.1
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12758
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1452
    ;; QUESTION SECTION:
    ;senecacollege.ca.  IN  A
    
    ;; ANSWER SECTION:
    senecacollege.ca. 564  IN  A  205.207.147.230
    ;; Query time: 34 msec
    ;; SERVER: 1.1.1.1#53(1.1.1.1)
    ;; WHEN: Sun Nov 04 17:31:57 EST 2018
    ;; MSG SIZE rcvd: 61
    • If you did not get the expected output, go back and ensure your machine has network connectivity (including an assigned default route).
  3. Once you have a respoinse, can you be sure it is accurate?
    • Re-run the previous dig command, but this time add +dnssec to request authentication of the results using DNSSec.
    >dig senecacollege.ca @1.1.1.1 +dnssec
    
    ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> senecacollege.ca @1.1.1.1
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38472
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 1452
    ;; QUESTION SECTION:
    ;senecacollege.ca.  IN  A
    
    ;; ANSWER SECTION:
    senecacollege.ca. 564  IN  A  205.207.147.230
    ;; Query time: 34 msec
    ;; SERVER: 1.1.1.1#53(1.1.1.1)
    ;; WHEN: Sun Nov 04 17:36:57 EST 2018
    ;; MSG SIZE rcvd: 61
    • Notice the addition of the do flag (DNSSec Ok, that is the server we queried is willing to perform authentication), but no other difference in output. This information is not authenticated.
  4. Now we will run a query that does get authenticated:
    • Run the following command (again you should get output similar to the following):
    >dig isc.org @1.1.1.1 +dnssec
    
    ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> isc.org @1.1.1.1 +dnssec
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51709
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 1452
    ;; QUESTION SECTION:
    ;isc.org.  IN  A
    
    ;; ANSWER SECTION:
    isc.org.  60  IN  A  149.20.64.69
    isc.org.  60  IN  RRSIG A 5 2 60 20181128233334
    20181029233334 19923 isc.org.
    evUIhl3hmTGFchNe8GH7NDgMQS56fdgFgQy/BBqbE+zu0TXEVPLLsGxz
    pAEnYJq+0gTTa/nJjIMmxxsXj7HNZ+gpL8koGNRJeZDt/Q4jmfcRh+A7
    HJOn1LVpjwdzw459XF38mQmwBK7oh6ZTBg0UKzaw4J6zr5vql9KWoyJV KCo=
    
    ;; Query time: 31 msec
    ;; SERVER: 1.1.1.1#53(1.1.1.1)
    ;; WHEN: Sun Nov 04 17:42:44 EST 2018
    ;; MSG SIZE rcvd: 219
    • Notice that in addition to the do flag, the answer to this query also has an ad flag (Authenticated Data), along with extra information in the answer itself (the RRSIG record). This result is authenticated.
    • If you want to see this result without the DNSSec information, simply re-run the query without the +dnssec request.

Investigation 2: Configuring DNSSec on a Recursive Server

Investigation 3: Configuring DNSSec on an Authoritative Server

Completing the Lab

Your DNS server is now capable of performing recursive queries using DNSSec when client machines request it. It has also been configured to provide the extra DNSSec records when clients request them. Note that it is not yet truly providing DNSSec answers, as it is not being authenticated through the domain above yours.

Follow the instructions on blackboard to submit the lab.