DNSCheck is a program that was designed to help people check, measure and hopefully also understand the workings of the Domain Name System, DNS. When a domain (aka zone) is submitted to DNSCheck it will investigate the domain’s general health by traversing the DNS from root (.) to the TLD (Top Level Domain, like .SE) to eventually the nameserver(s) that holds the information about the specified domain (like iis.se). Some other sanity checks, for example measuring host connectivity, validity of IP-addresses and control of DNSSEC signatures will also be performed.
The domain name system (DNS in short) is what could be called the “phone book” of the Internet. It keeps track of the mapping of, for example, a human-readable website name (like www.iis.se) to the slightly more arcane form of an IP-address that the computer needs to initiate communication (in this case 188.8.131.52).
Besides browsing the Internet with your web browser using website names instead of IP-addresses the DNS also makes sure your emails find their way to the right recipient. In short, a stable DNS is vital for most companies to maintain a working and efficient operation.
The webpage www.dnscheck.se points to an earlier version of DNSCheck that .SE developed with the help of Patrik Fältsröm of Frobbit AB. The new version of DNSCheck resides in dnscheck.iis.se and was developed by Jakob Schlyter of Kirei AB.
.SE wanted a better control of the code and also the ability to reuse parts of the DNSCheck code in other projects. Thus we came to the conclusion that it was a better idea to start from scratch and build a modular codebase that we could also add new features to, like for example ipv6- and dnssec-controls.
If you want the technical information about how DNSCheck operates you are advised to check the wiki/trac connected to the DNSCheck open source project. This is the URL: https://github.com/dotse/dnscheck/wiki/Architecture . If you want a less technical answer you should check the first FAQ-question: “What is DNSCheck”.
The current version of DNSCheck was made for technicians or at least people who are interested to learn more about how the DNS operates. If you merely want to show whoever is in charge of your domain (the tech-c or technical staff at your name server provider) that there in fact is a problem with your domain you can use the link that appears on the bottom of the page after each test. So if you have run a test and want to show someone the result of that specific test you can just copy the link at the bottom of the page that displays your test results. The link below, for example, points at a previous test on "iis.se":
Of course, this depends on what kind of test failed for your zone. In most cases you can press the actual error/warning-message and in so doing get more detailed information about what kind of problem that was found.
As an example if we test the domain "iis.se" and recieve an error titled “Name server ns.nic.se (184.108.40.206) does not answer queries over UDP”. What does this mean? After we click this message more detailed information become visible. More specific this: “The name server failed to answer queries sent over UDP. This is probably due to the name server not correctly set up or due to misconfigured filtering in a firewall.”. Luckily this was just an example, that error basically means the name server is down so it’s not the most harmless error around.
There is no final judgement of the health of a domain that can be bestowed by anyone. This is very important. .SE and the people behind DNSCheck do not claim that DNSCheck is correct in every aspect. Sometimes opinions differ, especially between countries, but sometimes also locally. We have had the luck to have the help of an extremely competent DNS-group here in Sweden. Hopefully their opinions in combination with ours have made a good compromise between what is an actual potentially dangerous error and what could be merely seen as a notice or warning.
But as with all things as evolving as DNS the situation is most likely changing, what is a notice today could be an error tomorrow. If you really think we’ve made a mistake in our judgement please don’t hesitate to drop us an email at firstname.lastname@example.org with a link to your test and an explanation why you think it shows something that you consider incorrect. ( If you don’t know how to find the link to your test, check the "How can DNSCheck help me"-part of this FAQ ).
Yes, it does. All tests run over IPv4 will also be run over IPv6 if DNSCheck is configured to do so.
Yes, if DNSSEC is available on a domain that is sent to DNSCheck it will be checked automatically.
First of all this DNSCheck saves all history from earlier tests, which means you can go back to a test you did a week ago and compare it to the test you ran a moment ago.
DNSCheck also controls that the name servers a zone has used previously no longer contains information about the zone you’re testing (this only applies to .SE-domains that have been redelegated after February 2007).
DNSCheck will also try and explain the error/warning to you in a good way, although these messages can be difficult to understand for a non-technician. The next version of DNSCheck, that will be launched later this year, will be more compliant to non-technician users.
DNSCheck will continuously scan the .SE-zone and report its health into the database.
There’s an “advanced” tab for technicians who might want to use DNSCheck without the “basic” view.
Lastly, this open source version of DNSCheck was built using modular code which, basically, means you can use parts of it in your systems, if you’d want to. It’s quite rare that you’d want a complete program just to check for example redelegations.
Yes. All the checks that occur for .SE-domains will be used on your zone as well. However, the periodic sweep of the database (automatic checks basically) only happens on .SE-domains, other than that it’s identical.
Since DNSCheck is open to everyone it is possible for anyone to check your domain and also see history from previous tests, however there is no way to tell who has run a specific test since nothing is logged except the time of the test.
If we skip the situation where the domain doesn’t exist, as in you input a non-existing domain to DNSCheck, there are 2 other possibilites:
1. To protect the engine from multiple identical inputs, that is the same IP checking the same zone several times, there is a delay of 5 minutes between identical subsequent tests. Which practically means that you can only test the same domain once every 5 minutes, if you try and test it again within 5 minutes the last results will be displayed instead.
2. Because DNSCheck was made to check domains (like iis.se) and not hostnames in a domain (like www.iis.se) the DNSCheck webpage will do a pre-control of your domain before it sends it on to the engine for testing. This shouldn’t effect the great majority of domains out there but it CAN do so, because if the webpage decides a domain doesn’t exist the check wont run. Sofar the only time we’ve seen this is when a domains’ nameservers all lie within the domain that’s being tested and these are very broken. We need to fix this, and please do report if you cannot check your domain so that we can see if anything else is wrong. This control will be improved, that’s a promise.
This question is very hard to answer since DNSCheck will generate different queries depending on how your name servers answer. The easiest way to get a full view of what queries and results are generated is to run the “dnscheck” CLI command and add the flag “--raw”. This will result in quite thorough information on what is happening. However the output from this CLI-tool is quite heavily technical so unless you’re into bits and bytes you might want to skip this step. :)
An undelegated domain test is a test performed on a domain that may, or may not, be fully published in the DNS. This can be quite useful if you are going to move your domain from one registrar to another. For example, let us say that you want to move your zone example.se from the nameserver ’ns.nic.se’ to the nameserver ’ns.iis.se’. In this scenario you could perform an undelegated domain test providing the zone (example.se) and the nameserver you are moving to (ns.iis.se) BEFORE you move your domain. When this test shows a green light you can be fairly certain that the new location for your domain at least knows that it is supposed to be replying to queries about your domain. However there might still be other problems in the zone data itself that this test is unaware of.