It's going to be very hard to see where the connection is blocked from where you're standing but my bet is that a firewall policy above and beyond the access your hosting company provides to you is intercepting the traffic before it hits your seed node. The tech guys at DotEasy helpdesk probably won't have a clue what the problem is but I bet their network and security guys do if they were asked to look into it.
Another option is to set up SSL certificates between your web server and a test machine to see if that resolves the trust issue but my gut feeling is that it won't because access is being blocked at a different level altogether.
I may be wrong on the above but spent days and days of serious headaches with one faucet and as soon as everything was migrated to a VPS, the dreaded 111 error was solved almost instantly. With seed nodes you don't have databases, usernames and password etc to throw further spanners into the works, so troubleshooting the issues should be a bit easier (famous last words).
It's pretty setting easy up a VPS and I can provide you a DigitalOcean one for a few days if it's of any help?
P.S. Are you 100% sure that you've changed your port numbers in the seeder's bitcoin.cpp, main.cpp, protocol.cpp and protocol.h files before you compiled it?
I've decided on self hosting and after many support tickets and phone calls I now have DotEasy pointing my webhost NS records to my master and slave VPS name servers.
However, while the dnsseeder now shows DNS requests and db queries, it does not appear to be logging my client IP addresses nor is it reciprocating information to peers attempting a DNS request. This is reflected in
dnsstats.log1411083359 0 0 0 0 0
1411083559 0 0 0 0 0
1411083959 0 0 0 0 0
1411084759 0 0 0 0 0
and in
dnsseed.dump, which is empty.
On the DNS Seeder I get the following output;
$ 0/1 available (1 tried in 800s, 0 new, 0 active), 0 banned; 48 DNS requests, 4 db queries
On my clients I get the following;
...
1 addresses found from DNS seeds
dnsseed thread exit
connect() to 104.131.20.192:9751 failed after select(): Connection refused (111)
connect() to 104.131.20.192:9751 failed after select(): Connection refused (111)
Cannot connect to kjy2eqzk4zwi5zd3.onion:9751: unsupported network
Cannot connect to kjy2eqzk4zwi5zd3.onion:9751: unsupported network
connect() to 104.131.20.192:9751 failed after select(): Connection refused (111)
Cannot connect to kjy2eqzk4zwi5zd3.onion:9751: unsupported network
Using bind9 my DNS is set up as follows;
Master/etc/hosts127.0.0.1 localhost
127.0.1.1 ns1.cryptodistributed.org ns1
#
/etc/hostnamens1
#
/etc/bind/named.conf.optionsoptions {
directory "/var/cache/bind";
recursion no;
allow-transfer { none; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
#
/etc/bind/named.conf.localzone "cryptodistributed.org" {
type master;
file "/etc/bind/zones/db.cryptodistributed.org";
allow-transfer { 104.131.18.252; };
};
zone "55.131.104.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.104.131.55";
};
#
/etc/bind/zones/db.cryptodistributed.org$TTL 604800
@ IN SOA ns1.cryptodistributed.org. email.cryptodistributed.org. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers
cryptodistributed.org. IN NS ns1.cryptodistributed.org.
cryptodistributed.org. IN NS ns2.cryptodistributed.org.
seed.cryptodistributed.org. IN NS 104.131.20.192.
; A records for name servers
ns1 IN A 104.131.55.112
ns2 IN A 104.131.18.252
seed IN A 104.131.20.192
; Other A records
@ IN A 104.131.53.44
www IN NS 104.131.53.44
#
/etc/bind/zones/db.104.131.55$TTL 604800
@ IN SOA example.com. admin.example.com. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers
IN NS ns1.cryptodistributed.org.
IN NS ns2.cryptodistributed.org.
; PTR records
112 IN PTR ns1.cryptodistributed.org.
252.18 IN PTR ns2.cryptodistributed.org.
44.53 IN PTR
www.cryptodistributed.org.
192.20 IN PTR seed.cryptodistributed.org.
#
Curiously, nslookup and dig do not give the expected output.
Specifically, they are not returning an authorative NS record for subdomain seed.cryptodistributed.org. I had read that bind may be stripping off the authorative answer bit in the reply,
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05514.html, but I am not not sure how I might fix such a problem or whether I may have made some error elsewhere.