Tools

Home

Tool info

Tools

This section is reserved for Tools

There are several differences between the historical V1 DNSReport, and the new V2 DNSReport. We understand some of the changes may be difficult to understand at first glance, hopefully this article will serve to answer any questions you may have about them. If after reading this article you still have questions, do not hesitate to contact us via email at support@dnsstuff.com.

Parent section

Missing Direct Parent

This test has been removed entirely. It used to indicate that the entire DNSReport failed, as the zone could not be found at the parent servers. The test will still fail and indicate that either the zone does not exist and may be misspelled, but the error message is not done within the context of a DNSReport result and is no longer counted as a test.

Remaining Tests

The remaining tests have been aggregated into a single test called the "Parent Zone Provides NS Records" test. This test checks that the parent zone provides NS records for the zone in question. The test passes if the parent zone provides at least three NS records and glue for all of them. Only having two NS records results in a warning, and only having a single NS record results in a failure. Failure to provide glue also results in a warning.

NS section

NS records at your nameservers

This test has been removed, as it was not actually a test, but simply a list of nameservers. The nameservers are now simply listed within the tests themselves, primarily the "All Nameservers Respond" test.

Mismatched Glue

The Mismatched Glue test has been renamed "NS list matches parent list" test and now tests both NS records and their associated glue records. This has resulted in the removal of the "No NS A records at nameserver" and "All nameservers report identical NS records" tests, as their functionality is included within this test.

Nameserver name validity

This test has been removed, as we are currently unaware of any nameserver software in production use that will allow you to enter invalid data into any RDATA field and still allow the zone to be loaded and the records served. Our evaluation is based on current release versions of BIND 8, BIND 9, djbdns, and Microsoft's DNS server.

Number of Nameservers

This test is now performed in the Parent section, as that is where it matters the most. If there are differences between the nameserver list in the parent zone and the zone being tested, those differences will be reflected in the "NS list matches parent list" test in this section.

Lame Nameservers

This test has been renamed "All nameservers authoritative."

Missing (stealth) nameservers

This test functionality has been rolled into the "Stealth Nameservers" test.

Missing Nameservers 2

The functionality of this test has been duplicated within the "NS list matches parent list" which can detect any differences in the two lists.

No CNAMEs for domain

No NSs with CNAMEs

Nameservers on separate class C's

While this test was always a misnomer, and was in fact testing that the nameserver addresses were in different /24 netblocks, it has now been removed for two reasons. The test itself was designed to warn the user that in the event of a physical or network segment failure, several or all of their nameservers may simultaneously become unavailable. First, CIDR and other routing technologies which have been in use for many years have removed the ability to simply assume that since two addreses are within the same /24 that they are located within physical proximity to one another. Second, it is now extremely common for single servers to host all domain functionality, with a single physical machine acting as nameserver, mailserver, webserver, and even database server; issuing warnings for such domains caused unwarranted concern for a large number of our users.

Nameserver versions

This test has been renamed "Nameserver software version"

Single Point of Failure

This test has been disabled in DNSReport for several years and was not recreated for the new DNSReport.

Stealth NS record leakage

The "Stealth NS record leakage" test reported a failure when a nameserver served additional nameserver records in baliwick when asked for other records. This test was removed as serving records in baliwick is not only common, but encouraged, to help cut down on additional requests when many such requests are predictable. Any stealth nameservers (nameservers listed in the zone but not in the parent zone) detected are still listed in an attention getting fashion when they are detected, in the "NS list matches parent list" test.

SOA

All SOA field checks

All SOA field checks are now performed within a single test, titled "SOA field check." This significantly reduced the display size of the DNSReport while not actually removing any functionality.

MX

Low port test

The "low port test" attempted to connect to the remote mailserver on port 25 from a source port below 1024. The general reasons behind this test no longer apply as firewalls and other filtering mechanisms have improved.

Invalid characters, MX records are not CNAMEs, MX is a host name

MX A lookups have no CNAMEs

This test was removed as it was a duplicate of the "MX records are not CNAMEs" test, which itself was removed as mentioned previously.

Multiple MX-A records, Differing MX-A records, Duplicate MX records

All of these tests are now performed by a single test called "Differing mailserver addresses."

Mail

Acceptance of abuse address

This test now issues a failure in place of a warning if mail to the abuse mailbox is not accepted.

Acceptance of address literals

This test now issues a failure in place of an 'info' if mail to the address literal is not accepted.

