|
|
| (12 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | = Some DNS Review =
| + | #REDIRECT [[OPS335_Lab_3b]] |
| − | | |
| − | 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.
| |
| − | | |
| − | == 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 this:
| |
| − | | |
| − | :Find the MX record for senecacollege.ca using dig:<br><source lang="bash">dig senecacollege.ca MX</source><br>
| |
| − | :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.
| |
| − | | |
| − | == CNAME record ==
| |
| − | | |
| − | Sometimes you want multiple domain names to point to the same server. The most common example of this is the www. subdomain. Use dig to find the main web server for Seneca or for CBC.
| |
| − | | |
| − | See [http://www.zytrax.com/books/dns/ch8/cname.html the reference] for CNAME to get examples of how to configure such records in Bind.
| |
| − | | |
| − | == TXT record ==
| |
| − | | |
| − | A TXT record can store pretty much anything, it's typically used for purposes that the desiners of DNS haven't though of themselves. For example a common use of a TXT record is SPF: a record that helps receiving email servers to determine the likelyhood that a message is spam.
| |
| − | | |
| − | == Your task ==
| |
| − | | |
| − | Configure at least one of each of the records above for your domain served by the Bind server in your vm1 and verify that your records work.
| |
| − | | |
| − | = Test Plans =
| |
| − | | |
| − | Every IT company needs to do testing - whether on software they create or systems they set up. Whenever you have a job to do - there has to be a way to show that your job is complete and correct (according to original expectations).
| |
| − | | |
| − | How much detail goes into the test plan depends on the resources available for testing, the scale of the changes, and the risk associated with getting things wrong. In your case the worst that's going to happen if you misconfigure a server is you'll lose some marks. In the industry a mistake like that can cost the company you work for a lot of money (perhaps even more than your salary).
| |
| − | | |
| − | Whether you have an extremely detailed process or something quick and simple - your test plan must be made with a well organized set of test cases.
| |
| − | | |
| − | == Test Cases ==
| |
| − | | |
| − | Theoretically you write the test cases before you complete the system. In a way the test suite (all the test cases combined) determine the requirements for your system.
| |
| − | | |
| − | Generally speaking each test case typically has at least one expected positive and some number of expected negative results. For example if you're setting up a DNS record for www.yoursenecaid.org your test case might look something like this:
| |
| − | | |
| − | [[Image:Sample_test_case.png|800px| ]] | |
| − | | |
| − | 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.
| |
| − | | |
| − | === Failures ===
| |
| − | | |
| − | Test cases (in a test suite, in a system that keeps track of them) are not intended to only show that the system is working. It's equally valuable to see that at some point in the past there was a problem. In that case there may be a bug number or some other means of tracking down what caused the problem in the past and how it was fixed. So recording failed test results is just as important as recording passes.
| |
| − | | |
| − | == Your task ==
| |
| − | | |
| − | 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.
| |
