We’re back with the blog!
We know the blog link has not been working in the last months, we know that the feedback link wasn’t working, we know that there are features that admin folks need and expect.

But here’s the deal: IntoDNS is our passion project. Passion leads to great projects, but sometimes (read “always”) the MUST DO tasks (read customers ) get in the way of passion projects and tasks. But I’m sure you already knew and been living that.

We’ve been reading a lot of concerns about IntoDNS becoming a paid site, just like other similar tools (*cough* dnsr… something… *cough*). It’s something you shouldn’t worry about. As stated in some earlier posts (that you couldn’t read anyway due to the blog being down ), IntoDNS will continue to remain free as long as we can afford to host it (and as a hosting & web development company I don’t see how we won’t afford that in the following hundred years ).

We have a lot of plans for IntoDNS, and so few hours to spare in our schedules. I can only promise you that IntoDNS will continue to be free. I can also promise you that we will _try_ to add the needed and asked features.
And one more thing, thank you for using it, thank you for spreading the word and thank you to all those world-wide guys that sent us feedback and reported bugs. Keep them coming! And if you want to help: just spread the word, spread your love!

Yours,

Cristian Tomoiaga, IntoDNS brain, admin, root and knowledge container (and not to mention forest administrator),
Adi Andreias post author and minor IntoDNS features implementer,
from Elvsoft, the authors of IntoDNS

Examples where results will not be accurate:

SPF checks – a lot of people add a SPF record without having any clue if that record is really ok. It’s impossible to test with intoDNS or any other tool like it since we do not know if your e-mail is really going out through your MX or through another IP different than the one(s) listed as your MX.

Mail checks – The same as in the case of SPF, we do not know if your e-mail really goes out through your MX records, we only assume that.

The delays have almost nothing to do with the speed of our servers or the servers we test. A lot of delays are caused by how a SMTP server is configured.
Let’s take Exim for example which is used on all servers with cPanel.
This SMTP server by default does an ident request to the client or server that connects to it and only after an answer to that request is received or a timeout occurs (in most cases), the welcome message is sent. If you have cPanel on your server and have not modified the exim configuration manually, try a telnet to your SMTP host on port 25. You will most likely see a few seconds delay before the welcome message appears. This is happening in most cases because your SMTP server is doing that ident request. Do you have an ident server installed on your computer? No of course you don’t! Do your clients have one installed? No of course they don’t!

Identd is pointless and potentially dangerous and should not be used at all. You should consider changing your server settings not to use ident requests. In Exim you can do that by setting rfc1413_query_timeout to 0. After disabling the ident lookup, try telnetting again and see the difference.

Of course, ident is not the only problem that causes those delays. Another major problem in my opinion is that some servers verify the senders by connecting to the host that is sending the e-mail. This is not good at all, even if it seems to be very useful in preventing spam. Most of the spammers have very little understanding of what’s going on around them, but that doesn’t mean they will not adapt to changes.

Have you ever seen yahoo or Gmail connecting to one of your SMTP servers in order to verify the existence of an e-mail address? This will only lead to some mail being lost; it’s almost useless and will have an impact on your server’s performance. I recommend not using this type of verification at all.

I also agree that the Mail tests need to be improved along with other tests and we are doing our best.

What?

IntoDNS checks the health and configuration of DNS servers and mail servers. It’s designed as a tool that helps server and network administrators in day to day job, to identify and fix DNS and mail issues.

Who?

IntoDNS is developed by a team of professionals from Elvsoft. Cristian Tomoiaga, an experienced system administrator, is the main project developer. Ovidiu Mocan and Adi Boiciuc worked on the graphic design and the clean XHTML & CSS code. Adi Andreias contributes to some of the tests and coordinates the whole project.

How?

We chose Python because it’s an elegant and powerful language with great multithreading support. And multithreading is crucial for IntoDNS’ performance. Django sets the web stage for Python and jQuery helps us with some of the tricks.

Where (are the ads)?

A strong project is a project that can sustain itself. But we don’t like web sites that have more ads then content. We don’t plan to overload intodns.com with screaming ads. When we’ll need a bunch of servers to sustain the traffic we ll probably come up with some sponsorship model with a single, small, nonintrusive and industry related ad. Drop us a line if you want to sustain IntoDNS.

Where to?

We plan to continue to improve IntoDNS and make it the best DNS health checker on the web. Feedback is very important to us. So don’t be shy.