SPF

The SPF test was greatly expanded and moved into its own section.

WWW

All tests

The WWW section was not included in the first release of the DNSReport V2 beta, though it was reimplemented in an updated release.

Domain A Lookup

The Domain A Lookup test has been renamed "Zone A Record" simply because DNSReport is quite often run against zones which are not properly called domains.

SSL

The SSL tests within the WWW section are entirely new.

DNSSEC

The entire DNSSEC section is a new DNSReport addition.

SPF

The entire SPF section is a new DNSReport addition.

How to retrieve headers

>>Gmail (old format)
1. Open the suspect email you wish to test
2. Click on Show Options next to the sender's email address
3. Click on Show Original - a new window will open containing the Full Headers
4. Highlight and copy the Full Headers
5. Go to http://www.dnsstuff.com/emailpathanalyzer
6. Paste the Full Headers into the header field
7. Hit run

>>Gmail (new format)
1. Open the suspect email you wish to test
2. Click on the down arrow next to Reply
3. Choose 'Show Original' from the drop down menu
4. Highlight and copy the Full Headers only, not the message text
5. Go to http://www.dnsstuff.com/emailpathanalyzer
6. Paste the Full Headers into the header field
7. Hit run

>>Outlook
CAUTION: Do not click on View Source in the drop down menu. In Outlook, Source gives you the HTML encoding of the email text message; it does not give you the email headers.
1. Right click on suspect email, then select ”Message Options”
2. Then Right click in the box with the title “Internet headers:” and select “Select All”, then Right click again and select “Copy”
3. Go to http://www.dnsstuff.com/emailpathanalyzer
4. Paste the Full Headers into the header field
5. Hit run

>>Outlook Express
1. Right click on the suspect email you wish to report
2. From the menu above choose 'Properties'; this will launch a dialog box.
3. When the dialog box first launches it will be on the 'General' tab; to view the Full Headers click on the
'Details' tab as shown above in red.
4. Highlight and copy the Full Headers
5. Go to http://www.dnsstuff.com/emailpathanalyzer
6. Paste the Full Headers into the header field
7. Hit run

>>Thunderbird
1. Double-click on the suspect email in open letter view
2. Click on View in the toolbar then on Message Source in the drop down menu
3. The full text of the message with Full Headers is displayed
4. Highlight and copy the Full Headers. The fastest way to do this is to right click on the Headers then click Select All in the drop down menu. Right click on the Headers again and click Copy in the drop down menu.
5. Go to http://www.dnsstuff.com/emailpathanalyzer
6. Paste the Full Headers into the header field
7. Hit run

>>Yahoo Mail (classic)
In order to guarantee that the Full Headers will stay in the suspect email when you forward it to us you will have to copy and paste them into the top of the message text, even though they will appear as part of the email.
Unfortunately, Yahoo is not stable right now and the Full Headers you see as part of your email may disappear in transit.
1. Open the suspect email and scroll down to the bottom of the message text. Click on Full Headers.
2. This is what will appear at the top of the email:
3. Highlight the Full Headers, then right click and select Copy in the drop down menu
4. Go to http://www.dnsstuff.com/emailpathanalyzer
5. Paste the Full Headers into the header field
6. Hit run

>>Hotmail/MSN
HOTMAIL USERS: The Full Headers can only be accessed if you are using the full hotmail version, not basic)
1. Right click on the suspect email and a drop down menu will appear.
2. Choose Source on the drop down menu
3. Copy highlight and copy the Full Headers
4. Go to http://www.dnsstuff.com/emailpathanalyzer
5. Paste the Full Headers into the header field
6. Hit run

Our rate limiting system is very complex, and it may have thought that you were an automated program. If you request to be unblocked via our CONTACT form, we will investigate your account. Within 24 hours your access to the site will be back.
Here are some things we look at:

