A friendly reminder from a sysadmin/web app developer who has to deal with dns and network issues in the real world and would like to use a nice clean UI tool like this: Lack of IPv6 support is a deal breaker.
This is very useful, and to call it disappointing is rude to the creator of the tool. Why would you say something so negative just because it's not perfect? This is the problem with Hacker News these days - people can't wait to say something nasty.
It's a nice website, but developers would be more inspired to try tools such as dnrd which allows one to run multiple dns servers on one machine and reverse-proxy the requests.
Ex on my dsl modem where I love to test stuff:
dnrd-port53 -a 192.168.178.1 -m off -s 127.0.0.1:mydomain.com -s 127.0.0.2:local -s 127.0.0.4:fritz.box -s 127.0.0.4:178.168.192.in-addr.arpa -s 213.16.20.51 -s 213.188.172.70 -s 74.82.42.42 -u dns -R /tmp/dnrd -l
This runs dnrd (hardcoded to bind on port 53 - I sometimes use other ports), and case switch the requests :
if it ends by .mydomain.com, it goes to 127.0.0.1
if it ends by .local, it goes to 127.0.0.2
if it ends by .fritz.box, it goes to 127.0.0.4
if it ends by .178.168.192.in-addr.arpa (reverse), it goes to 127.0.0.4
everything else goes to 213.16.20.51, 213.188.172.70, 74.82.42.42 : if one stops responding it's removed from the list and the others are used.
THAT is a tool for developpers.
Shameless plug : bind6.c on http://code.google.com/p/guylhem/source/browse/bind6.c : if you also have a fritzbox dsl modem, you can "force bind" its default dns server to a given ip:53 instead of *:53, allowing another servers on say 127.0.0.1 :
It seems this was posted by the developer of this site himself, so I've got a feature request: combining these tools.
For example, you enter a domain name or IP address and you get the following information:
- DNS report
- Reverse IP
- Port scan
- Chinese/Iran Firewall test
- DNSSEC
- IP location (maybe of nameserver IPs as well?)
- PageRank check
- Traceroute
- Ping
- DNS records
- HTTP headers
- Spam DB lookup
- ASN
Adding this would make things a whole lot easier, I hope you will consider it!
The DNS propagation checker -- is there an existing framework that this site interfaces or is it something that they rolled out on their own? I've seen some services that use a dozen of servers to run the check, but this is hardly sufficient ad it excludes the last mile (where all the fun stuff is).
I think it is especially amusing that (according to viewdns.info), dnssec.net itself does not have DNSSEC enabled (while it is producing a response for verisign.com for example). Thoughts on the virtues of DNSSEC? Why are you (not) using it?
I'm interested in more details about how the "Iran Firewall Test" works. It shows my site as blocked, while I can confirm it elsewhere, it would be nice to know how this determined that.
I suspect it's getting hammered at the moment -- the Iran check returned an error for me, and the Google page rank check for "google.com" or "yahoo.com" still reports "Sorry, we couldn't seem to find that domain in Google's cache."
To the developer: this is a great time to refine the error handling (plus scaling, of course). :)
E.g., make sure when the requests fail (for whatever reason) that it can report this back to the user clearly.
+1 for having an API. I'm increasingly on a rampage to replace anything I currently have to do via GUI or web browser with something I can do via CLI or API. So much faster, more automatable, less visual fluff and cognitive overhead.
[+] [-] zaphoyd|14 years ago|reply
EDIT: for friendliness.
[+] [-] gabyar|14 years ago|reply
[+] [-] guylhem|14 years ago|reply
Ex on my dsl modem where I love to test stuff:
dnrd-port53 -a 192.168.178.1 -m off -s 127.0.0.1:mydomain.com -s 127.0.0.2:local -s 127.0.0.4:fritz.box -s 127.0.0.4:178.168.192.in-addr.arpa -s 213.16.20.51 -s 213.188.172.70 -s 74.82.42.42 -u dns -R /tmp/dnrd -l
This runs dnrd (hardcoded to bind on port 53 - I sometimes use other ports), and case switch the requests : if it ends by .mydomain.com, it goes to 127.0.0.1 if it ends by .local, it goes to 127.0.0.2 if it ends by .fritz.box, it goes to 127.0.0.4 if it ends by .178.168.192.in-addr.arpa (reverse), it goes to 127.0.0.4 everything else goes to 213.16.20.51, 213.188.172.70, 74.82.42.42 : if one stops responding it's removed from the list and the others are used.
THAT is a tool for developpers.
Shameless plug : bind6.c on http://code.google.com/p/guylhem/source/browse/bind6.c : if you also have a fritzbox dsl modem, you can "force bind" its default dns server to a given ip:53 instead of *:53, allowing another servers on say 127.0.0.1 :
killall multid; LD_PRELOAD=bind6.so BIND_IPV6=::ffff:127.0.0.4 /sbin/multid -v -d -U -P
[+] [-] flyt|14 years ago|reply
google.com domain report: http://www.robtex.com/dns/google.com.html#summary
google AS peering info: http://www.robtex.com/as/as15169.html#peer
netblock info: http://www.robtex.com/route/74.125.0.0-16---google.html
[+] [-] JOfferijns|14 years ago|reply
It seems this was posted by the developer of this site himself, so I've got a feature request: combining these tools. For example, you enter a domain name or IP address and you get the following information:
- DNS report
- Reverse IP
- Port scan
- Chinese/Iran Firewall test
- DNSSEC
- IP location (maybe of nameserver IPs as well?)
- PageRank check
- Traceroute
- Ping
- DNS records
- HTTP headers
- Spam DB lookup
- ASN
Adding this would make things a whole lot easier, I hope you will consider it!
[+] [-] redler|14 years ago|reply
[1] http://viewdns.info/api/
[+] [-] rebelde|14 years ago|reply
[+] [-] ioquatix|14 years ago|reply
[+] [-] gergles|14 years ago|reply
"Oops! Your SOA serial number (2012041402) doesn't seem to be in the recommended format (YYYYMMDDnn - where nn is the revision number)."
Looks like it's in that format to me?
[+] [-] jbarham|14 years ago|reply
http://www.dnsvalidation.com/ is also a nicely done site for checking DNS configuration.
[+] [-] stock_toaster|14 years ago|reply
[1]: http://www.nlnetlabs.nl/projects/ldns/
[+] [-] ranit8|14 years ago|reply
[deleted]
[+] [-] huhtenberg|14 years ago|reply
[+] [-] stevenjgarner|14 years ago|reply
[+] [-] brokentone|14 years ago|reply
[+] [-] jtheory|14 years ago|reply
To the developer: this is a great time to refine the error handling (plus scaling, of course). :)
E.g., make sure when the requests fail (for whatever reason) that it can report this back to the user clearly.
[+] [-] nphase|14 years ago|reply
[+] [-] kenny_r|14 years ago|reply
[+] [-] known|14 years ago|reply
[+] [-] clippit|14 years ago|reply
[+] [-] mkramlich|14 years ago|reply
[+] [-] huoju|14 years ago|reply