Difference between revisions of "OPS335 Lab 3b"
m (→EXPLORATION QUESTIONS) |
|||
| (22 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | = | + | ==DOMAIN NAME SYSTEM RESOURCES== |
| − | + | Online References: | |
| − | + | *[https://en.wikipedia.org/wiki/Test_case Test Case Definition] (Wikipedia definition of a Test Case) | |
| − | |||
| − | + | ==OBJECTIVE == | |
| − | + | Last week you were introduced to administering a simple authoritative DNS server. This week we will review that topic, but focus on learning a few more resource record types. This lab will also provide the background and tools (such as a test case) that will be used in your assignment #1. | |
| − | + | You will also be using the '''dig''' tool in more depth in this lab. | |
| − | |||
| − | + | ==INVESTIGATION 1: STUDYING RESOURCE RECORD TYPES== | |
| − | + | === The MX Record === | |
| − | + | When someone tries to send email (for example: '''senecacollege.ca''') the mail message needs to be sent to the Seneca <u>mail</u> server (which, most likely, is '''not''' senecacollege.ca). That is the typical setup for any business since using a different server for mail simplifies administration and helps maintain server load balancing. | |
| − | + | :To Demonstrate the point in the statement above: | |
| − | + | :Find the MX record for senecacollege.ca using the '''dig''' command:<br><source lang="bash">dig senecacollege.ca MX</source> | |
| + | :Notice that the email servers aren't even a subdomain of senecacollege.ca but a completely different company (Microsoft in this case).<br>In other cases (for example, check the records for ''google.com'') the email servers are within the company's domain. | ||
| − | + | In rare cases, there may be no MX records associated with a domain (For example: try '''dig littlesvr.ca'''). In this latter case, the server called littlesvr.ca, which is supporting a web-server, is also supporting the email server for the same IPADDR. | |
| − | + | Notice that the response from commands for '''MX records''' contains <u>domain names</u> and <u>not</u> IP addresses. That means that when you look for a domain's email server, you may be required to also perform a query for MX record as well as for another type A record. Recall that type A records provide the IPADDR information. | |
| − | + | It is highly recommended that you become comfortable with being able to create an MX records, and be comfortable interpreting (reading) MX record information contained in the '''Bind configuration file''' or by performing domain name queries using '''dig''', '''nslookup''' or the '''host''' command. See [http://www.zytrax.com/books/dns/ch8/mx.html the reference] for the syntax. | |
| − | == | + | === The CNAME record === |
| − | + | Sometimes you may want to create multiple domain names to point to the same server. The most common example of this is the '''www. subdomain'''. | |
| − | + | Use the '''dig''' command to find the <u>main web server</u> for '''Seneca College''' as well as for the '''CBC (Canadian Broadcast Corporation)'''. | |
| − | + | See [http://www.zytrax.com/books/dns/ch8/cname.html the reference] for CNAME to view examples of how to configure such records in Bind. | |
| − | + | === The TXT record === | |
| − | + | A '''TXT''' record is used to store any type of data or information. It is generally considered to be a "user-defined" section in order to provide additional information that the DNS system was not designed to handle or accommodate. For example, a common use of the TXT record is to support '''SPF''': which is a special type of record used to help receiving email servers determine the likelihood that a message is spam. | |
| − | == | + | === Update Additional Resource Records for Your VM1 Name Server === |
| − | + | Configure your '''VM1''' machine (Bind server) to incorporate each of the records discussed above and verify that your records work by DNS query. | |
| − | Generally | + | '''Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log-book''' |
| + | |||
| + | |||
| + | ==INVESTIGATION 2: GENERATING TEST PLANS== | ||
| + | |||
| + | === Reason for Using Test Plans === | ||
| + | |||
| + | Every IT company needs to perform testing whether on software they create, or for the systems they set up in order to provide quality assurance. Whenever an IT job is performed, it is essential that there is a method or framework to show that your job is complete and correct (according to original expectations). One example would be the use of a '''Test Plan''' in order to <u>demonstrate</u> that the task was completed successfully according to the required specifications (i.e. proof). Another example would include the use of a ''ticketing system'' that tracks issues to be addressed, fixed, closed, and end-user feedback. | ||
| + | |||
| + | How much detail goes into the test plan depends on what resources are available for testing, the scale of the changes, and the risk associated with problems that may occur while performing a task. In your case, the worst case scenerio is that you mis-configure your server, and that you may lose a few marks on an assignment. In the IT industry, a mistake (such as server mis-configuration) can cost the company that you work a lot of money (perhaps even more than your salary). | ||
| + | |||
| + | Your test plan that you create should be planned, be well organized (communicated) and contain the appropriate test cases to indicate that the configuration was successful. | ||
| + | |||
| + | === Test Cases Within a Test Plan === | ||
| + | |||
| + | Theoretically, you will create test cases (to be included in your Test Plan) prior to finishing the configuration of your system or task. One way to look at this is that when all of the test cases are created prior to completing your task, they become a benchmark or framework which really determine the requirements for your system. | ||
| + | |||
| + | Generally, each test case typically has at least '''one expected positive''' and a '''few expected negative''' results. For example, if you are setting up a DNS record for www.yoursenecaid.org your test case might look something like this:<br><br> | ||
[[Image:Sample_test_case.png|800px| ]] | [[Image:Sample_test_case.png|800px| ]] | ||
| + | <br><br> | ||
The test above shows a few things: that the DNS server is running, that it's accessible from the internal network, and it is serving the correct record. It also shows that the needed record does not propagate to the public DNS servers - the server 8.8.8.8 doesn't have the same record that your private server does. That's not a wonderful result but it's what you were expecting so it's still a positive result. In fact if 8.8.8.8 returned an A record for your query - you should be concerned that the rest of your test cases may be incorrect. | The test above shows a few things: that the DNS server is running, that it's accessible from the internal network, and it is serving the correct record. It also shows that the needed record does not propagate to the public DNS servers - the server 8.8.8.8 doesn't have the same record that your private server does. That's not a wonderful result but it's what you were expecting so it's still a positive result. In fact if 8.8.8.8 returned an A record for your query - you should be concerned that the rest of your test cases may be incorrect. | ||
You can spend an infinite amount of time running tests and stil not prove anything definitively, so you have to do your best to make sure the tests you run are representative of the requirements - that after a successful run of all the tests the service is almost certainly working correctly. | You can spend an infinite amount of time running tests and stil not prove anything definitively, so you have to do your best to make sure the tests you run are representative of the requirements - that after a successful run of all the tests the service is almost certainly working correctly. | ||
| − | === Failures === | + | === Identifying Test Case Failures === |
| + | |||
| + | Test cases (in a test suite) are not intended to only show that the system is working. On the other hand, it is valuable to view a history of problems or failures that have occurred in the past. For those situations, there may be a bug tracking number or some other means of tracking down what caused the problem in the past and how it was fixed. This can help provide quick identification of problems to lead to quick resolutions in case those similar situation occur in the future. | ||
| + | |||
| + | === Create Test Cases for Your VM1 Machine === | ||
| + | |||
| + | Provide query results for your '''vm1''' name server for each of the resource records discussed in this lab. | ||
| + | |||
| + | Pick any section of any of the labs that wish to generate 3 separate test cases. Write the test cases in a test plan template, then save another copy of the test plan, making sure to include:your current testing criteria, and the results from you running that current testing criteria. You will be required to show this test plan upon sign-off of this lab. | ||
| + | |||
| + | '''Record steps, commands, and your observations in INVESTIGATION 2 in your OPS335 lab log-book''' | ||
| − | |||
| − | = | + | = COMPLETING THE LAB = |
| − | + | To submit the lab, show the '''newly-created DNS records''' (via nslookup, host, or dig command), and show your '''completed test plan'''. | |
| − | |||
| − | = | + | =EXPLORATION QUESTIONS= |
| − | + | #What is the purpose of the following types resource records?<ul><li>A</li><li>NS</li><li>MX</li><li>TXT</li><li>PTR</li></ul> | |
| + | #Show the steps for using '''nslookup''' for querying the name name cnn.com for each of the record types discussed in the previous question. | ||
| + | #Show the '''host''' commands for querying the name name cnn.com for each of the record types discussed in Question #1. | ||
| + | #Show the '''dig''' commands for querying the name name cnn.com for each of the record types discussed in Question #1. | ||
| + | #What is the purpose of a Test Plan? | ||
| + | #What are the main components of a Test Plan? | ||
Latest revision as of 16:35, 4 May 2016
Contents
DOMAIN NAME SYSTEM RESOURCES
Online References:
- Test Case Definition (Wikipedia definition of a Test Case)
OBJECTIVE
Last week you were introduced to administering a simple authoritative DNS server. This week we will review that topic, but focus on learning a few more resource record types. This lab will also provide the background and tools (such as a test case) that will be used in your assignment #1.
You will also be using the dig tool in more depth in this lab.
INVESTIGATION 1: STUDYING RESOURCE RECORD TYPES
The MX Record
When someone tries to send email (for example: senecacollege.ca) the mail message needs to be sent to the Seneca mail server (which, most likely, is not senecacollege.ca). That is the typical setup for any business since using a different server for mail simplifies administration and helps maintain server load balancing.
- To Demonstrate the point in the statement above:
- Find the MX record for senecacollege.ca using the dig command:
dig senecacollege.ca MX
- Notice that the email servers aren't even a subdomain of senecacollege.ca but a completely different company (Microsoft in this case).
In other cases (for example, check the records for google.com) the email servers are within the company's domain.
In rare cases, there may be no MX records associated with a domain (For example: try dig littlesvr.ca). In this latter case, the server called littlesvr.ca, which is supporting a web-server, is also supporting the email server for the same IPADDR.
Notice that the response from commands for MX records contains domain names and not IP addresses. That means that when you look for a domain's email server, you may be required to also perform a query for MX record as well as for another type A record. Recall that type A records provide the IPADDR information.
It is highly recommended that you become comfortable with being able to create an MX records, and be comfortable interpreting (reading) MX record information contained in the Bind configuration file or by performing domain name queries using dig, nslookup or the host command. See the reference for the syntax.
The CNAME record
Sometimes you may want to create multiple domain names to point to the same server. The most common example of this is the www. subdomain.
Use the dig command to find the main web server for Seneca College as well as for the CBC (Canadian Broadcast Corporation).
See the reference for CNAME to view examples of how to configure such records in Bind.
The TXT record
A TXT record is used to store any type of data or information. It is generally considered to be a "user-defined" section in order to provide additional information that the DNS system was not designed to handle or accommodate. For example, a common use of the TXT record is to support SPF: which is a special type of record used to help receiving email servers determine the likelihood that a message is spam.
Update Additional Resource Records for Your VM1 Name Server
Configure your VM1 machine (Bind server) to incorporate each of the records discussed above and verify that your records work by DNS query.
Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log-book
INVESTIGATION 2: GENERATING TEST PLANS
Reason for Using Test Plans
Every IT company needs to perform testing whether on software they create, or for the systems they set up in order to provide quality assurance. Whenever an IT job is performed, it is essential that there is a method or framework to show that your job is complete and correct (according to original expectations). One example would be the use of a Test Plan in order to demonstrate that the task was completed successfully according to the required specifications (i.e. proof). Another example would include the use of a ticketing system that tracks issues to be addressed, fixed, closed, and end-user feedback.
How much detail goes into the test plan depends on what resources are available for testing, the scale of the changes, and the risk associated with problems that may occur while performing a task. In your case, the worst case scenerio is that you mis-configure your server, and that you may lose a few marks on an assignment. In the IT industry, a mistake (such as server mis-configuration) can cost the company that you work a lot of money (perhaps even more than your salary).
Your test plan that you create should be planned, be well organized (communicated) and contain the appropriate test cases to indicate that the configuration was successful.
Test Cases Within a Test Plan
Theoretically, you will create test cases (to be included in your Test Plan) prior to finishing the configuration of your system or task. One way to look at this is that when all of the test cases are created prior to completing your task, they become a benchmark or framework which really determine the requirements for your system.
Generally, each test case typically has at least one expected positive and a few expected negative results. For example, if you are setting up a DNS record for www.yoursenecaid.org your test case might look something like this:
The test above shows a few things: that the DNS server is running, that it's accessible from the internal network, and it is serving the correct record. It also shows that the needed record does not propagate to the public DNS servers - the server 8.8.8.8 doesn't have the same record that your private server does. That's not a wonderful result but it's what you were expecting so it's still a positive result. In fact if 8.8.8.8 returned an A record for your query - you should be concerned that the rest of your test cases may be incorrect.
You can spend an infinite amount of time running tests and stil not prove anything definitively, so you have to do your best to make sure the tests you run are representative of the requirements - that after a successful run of all the tests the service is almost certainly working correctly.
Identifying Test Case Failures
Test cases (in a test suite) are not intended to only show that the system is working. On the other hand, it is valuable to view a history of problems or failures that have occurred in the past. For those situations, there may be a bug tracking number or some other means of tracking down what caused the problem in the past and how it was fixed. This can help provide quick identification of problems to lead to quick resolutions in case those similar situation occur in the future.
Create Test Cases for Your VM1 Machine
Provide query results for your vm1 name server for each of the resource records discussed in this lab.
Pick any section of any of the labs that wish to generate 3 separate test cases. Write the test cases in a test plan template, then save another copy of the test plan, making sure to include:your current testing criteria, and the results from you running that current testing criteria. You will be required to show this test plan upon sign-off of this lab.
Record steps, commands, and your observations in INVESTIGATION 2 in your OPS335 lab log-book
COMPLETING THE LAB
To submit the lab, show the newly-created DNS records (via nslookup, host, or dig command), and show your completed test plan.
EXPLORATION QUESTIONS
- What is the purpose of the following types resource records?
- A
- NS
- MX
- TXT
- PTR
- Show the steps for using nslookup for querying the name name cnn.com for each of the record types discussed in the previous question.
- Show the host commands for querying the name name cnn.com for each of the record types discussed in Question #1.
- Show the dig commands for querying the name name cnn.com for each of the record types discussed in Question #1.
- What is the purpose of a Test Plan?
- What are the main components of a Test Plan?
