Slashdot Mirror

I don't know if this is the one you are referring to, but I use http://dnsreport.com/ for the quick list of problems, and http://www.dnsstuff.com/ for the rest.

They don't seem to be anymore. http://www.dnsreport.com/tools/dnsreport.ch?domain =slashdot.org is now showing...

OK. Your DNS servers do not announce that they are open DNS servers. Although there is a slight chance that they really are open DNS servers, this is very unlikely. Open DNS servers increase the chances that of cache poisoning, can degrade performance of your DNS, and can cause your DNS servers to be used in an attack (so it is good that your DNS servers do not appear to be open DNS servers).

I guess that shows the slashdot editors actually do read their site sometimes after all!

http://www.dnsreport.com/tools/dnsreport.ch?domain =slashdot.org

FAIL Open DNS servers ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are:

Server 66.35.250.12 reports that it will do recursive lookups. [test]
Server 12.152.184.136 reports that it will do recursive lookups. [test]
Server 12.152.184.135 reports that it will do recursive lookups. [test]

See this page for info on closing open DNS servers.

Although I dont think that DNSReport.com will check for this particular issue, it will at the very least point out many possible issues with your dns configuration.

I used this to troubleshoot our servers a while back. I don't claim to know hardly anything at all about DNS, which is why this tool was so useful for me. I figured out that I had a lot of problems related to my slave updates.

Is it possible these larger DNS servers are updating based on the refresh/expire values instead of the TTL?

I don't know whats up with my ISP, their DNS servers go down quite frequently, probably some jerks playing DoS war, I use a high quality ISP in the area for secondary DNS, never have any problems. I would set up a named server on my network but named is such a bastard to configure, for me anyways.

Why did you need to contact your friends/relatives to check whether or not your domain gets propagated?
Couldn't you just query DNS servers directly using nslookup and/or dig?
Querying them directly would eliminate you from wondering if the machine you are checking from has the DNS cached and you wouln't need to flush it (why would you need your friends/relatives to reboot their machines?). Not to mention the amount of time you would spend in having to coordinate this type of testing.
Even if you don't want to use nslookup and/or dig from your Windows/Linux/Mac/whatever, there are tools available via the web that can help as well.
This certainly is not a list of all the tools, or even the best ones... they're just ones that I have used in the past:

dig Web-based "dig" tool
nslookup Web-based "nslookup" tool
DNS Report Checks for DNS errors and provides nicely formatted information on a given domain
DNS Stuff Various web-based DNS tools

There are many online DNS tools DNS report being one of the best and DNS stuff being very powerful but harder to use. I also like Dig it Man! for simple DNS checks. Also many large internet providers usually have allkinds of online network tools available online on their webpages.

Hmm - seems OK.

Wow, their DNS is stuffed.
http://www.dnsreport.com/tools/dnsreport.ch?domain =nyud.net

DNS Report DNS Report for panix.comGenerated by www.DNSreport.com at 13:18:18 GMT on 16 Jan 2005. status = "Getting data from root..."; CategoryStatusTest NameInformation Parent PASSMissing Direct Parent checkOK. Your direct parent zone exists, which is good. Some domains (usually third or fourth level domains, such as example.co.us) do not have a direct parent zone ('co.us' in this example), which is legal but can cause confusion. INFONS records at parent serversYour NS records at the parent servers are:
ns1.ukdnsservers.co.uk. [142.46.200.67 (NO GLUE)] [CA] ns2.ukdnsservers.co.uk. [207.61.90.196 (NO GLUE)] [CA] [These were obtained from f.gtld-servers.net] PASSParent nameservers have your nameservers listedOK. When someone uses DNS to look up your domain, the first step (if it doesn't already know about your domain) is to go to the parent servers. If you aren't listed there, you can't be found. But you are listed there WARNGlue at parent nameserversWARNING. The parent servers (I checked with f.gtld-servers.net.) are not providing glue for all your nameservers. This means that they are supplying the NS records (host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of "ns1.example.org" for the domain "example.com"). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain. status = "Waiting for NS results from your nameservers..."; NS INFONS records at your nameserversYour NS records at your nameservers are:
ns1.ukdnsservers.co.uk. [TTL=86400] ns2.ukdnsservers.co.uk. [TTL=86400] PASSAll nameservers report identical NS recordsOK. The NS records at all your nameservers are identical. PASSAll nameservers respondOK. All of your nameservers listed at the parent nameservers responded. PASSNameserver name validityOK. All of the NS records that your nameservers report seem valid (no IPs or partial domain names). PASSNumber of nameserversOK. You have 2 nameservers. You must have at least 2 nameservers (RFC2182 section 5 recommends at least 3 nameservers), and preferably no more than 7. PASSLame nameserversOK. All the nameservers listed at the parent servers answer authoritatively for your domain. PASSMissing (stealth) nameserversOK. All 2 of your nameservers (as reported by your nameservers) are also listed at the parent servers. PASSMissing nameservers 2OK. All of the nameservers listed at the parent nameservers are also listed as NS records at your nameservers. PASSNo CNAMEs for domainOK. There are no CNAMEs for panix.com. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. Note that I only checked panix.com, I did not check the NS records, which should not have CNAMEs either. PASSNo NSs with CNAMEsOK. There are no CNAMEs for your NS records. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. WARNNameservers on separate class C'sWARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location. PASSAll NS IPs publicOK. All of your NS records appear to use public IPs. If there were any private IPs, they would not be reachable, causing