A few days ago Ian West pointed me an bug. In some rare cases DnsValidation.com was unable to complete running reports. I've studied the problem and found the bug in packet decoding layer, ldns was unable to decode received DNS data. The bug was fixed today.

I've created a credits page here:
http://www.dnsvalidation.com/wiki/Credits

Thank you, Ian !

After design cleanup and a few page size optimizations made last week, today I'm introducing report navigation. This new information gives you an overview for each section (FAIL count, WARN count) which helps to read the report and includes direct links to sections for easier navigation.

Previous week I've deployed a new version of DnsValidation.com which brings a new asynchronous architecture based on EventMachine which makes DNS reports really fast (on average ~7 seconds/report). Now most of delay is produced by mail servers  and its RBL checks, I still need to make some fine tunings.

While working on this release I've learned a few things:

• Event-driven programming is hard, it's very easy to lock the entire process while waiting for event/condition that will never happen :)
• Extending Ruby is fun
• Starbucks may not have the best coffee, but it's a great way to escape from daily routine (warm ambiance, free WiFi and AC Power included)

Changes:

• Asynchronous architecture - checks are executed in parallel which leads to faster reports
• IDN (Internationalized Domain Names) support:
  
  • Example reports:
    • Gartenmöbel.de - ”garden furniture” in German
    • 网站目录.com - Chinese
    • 스타벅스코리아.com - Starbucks Korea
    • аромат.com - Russian Shop
• TLD DNS reports:
  
  • Example TLD reports
    
    • .com
    • .travel
    • .fr
    • .ly
    • .cz
    • .ru
• DomainKeys checks removed as everyone is migrating to it's successor DKIM (no DKIM checks right now).

References:
http://www.idnguru.com/idn-language-list/

I will migrate today the website to a new asynchronous architecture which will improve report generation speed so I you may see sporadically the error page while I'm migrating the database.

Last week I've been busy working on DNS Validation and starting with yesterday the website has has a new face after a complete redesign. The project has a new logo, a new look and special attention was allocated to printing reports support.

I hope you enjoy the new design as I do. If you have any problems or suggestions regarding new design please don't hesitate to contact me.

A new DNS check is ready: "Glue Mismatch" under NS section.

While querying nameservers often they do provide A or AAAA records in additional section of the response to help/speed up host name resolution, those records are named glue records.

You can examine a DNS query to see glue records from command line with dig:

[vitalie@silver ~]$ dig mx redhat.com @ns1.redhat.com

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> mx redhat.com @ns1.redhat.com
 ;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2912
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5

;; QUESTION SECTION:
 ;redhat.com.                    IN      MX

;; ANSWER SECTION:
redhat.com.             600     IN      MX      5 mx1.redhat.com.
 redhat.com.             600     IN      MX      10 mx2.redhat.com.

;; AUTHORITY SECTION:
redhat.com.             600     IN      NS      ns2.redhat.com.
 redhat.com.             600     IN      NS      ns3.redhat.com.
redhat.com.             600     IN      NS      ns1.redhat.com.
 
;; ADDITIONAL SECTION:
mx1.redhat.com.         600     IN      A       209.132.183.28
mx2.redhat.com.         600     IN      A       66.187.233.33
 ns1.redhat.com.         600     IN      A       66.187.233.210
ns2.redhat.com.         600     IN      A       209.132.183.2
ns3.redhat.com.         600     IN      A       209.132.176.100
 
;; Query time: 150 msec
;; SERVER: 66.187.233.210#53(66.187.233.210)
;; WHEN: Wed Nov  3 15:05:56 2010
;; MSG SIZE  rcvd: 202

In this example while querying MX records from ns1.redhat.com I've received the IP addresses of the mail exchangers:

mx1.redhat.com.         600     IN      A       209.132.183.28
mx2.redhat.com.         600     IN      A       66.187.233.33

Sometimes you may mess up IP addresses for your nameservers (example IPs provided by your nameserves are different by IPs provided by your registrar), this new check should catch this problem.

Check your domain's glue records here:

http://www.dnsvalidation.com/