Changes

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.

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.

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.

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'''.

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.

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.

Configure your '''VM1''' machine (Bind server) to incorporate each of the records discussed above and verify that your records work by DNS query.

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.

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.

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.

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.

When I check your lab - I normally ask you to run some commands, and I'll ask you some questions, and that is a sort of made-up-on-the-fly test suite for your lab. Let's formalize that for one section of one lab in a set of test cases.

Pick any section of any lab you like that would justify having at least three test cases. Write the test cases in a template, save a copy of that for the current test run, and execute the tests, recording the results.

= Submit =

To submit the lab - show that the new DNS records you created are served correctly and show your completed test plan.