Professional Django team
Adrian Andreias | Saturday, December 13th, 2008Our schedule may allow us to accept new web development projects starting the spring of 2009.
(In case you haven’t noticed
) We’re a professional Python and Django development company, seasoned through about a dozen of other programming languages + frameworks.
If you want to outsource a medium to large web project based on Python/Django/JavaScript/jQuery, which requires clean and accessible XHTML and CSS coding, drop me an email at adi{at]elvsoft.com.
At this point we are not interested in creating an IntoDns for you or similar DNS report site. Please do not contact us with this request.
PS: Nope, no updates on IntoDns. We have a features request list, but still no spare time.
LATER EDIT: we currently not accepting any new projects since we’re fully booked.
Kevin Reed says:
I want to thank you for your IntoDNS website service. It is exactly what I am looking to replace the current DNSStuff services that I have been using for years. I’ve paid for their subscription service for the past two years, but find their recent increase of more than 100% to be excessive.
I would rather, donate the $40 that I would have paid them for the subscription this year before they raised their rates to you instead.
If you have a Paypal payment account, please let me know so that I can make tha donation.
Thanks!
spenser says:
There appears to be a *small* bug in result presentation.
In the NS check, when there are two NS listed at the parent, and the two NS return both NS records on a query, the first NS is reported as returning only itself as NS, while the second NS is reported as returning both NS. For example:
NS records got from your nameservers listed at the parent NS are:
a.dxmx.com ['38.117.78.200'] [TTL=3600]
b.dxmx.com ['38.117.78.200', '208.86.1.198'] [TTL=3600]
This was for a query on platformlabs.com. The results were manually checked against the NS.
Dan says:
I just wanted to thank you for making this site available. I too was a longtime user of that other DNS check site, and was none too pleased when they went overboard with their pay service.
Please keep up the great work, it is much appreciated!
Vahid Cyrus says:
hi
i’m admin of persian WHT
i need to create a sample of intodns
if you can help me please send e-mail
Adi Andreias says:
What do you mean by “smaple of intodns” ?
Fashion Jewellery says:
Hi
I am having a small problem here. I am trying to check DNS setup of one of my .Info domains and I am getting this error message.
“”Can’t get nameservers at parent server!I only check domains not subdomains!”"
The thing is, its not a subdomain. I can check for other domain but not this one. Is it because of the “-” in domain name?
The domain I am using is given in my comment details. Please let me know if its possible to check domain with dash signs in them.
Andy says:
Hey, I think that what you have made here is great, and it should be a standard that all web pages pass this test.
That’s why I think you should have a IntoDNS certified badge, a little icon like the w3c validation checks have a certified badge you can put on your site, you should have one to
I would love to have that on my site!
Vishal Agarwal says:
Thanks for a great website.
Yassen says:
Hello and thanks for the great DNSreport alternative!! I want to report a bug (as I see it):
Domain NS records Nameserver records returned by the parent servers are:
ns1.itlabs.bg. ['87.121.47.18'] (NO GLUE) [TTL=172800]
ns9.itlabs.bg. ['78.46.88.171'] (NO GLUE) [TTL=172800]
Then later on, you say:
Same Glue Looks like the A records (the GLUE) got from the parent zone check are different than the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do.I detected some problems as follows:
For ns1.itlabs.bg the parent reported: ['78.46.88.171'] and your nameservers reported: ['95.87.245.188']
For ns9.itlabs.bg the parent reported: ['78.46.88.171'] and your nameservers reported: ['78.46.88.171']
This is a peculiar case when the root servers report a different IP for one of the name servers, than what the very name servers report as IP addresses for themselves. The last statement should be:
Same Glue Looks like the A records (the GLUE) got from the parent zone check are different than the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do.I detected some problems as follows:
For ns1.itlabs.bg the parent reported: ['87.121.47.18'] and your nameservers reported: ['95.87.245.188']
For ns9.itlabs.bg the parent reported: ['78.46.88.171'] and your nameservers reported: ['78.46.88.171']
(And even the second server may not be listed, as there is no problem with it.. but that’s a matter of preference. The first one is not correct, though, and needs a fix.)
Thanks again for this great tool!
Yassen says:
Folks, thanks again for intoDNS! As you can see, I very often come to your site and your service is an essential tool for doing my job…
Another sort of defect that I want to report: Reverse DNS queries seem to go through a DNS cache local to your system and thus does not reflect the latest state of affairs. About 10 hours ago I fixed a problem with an RDSN record for an IP in my network and a bunch of RDNS-checking services now show it is working fine, but intoDNS still reports what was true about 10 hours ago:
“ERROR: No reverse DNS (PTR) entries. The problem MX records are:
xxx.yyy.zzz.ttt.in-addr.arpa -> no reverse (PTR) detected”.
I would suggest making a fresh RDNS request each time a report is requested.
Thanks a lot again,
Keep up the great work!
Sci-Fi Si says:
This is a great website, thank you so much for making it free!
God bless ya’ cottons
Ugur Eskici says:
Thanks for this usefull tool. as scifi said thanks so much for make it free.
Ugur

Categories
Archives