|
Now that you've got your master tinydns server 100% operational, it's time to throw a series of tests at it to make sure that everything is working correctly. I'm going to cover a few simple procedures tests:
1. Your first domain - In this test, you will point a real domain to your new nameservers and you'll create a zone entry for the domain.
2. DNS confirmation - After pointing a domain to your nameservers and creating a zone entry for that domain, we'll confirm that both of your nameserver are, in fact, serving the correct DNS info for that domain.
3. DNS compliance - Our last test will involve the use of the DNS server test at dnsreport.com. We'll run the test, check out the results and correct any problems that need correcting. The goal here is to get your server so that it complies with the international DNS server standards. This is crucial not only from a functionality standpoint, but also because many registrars (especially overseas registrars) will NOT let you delegate a nameserver for a domain unless it passes a series of tests. A compliant server will ensure trouble free operation and also prevent you from looking like a newbie to your boss.
Your first domain
If you recall, in the last step I had you create an initial domain entry in the Vegadns interface. It didn't really matter at that time if that domain was real or not, but now were going to test the DNS server with the a real and active domain.
For the purposes of this example, let's say that I have purchased a domain called applejacks.com.
While still working at the registrar level, I will first want to point (delegate) the new domain to my new nameservers. Each registrar supplies different methods for doing this, but the concept is the same. You want to point the domain to your new nameservers. In the case of our example nameservers in previous steps, I want to point my new domain to:
ns1.djbdnsrocks.org 1.3.5.7
ns2.djbdnsrocks.org 2.4.6.8
Once you save the changes, it will take anywhere from a few hours to as long as 48 hours for the change to take effect. Generally, 24 hours is a good estimate.
A "whois" lookup can be performed on your new domain at regular intervals to find out when the nameserver delegation has taken effect. On most *nix servers, you can run a simple whois lookup like this:
whois applejacks.com (obviously, swap out applejacks.com your new domain name here)
The output of the whois lookup should tell you what nameservers the domain currently has delegated to it. Typically, the nameserver at listed at the very end of the whois query. You can also do a more "user friendly" whois lookup at http://www.domainwhitepages.com if you so desire.
While we're waiting for the nameserver delegation to take effect, we'll jump over to the Vegadns interface and create a zone entry for the new domain...
Using the "new domain" function in Vegadns, we'll create the new domain entry for applejacks.com...
click to enlarge
As you can see in the above snapshot, the new domain applejacks.com has been created in Vegadns. The nameserver information is correctly set to the djbdnsrocks.org nameservers I created. The entry comes equipped with 3 A records (applejacks.com, www.applejacks.com and mail.applejacks.com) and an MX record pointing the mail.applejacks.com with a priority of 10. You should also take note, again, of the SOA properties that are at the top of the entry as they need to correct at all times. The majority of this zone entry was actually created from the "default domain" settings that I had placed in Vegadns in the previous step. So, once I was sure that the template info was right, it really wasn't much work to create this new zone entry. All I do is fill in the blanks, so to speak.
Once the new zone has been created, it has already been written to the mysql database which controls Vegadns. The next thing that needs to happen is for the mysql data to be written out to the 2 tinydns nameservers. However, this step is 100% automated if you followed the directions on the previous step. If you recall, we created a crontab entry that runs the update-data.sh script (the scripts that pushes the new info out to the tinydns nameservers) every 10 minutes. So, at the very most, you're only going to have to wait 10 minutes for these changes to be active! However, if you are impatient, you can simple run the command "update-data.sh" directly on your server and it will push out the changes immediately!
So, the wrap up this part you should have done 2 things:
1. Pointed an active domain to your new nameservers
2. Created the zone entry for that domain via Vegadns
Now, let's see if it actually works...
DNS confirmation
So by now you should have pointed a domain at your nameservers as well as created the zone entry for that domain on your nameservers via Vegadns. Now let's see if you actually did it right. There are a few things we can do to test the new domain out.
Test 1. A local query
First, let's just do a simple dig against the new nameservers for the new domain. This test should work even if the domain is not yet pointed to your nameservers. In fact, it doesn't even matter if the domain is real or not. Your simple going to query your own nameservers and ask them if they have information on a domain. This is a private query to the nameservers themselves.
So, log into any server that is able to use the "dig" utility and do the following...
dig @1.3.5.7 applejacks.com
Obviously, you will want to replace 1.3.5.7 with the IP address of your first nameserver and applejacks.com with whatever domain you created a zone entry for.
You should get a reply from your DNS servers, similar to this:
dig @1.3.5.7 applejacks.com
; <<>> DiG 9.2.1 <<>> @1.3.5.7 applejacks.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63903
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;applejacks.com. IN A
;; ANSWER SECTION:
applejacks.com. 3600 IN A 64.246.60.29
;; AUTHORITY SECTION:
applejacks.com. 3600 IN NS ns2.djbdnsrocks.org.
applejacks.com. 3600 IN NS ns1.djbdnsrocks.org.
;; Query time: 4 msec
;; SERVER: 64.246.61.178#53(64.246.61.178)
;; WHEN: Mon Sep 27 01:28:31 2004
;; MSG SIZE rcvd: 99
Hey, isn't that cool? It works! Now try the same query against your secondary nameserver...
dig @2.4.6.8 applejacks.com
If all goes well., you should get a reply almost identical to the one above. If not, it's back to the drawing board. Among the troubleshooting steps you do, make sure your server is blocking DNS requests with a firewall rule and also make sure that all permissions/ownership settings on the tinydns and tinydns2 directory structures are correct.
Test 2. A remote query
This test requires that your nameservers be fully registered and that the domain be active and pointing to your nameservers.
This is the most important test. We're now going to test the DNS server' response when queried from an external location. In other words, we're going to query the domain from the outside world where all the rules apply.
Let's go to http://domainwhitepages.com/
Enter your domain in the query box. For this test, let's uncheck the whois lookups (we already did that previously) and just focus on the "DNS records" test.
When the "DNS records" lookup is performed, you should get a complete readout of your domain's DNS settings. The readout should look very much like the domain information in Vegadns. It should look similar to this sample query I did on djbdnsrocks.org:
click to enlarge
If you get the correct records back, your nameservers are working properly and returning the correct DNS info for your domains! Woohoo!
OK, now that you know your nameserver are working in a technical sense, we're going to do one final test. This test will test the overall health of your DNS setup and will greatly assist you in getting your DNS servers to comply with the international set of "rules" for DNS servers and nameserver delegation.
DNS compliance
Our final test will analyze and point out any inconsistencies and/or problems in our nameservers. To do this test, we're going to use http://www.dnsreport.com. The tests available at dnsreport.com do a superb job of analyzing all aspects of a domain's DNS records and the nameservers that serve that domain. Through these tests, you will be able to correct any problems in your nameserver and DNS configuration and you'll be able to have a DNS system which meets most or all of the international standards. This is very important, as some registrars (particularly overseas) will not allow a domain to be pointed at your nameservers if they fail many of these tests. So let's do it....
To do this test, you will need an active and functional domain name that is currently running off of your nameservers. For my test, I'm going to use djbdnsrocks.org
So let's go to http://www.dnsreport.com....
And now I enter djbdnsrocks.org in the "DNS report" field. Then a press the button and let the test go...
What comes back is a slew of test results. Every test result either passes, warns or fails. Ideally, you want your DNS system to pass all tests. However, a few warnings here and there do not constitute a crisis. What you really want to avoid is the failures. In the space below, I'm going to cover some of the tests, discussing what they mean and how to fix problems when they show up. There are a lot of tests, so I'm not going to cover every single one (at least not yet), but I will go over some of the more important and often failed tests.
|
NS records at parent servers
This is the second test performed and it makes sure that the nameservers to which you have pointed your domain to (at the registrar level) are reachable. A successful test in this area will show all of the nameservers that you pointed your domain to. In the case of djbdnsrocks.org, you can see the 4 nameservers that it's pointed to. They all resolve, they are all up and running and so it passes this test. Passing this test is vital and failures in this area usually result from one or more of your nameservers not answering queries correctly. If you see any failures, make sure that all of your nameservers are running and that they are answering all queries. You can typically tell if you nameserver if answering queries by looking at the logs.
For example:
tail -f /etc/tinydns/log/main/current
|
| |
|
Parent nameservers have your nameservers listed
Just like the test above, passing this test is crucial. This test makes sure that the nameservers to which your domain is pointing actually contain DNS information for that domain. Failing this test would mean that you successfully pointed you domain to your nameservers but that you failed to create the domain zone entry on the nameservers. In other words, you forgot to add the domain to your nameservers via Vegadns.
|
| |
|
Glue at parent nameservers
This test often results in a WARNING. A warning on this test is perfectly fine and it is not a critical problem. Essentially, the glue test looks at the TLD of your domain and compares that to the TLD of your nameservers. In case you don't know, a TLD is the ending on a domain, such as .com, .net or .org. If the domain your are testing has a different TLD than the nameservers to which it points, the test fails. For example, djbdnsrocks.org is pointed to ns1.namegenie.net. Since the domain is a .org and the nameservers are .net, the test fails. Again, this is not a critical error and in most cases, there's nothing you can do about it without doing a lot of extra work creating nameservers for each TLD. Don't worry about it.
|
| |
|
NS records at your nameservers
This test makes sure that the zone entry for your domain contains NS records that match the nameservers to which it points. For example, djbdnsrocks.org points to ns1, ns2, ns3 and ns3.namegenie.net. In the zone entry for djbdnsrocks.org (visible in Vegadns), there are 4 NS records in place indicating all 4 nameservers. If, for example, the zone entry for djbdnsrocks.org only contained an NS record for ns1 and ns2.namegenie.net, the test would fail because there are no NS records for ns3 and ns4.namegenie.net. You want to pass this test!
|
| |
|
All nameservers report identical NS records
Similar to the test above. It simply makes sure that each of your nameservers contains the same NS records for your domain.
|
| |
|
Nameservers on separate class C's
A non-critical test, this simply checks to see if each of your nameservers exist on different C classes. In other words, it checks to see if each of your nameservers resides on a different network. In a truly redundant setup, each nameserver would lie on a completely different network from the other nameservers. This would help to ensure functionality even if an entire network had problems. Again, this is not critical and if you are running all of your nameserver on a single machine you will most definitely fail this test. Don't sweat it. You've got a little less redundancy, but it's not a crisis.
|
| |
|
NS agreement on SOA serial #
This test makes sure that all of your nameservers have the same serial number, meaning that they were all updated at the same time and contain identical information. On the single server DNS setup, you should pass this. This test comes more into play when you have multiple servers at different locations. They must all have the same exact timestamp/serial to show that they all contain the same information.
|
| |
|
SOA serial number
When using tinydns, this test will likely fail. But don't worry. Tinydns simply uses a different serial process than other DNS solutions. This is non-critical and will not effect anything.
|
| |
|
MX record
A no brainer. This checks to make sure your domain has an MX record for mail functionality. This is non-critical, but the lack of an MX record will prevent your domain from being able to receive email.
|
| |
|
Multiple MX records
I'm not really sure why they include this test. I personally think it's not needed. This test checks to see if you have a secondary MX record that points to a backup mail server. I personally don't believe in backup mail servers and most people don't have them. This is non-critical and you don't need to worry about it, unless you are looking to have a backup mail server in the mix.
|
| |
|
Reverse DNS entries for MX records
This is a non-critical test, but an important one nevertheless. This test checks for the existence of a PTR record for your MX record. A PTR record validates your mail server. Many spam filters check for the existence of a PTR record and often a mail server won't accept mail from a mail server that doesn't have a PTR record. As a rule of thumb, I create a PTR record for every IP address that my server's have bound to them.
|
| |
|
Mail server host name in greeting
Another non-critical test. This simply checks to see if your mail server has the same greeting name as your MX record. As you can see from the djbdnsrocks.org test, my mail server has a different hostname, so it fails. Don't worry to much about this one.
|
| |
|
SPF record
Many mail servers these days check for an SPF record. An SPF record helps to prevent spam from being sent with your domain as a return address. In other works, it helps to prevent spammers from spoofing your domain when they spam people. That reminds me, I need to add an SPF record to djbdnsrocks.org. I plan to have a section of this tutorial that will cover SPF records very soon.
|
Proceed to step 8
|