* You use a web proxy: If you use a web proxy, you are now sharing the same IP address with possibly thousands of other people. If one of them abuses our site, you may get banned. If this is the case, you should stop using the web proxy. If you are forced to use a web proxy, you should complain to whoever is forcing you to use it.
* You should contact whoever is in charge of your web proxy (if you aren't sure, contact your Internet provider) for assistance. You should let them know that the web proxy at [IP of your web proxy] is being abused and participating in a DDoS attack (and may be an 'open web proxy'), and that they must fix the problem. Searching the web proxy logs for 'netgeo.ch' will definitely find the rogue hits (but could possibly find some legitimate hits).
* You may be the FireFox 'No Phishing' Extension: Someone had a great idea for a FireFox Extension, but didn't realize that it was going to abuse our site. If you use the FireFox web browser and have this extension, you must remove it.
* Automated/programmatic usage: You must contact sales@dnsstuff.com to learn more about our DNSstuff auto usage service. Our site does not support programmatic or high usage unless you have a valid account with DNSstuff.com.
* You may be infected with malware: There is malware out there that accesses our website, that thousands of computers are infected with. There is a slight chance you might have it. If you haven't done so recently, it would not hurt to run a good virus scanner that can detect malware.

An open DNS server is a DNS server that responds to recursive queries (queries for domains that the DNS server is not authoritative for, such as websites that you go to, or domains that you send mail to, as opposed to your own domain), and does so for anyone (not just clients on your local network).
Originally, DNS servers and mail servers were all open. That's just how the Internet was intended to work. Over the years however, spammers started relaying through open relays, so the best practice became not to run open relay mail servers. For quite a few years now, best practice has been to avoid configuring DNS servers as both authoritative and caching (doing recursive lookups). Unfortunately, most DNS servers are still open.
The problem is that there are now DDoS attacks (attacks that send lots of data to a computer, so that it becomes overloaded) that use open DNS servers, using amplification (sending small packets to a computer that then sends large packets to the victim, making it possible to send more data to the victim). Specifically, a UDP DNS packet is sent with a forged source IP address (the one of the victim), and a query is made in a small packet (about 75 bytes) for a domain that has a very large response packet (using EDNS0, it can be 4,000 or more bytes). The response packet then goes to the victim. The victim gets about 50 times as much data as the attacker is sending out. So with a dialup connection, they could saturate a T1 line.

NOTE: These instructions show you how to completely disable recursion. This is the best practice. However, if you need to run a DNS server that is both authoritative and recursive/caching, you will need to check the DNS server documentation to find out how to enable recursive lookups only for your local network. It seems that there is no way to do this with Microsoft DNS; if so, you will need to use other DNS server software or use a hosted DNS service. If anyone is aware of a way to get Microsoft DNS to allow recursion only to specific IP ranges, please let us know -- lots of people would like to do that.

Fixing Microsoft DNS on Windows NT
•    Add HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\NoRecursion with DWORD value 1 in registry
(NOTE: This may or may not work. Microsoft documents it in a way that both says it will disable recursion, and suggests
that it will not disable recursion).
Fixing Microsoft DNS on Windows 2000
•    Open DNS [Start->Programs->Admin Tools->DNS]
•    In the console tree, click the applicable DNS server.
•    On the Action menu, click Properties.
•    Click the Advanced tab.
•    In Server options, select the Disable recursion check box, and then click OK
Fixing Microsoft DNS on Windows 2003
•    Open DNS.
•    In the console tree, right-click the applicable DNS server, then click Properties.
•    Click the Advanced tab.
•    In Server options, select the Disable recursion check box, and then click OK.
Fixing Simple DNS Plus
•    Open Simple DNS Plus.
•    Go to the Tools menu and select Options.
•    Click 'Recursion' (under DNS) on the tree on the left side of the window.
•    Uncheck 'Perform DNS recursion'.
•    If you need to enable recursion for your local network, check that recursion box, select 'Only for the following client IP addresses', and enter the IP ranges of your network.
Fixing BIND
•    Open named.conf with a text editor
•    Use a line "recursion no;" in the "options" clause (or in the "view" clause)
•    If you need to enable recursion for your local network, you can use a "allow-recursion { ADD_LIST_OF_YOUR_IP_RANGES_HERE; }" line in the "options" section.
•    [Use caution; BIND files are easy to break]
•    For complete hardening, see http://www.cymru.com/Documents/secure-bind-template.html.

... or, "Almost a Reverse DNS FAQ"
Reverse DNS turns an IP address into a hostname -- for example, it might turn 192.0.2.25 into host.example.com.

For your domains, standard DNS (turning a hostname into an IP address, such as turning host.example.com into 192.0.2.25) starts with the company (registrar) that you registered your domains with. You let them know what DNS servers are responsible for your domain names, and the registrar sends this information to the root servers (technically, the parent servers for your TLD). Then, anyone in the world can access your domains, and you can send them to any IP addresses you want. You have full control over your domains, and can send people to any IPs (whether or not you have control over those IPs, although you should have permission to send them to IPs that are not yours).

Reverse DNS uses a similar method. For your IPs, reverse DNS (turning 192.0.2.25 back into host.example.com) starts with your ISP (or whoever told you what your IP addresses are). You let them know what DNS servers are responsible for the reverse DNS entries for your IPs (or, they can enter the reverse DNS entries on their DNS servers), and your ISP gives this information out when their DNS servers get queried for your reverse DNS entries. Then, anyone in the world can look up the reverse DNS entries for your IPs, and you can return any hostnames you want (whether or not you have control over those domains, although you should have permission to point them to hostnames that are not on your domains).

So for both standard DNS and reverse DNS, there are two steps: [1] You need DNS servers, and [2] You need to tell the right company (your registrar for standard DNS lookups, or your ISP for reverse DNS lookups) where your DNS servers are located. Without Step 2, nobody will be able to reach your DNS servers.

If you can comprehend the above paragraphs (which takes some time), you'll understand the biggest problem that people have with reverse DNS entries. The biggest problem people have is that they have DNS servers that work fine with their domains (standard DNS), they add reverse DNS entries to those servers, and it doesn't work. If you understand the above paragraphs, you'll see the problem: If your ISP doesn't know that you have DNS servers to handle the reverse DNS for your IPs, they won't send that information to the root servers, and nobody will even get to your DNS servers for reverse DNS lookups.

Basic Concepts:

    * Reverse DNS turns 192.0.2.25 into host.example.com (an IP address into a host name).
    * Typical reverse DNS lookup path: DNS resolver => root servers => ARIN (North American IP registry) => Local ISP => Acme Inc. DNS servers.
    * Whoever supplies your IP addresses (usually your ISP) MUST either [1] set up your reverse DNS entries on their DNS servers, or [2] "delegate authority" for your reverse DNS entries to your DNS servers.
    * Reverse DNS entries use a host name with a reversed IP address with ".in-addr.arpa" added to it -- for example, "25.2.0.192.in-addr.arpa" (".ip6.arpa" is used for IPv6 reverse DNS lookups).
    * Reverse DNS entries are set up with PTR records (whereas standard DNS uses A records), which look like "25.2.0.192.in-addr.arpa. PTR host.example.com" (whereas standard DNS would look like "host.example.com. A 192.0.2.25").
    * All Internet hosts should have a reverse DNS entry (see RFC1912 section 2.1).
    * Mail servers with no reverse DNS will have a hard time getting mail to certain large ISPs.

Very Common Myth:

    * Myth: If you have a reverse DNS entry listed in your DNS server, you have reverse DNS properly set up.
      Fact: This is often not the case. You need TWO things in order to have your DNS set up properly:
          o 1. Your DNS servers (or your ISP's) MUST have the reverse DNS entries set up ("25.2.0.192.in-addr.arpa. PTR host.example.com").
          o 2. AND your ISP or bandwidth provider MUST set up the reverse DNS on their end, so that DNS resolvers around the world will know that your DNS servers are the ones to go to when looking up the reverse DNS for your IP addresses.

How a reverse DNS lookup is accomplished:

    * The DNS resolver reverses the IP, and adds it to ".in-addr.arpa" (or ".ip6.arpa" for IPv6 lookups), turning 192.0.2.25 into 25.2.0.192.in-addr.arpa.
    * The DNS resolver then looks up the PTR record for 25.2.0.192.in-addr.arpa.
          o The DNS resolver asks the root servers for the PTR record for 25.2.0.192.in-addr.arpa.
          o The root servers refer the DNS resolver to the DNS servers in charge of the Class A range (192.in-addr.arpa, which covers all IPs that begin with 192).
          o In almost all cases, the root servers will refer the DNS resolver to a "RIR" ("Regional Internet Registry"). These are the organizations that allocate IPs. In general, ARIN handles North American IPs, APNIC handles Asian-Pacific IPs, and RIPE handles European IPs.

          o The DNS resolver will ask the ARIN DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
          o The ARIN DNS servers will refer the DNS resolver to the DNS servers of the organization that was originally given the IP range. These are usually the DNS servers of your ISP, or their bandwidth provider.

          o The DNS resolver will ask the ISP's DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
          o The ISP's DNS servers will refer the DNS resolver to the organization's DNS servers.

          o The DNS resolver will ask the organization's DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
          o The organization's DNS servers will respond with "host.example.com".