Help with DNS Seeder and hardcoded Seednodes

[12sided-dice]

***************************************************
SOLUTIONS POSTED FOLLOWING QUESTIONS
***************************************************

I'm creating an altcoin based on Pfennig (https://github.com/project-bitmark/pfennig), the cloneable reference implementation of Bitmark (https://github.com/project-bitmark/bitmark), in order to gain a deeper understanding of cryptocurrency.  This coin is not going to market. It's intended only as a means of educating myself about different cryptocurrencies and their inner workings.

Please don't poop on me with posts about crappy altcoins, etc.

The difficulties I'm experiencing are as follows;

1. Clients do not connect to seednodes;

chainparams.cpp
22   unsigned int pnSeed[] =
23   {
24                0x688312e4 // Updated seed node
25   };

After first run to set the rpcuser and rpcpassword, the daemon does not attempt to connect to hardcoded seed nodes.
In the above example, taken from the coin source, shows the hex IP of my VPS seednode at 104.131.20.192.

The VPS at 104.131.20.192 is set to listen using the following;

./betacoind -listen=1 -printtoconsole &

and reports the following;


Betacoin version v0.9.2.1-7ecf3af-dirty-beta (2014-08-16 21:43:28 -0400)
Using OpenSSL version OpenSSL 1.0.1e 11 Feb 2013
Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
Default data directory /home/ubox/.betacoin
Using data directory /home/ubox/.betacoin
Using at most 125 connections (1024 file descriptors available)
Using 8 threads for script verification
Using wallet wallet.dat
init message: Verifying wallet...
CDBEnv::Open : LogDir=/home/ubox/.betacoin/database ErrorFile=/home/ubox/.betacoin/db.log
Bound to [::]:9751
Bound to 0.0.0.0:9751
init message: Loading block index...
Opening LevelDB in /home/ubox/.betacoin/blocks/index
Opened LevelDB successfully
Opening LevelDB in /home/ubox/.betacoin/chainstate
Opened LevelDB successfully
LoadBlockIndexDB(): last block file = 0
LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=1, size=254, heights=0...0, time=2014-08-16...2014-08-16)
LoadBlockIndexDB(): transaction index disabled
LoadBlockIndexDB(): hashBestChain=c44dec01e2ba3f7d0376654b4fb790fd0e3e7c2996c389a57ca3e48270f1c57a height=0 date=2014-08-16 02:36:49 progress=0.000008
init message: Verifying blocks...
 block index             126ms
init message: Loading wallet...
nFileVersion = 90201
Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total
 wallet                  160ms
init message: Loading addresses...
Loaded 1 addresses from peers.dat  0ms
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
ext-ip thread start
dnsseed thread start
Loading addresses from DNS seeds (could take a while)
opencon thread start
addcon thread start
net thread start
msghand thread start
dumpaddr thread start
init message: Done loading
1 addresses found from DNS seeds
dnsseed thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
GetMyExternalIP() received [184.75.210.198] 184.75.210.198:0
GetMyExternalIP() returned 184.75.210.198
AddLocal(184.75.210.198:9751,4)
ext-ip thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)


SOLVED:
https://bitcointalk.org/index.php?topic=775332.msg8901349#msg8901349
https://bitcointalk.org/index.php?topic=34586.msg1983185#msg1983185

2. Clients only connect when using -connect or -addnode commands;


After first run to set the rpcuser and rpcpassword, the daemon will only connect to another client if using -addnode or -connect commands.
Using the following command, I am able to connect a client to my seednode at 104.131.20.192 ;

./betacoind -listen=1 -connect=104.131.20.192 &

and successfully mine blocks using;

./betacoind -listen=1 -gen=1 -connect=104.131.20.192 &

SOLVED:
This was the result of improper pnSeed formatting and broken DNS seed.  Peers now connect automatically via seednode or dns.

3. Client does not pull from peers.dat;

On all subsequent instances of the daemon no connection is made unless -connect or -addnode is specified.
The following instance of the daemon results in no connections despite having peers in the peer.dat file.

./betacoind -listen=1 -gen=1

Why is the client not pulling peers from the peer.dat file?



4. Clients are not able to connect to the DNS Seeder;

The DNS seeder shows no attempted connections.

I have my domain configured with both and A record and NS record as follows;

A Record:
seed.cryptodistributed.org                 104.131.53.44
www.seed.cryptodistributed.org             104.131.53.44


NS Record:
cryptodistributed.org               seed.cryptodistributed.org

Which appears to be functioning correctly as per
https://www.whatsmydns.net/#A/seed.cryptodistributed.org

The address of the dnsseed is entered as such in;
chainparams.cpp
64    vSeeds.push_back(CDNSSeedData("cryptodistributed.org", "seed.cryptodistributed.org"));

On the clients attempting to connect:

Betacoin version v0.9.2.1-7ecf3af-dirty-beta (2014-08-16 21:43:28 -0400)
Using OpenSSL version OpenSSL 1.0.1e 11 Feb 2013
Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
Default data directory /home/ubox/.betacoin
Using data directory /home/ubox/.betacoin
Using at most 125 connections (1024 file descriptors available)
Using 8 threads for script verification
Using wallet wallet.dat
init message: Verifying wallet...
CDBEnv::Open : LogDir=/home/ubox/.betacoin/database ErrorFile=/home/ubox/.betacoin/db.log
Bound to [::]:9751
Bound to 0.0.0.0:9751
init message: Loading block index...
Opening LevelDB in /home/ubox/.betacoin/blocks/index
Opened LevelDB successfully
Opening LevelDB in /home/ubox/.betacoin/chainstate
Opened LevelDB successfully
LoadBlockIndexDB(): last block file = 0
LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=1, size=254, heights=0...0, time=2014-08-16...2014-08-16)
LoadBlockIndexDB(): transaction index disabled
LoadBlockIndexDB(): hashBestChain=c44dec01e2ba3f7d0376654b4fb790fd0e3e7c2996c389a57ca3e48270f1c57a height=0 date=2014-08-16 02:36:49 progress=0.000008
init message: Verifying blocks...
 block index             126ms
init message: Loading wallet...
nFileVersion = 90201
Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total
 wallet                  160ms
init message: Loading addresses...
Loaded 1 addresses from peers.dat  0ms
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
ext-ip thread start
dnsseed thread start
Loading addresses from DNS seeds (could take a while)
opencon thread start
addcon thread start
net thread start
msghand thread start
dumpaddr thread start
init message: Done loading
1 addresses found from DNS seeds
dnsseed thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
GetMyExternalIP() received [184.75.210.198] 184.75.210.198:0
GetMyExternalIP() returned 184.75.210.198
AddLocal(184.75.210.198:9751,4)
ext-ip thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)


On the DNS seeder:

./dnsseed -h seed.cryptodistributed.org -n 104.131.53.44
Starting 4 DNS threads for seed.cryptodistributed.org on 104.131.53.44 (port 53) ......done
Starting seeder...done
Starting 96 crawler threads...done
0/2 available (2 tried in 100s, 0 new, 0 active), 0 banned; 0 DNS requests, 4 db queries

SOLVED:

In the dnsseeder, main.cpp:
Line 351
 - db.Add(CService("kjy2eqzk4zwi5zd3.onion", 9751), true);
+ db.Add(CService("104.131.18.228", GetDefaultPort()), true);

DNS seeder serves peers from seednode.


I will happily provide additional details if anyone has an idea as to what might be the problem.
Thanks!

[esotericizm]

I find it easier just to manually edit the zone file config.

[12sided-dice]

Hi esotericizm, thanks for the suggestion.
As far as I can tell the DNS appears to be properly configured;

$ nslookup seed.cryptodistributed.org

Server:     8.8.8.8
Address:   8.8.8.8:53

Non-authoritative answer:
Name:  seed.cryptodistributed.org
Address:  104.131.53.44

however when I run:

dig -t NS seed.cryptodistributed.org

;;Question Section:
;seed.cryptodistributed.org.   IN     NS

;;AUTHORITY SECTION
cryptodistributed.org.   IN   SOA   dns5.doteasy.com hostmaster.doteast.com

I contacted my hosting provider but they said it looks correct.
Re-reading https://bitcointalk.org/index.php?topic=599623.0 I'm now wondering if I should have created an NS record like so;

NS Record:
seed.cryptodistributed.org     104.131.53.44

Rather than;

cryptodistributed.org        seed.cryptodistributed.org 

[PereguineBerty]

It's kinda clutching at straws here but could there be any kind of firewall or router blocking the connection?

Bitcoin 111 errors are because of RPC access being blocked. Although slightly different, I've had nightmare problems in the past with faucets that refuse connections when used on webhosts rather than a dedicated VPS setup. Even jailbroken hosting plans don't give as much access as they would have you believe.

An NS record is pretty important and a lot of hosts won't allow you to change one (even if you ask their support for a record change). If you come up against a brick wall, my suggestion is that you try to host the seeder and website yourself on a cheap VPS. You can't beat DigitalOcean's VPSs for the flexibility you get at such a small cost if you find that the hosts aren't accommodating your requests.

[12sided-dice]

It's kinda clutching at straws here but could there be any kind of firewall or router blocking the connection?

Bitcoin 111 errors are because of RPC access being blocked. Although slightly different, I've had nightmare problems in the past with faucets that refuse connections when used on webhosts rather than a dedicated VPS setup. Even jailbroken hosting plans don't give as much access as they would have you believe.

An NS record is pretty important and a lot of hosts won't allow you to change one (even if you ask their support for a record change). If you come up against a brick wall, my suggestion is that you try to host the seeder and website yourself on a cheap VPS. You can't beat DigitalOcean's VPSs for the flexibility you get at such a small cost if you find that the hosts aren't accommodating your requests.

The connection isn't blocked, as far as I can tell, and netstat shows the dnsseed listening on port 53.

I'm using DotEasy as my webhost which could be the problem.  I've changed my NS record to point to my vps rather than the subdomain, but I'll have to wait for the change to take effect before I can confirm that it was the issue. Considering their support had no idea what I was talking about I'll probably have to try hosting the website on a vps.

Any thoughts on why the client isn't connecting to previously connected peers?

[PereguineBerty]

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?

[12sided-dice]

I'm going to try hosting the website on a vps and see if that resolves the issue.
Thank you very much for offering a vps for a few days but I've already got a few cheap digitalocean vps'.

I re-checked the ports on the seeder for sanity and it looks fine.

[12sided-dice]

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.log

1411083359 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/hosts

127.0.0.1    localhost
127.0.1.1    ns1.cryptodistributed.org ns1

#

/etc/hostname

ns1

#

/etc/bind/named.conf.options

options {
        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.local

zone "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.

[iGotSpots]

You are making it much harder than needed. The seednode in the source should be like coin.seednode.org - Then you point that DNS to your node(s). When it looks for a seednode it looks for a list of IPs to basically addnode

This is why you only have connections through addnodes

[bee7]

FYI:

NS record should point to FQDN (see http://www.rfc-editor.org/rfc/rfc1035.txt, chapter 3.3.11), that may not belong to specifically this domain, which in turn must have an A record in its zone. So basically all you need is this:

Code:

seed.cryptodistributed.org.  IN  NS  seedvps.cryptodistributed.org.
seedvps  IN  A  a.b.c.d

and the host a.b.c.d must run your dnsseed daemon.

[12sided-dice]

You are making it much harder than needed. The seednode in the source should be like coin.seednode.org - Then you point that DNS to your node(s). When it looks for a seednode it looks for a list of IPs to basically addnode

This is why you only have connections through addnodes

FYI:

NS record should point to FQDN (see http://www.rfc-editor.org/rfc/rfc1035.txt, chapter 3.3.11), that may not belong to specifically this domain, which in turn must have an A record in its zone. So basically all you need is this:

Code:

seed.cryptodistributed.org.  IN  NS  seedvps.cryptodistributed.org.
seedvps  IN  A  a.b.c.d

and the host a.b.c.d must run your dnsseed daemon.

 

Now I see! I've been going crazy but I see now where the problem is. I should set up my dns like this;

; Name servers
cryptodistributed.org.    IN    NS    ns1.cryptodistributed.org.
cryptodistributed.org.    IN    NS    ns2.cryptodistributed.org.
seed.cryptodistributed.org.  IN  NS  seedvps.cryptodistributed.org.

; A records for name servers
ns1    IN    A    104.131.55.112
ns2    IN    A    104.131.18.252
seedvps    IN    A    104.131.20.192

and in the coin like so;

chainparams.cpp
vSeeds.push_back(CDNSSeedData("cryptodistributed.org", "seedvps.cryptodistributed.org"));

Superficially, this looks redundant to me and is probably the reason why I had failed to understand.
Going to try this tonight.

[bee7]

Just one correction:

chainparams.cpp
vSeeds.push_back(CDNSSeedData("cryptodistributed.org", "seed.cryptodistributed.org"));

[12sided-dice]

I configured my DNS as:

; Name servers
cryptodistributed.org.    IN    NS    ns1.cryptodistributed.org.
cryptodistributed.org.    IN    NS    ns2.cryptodistributed.org.
seed.cryptodistributed.org.  IN  NS  seedvps.cryptodistributed.org.

; A records for name servers
ns1    IN    A    104.131.55.112
ns2    IN    A    104.131.18.252
seedvps    IN    A    104.131.20.192

And chainparams.cpp as I originally had it configured;

vSeeds.push_back(CDNSSeedData("cryptodistributed.org", "seed.cryptodistributed.org"));

but I am now getting the following error;

connect() to 228.18.131.104:9751 failed: Network in unreachable (101)
Cannot connect to kjy2eqzk4zwi5zd3.onion:9751: unsupported network

104.131.18.228 is the IP address of my seednode as is configured as follows;

unsigned int pnSeed[] =
{
      0x688312e4
};

So I'm not sure why it's attempting to connect to that IP instead.

There are no visible attempts from the coin daemon to connect to the DNS seeder on 104.131.20.192.

On the VPS 104.131.20.192, on which I'm running the dns seeder using;

./dnsseed -h seed.cryptodistributed.org -n 104.131.20.192

I get;

$ 0/1 available (1 tried in 800s, 0 new, 0 active), 0 banned; 10 DNS requests, 14 db queries

[bee7]

It hardly would connect directly as it uses standard resolver library to get all A mappings from the zone.

is it running and listening at port 53 at all? :

Code:

dig @104.131.20.192 seed.cryptodistributed.org

; <<>> DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 <<>> @104.131.20.192 seed.cryptodistributed.org
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

[12sided-dice]

I understand the clients should not connect directly to the dnsseeder, I meant that the DNS seeder is not logging attempted connections or IP addresses from coin clients.

It is running as root and listening on port 53.

[bee7]

I understand the clients should not connect directly to the dnsseeder, I meant that the DNS seeder is not logging attempted connections or IP addresses from coin clients.

It is running as root and listening on port 53.

In the post above I showed you that I could not connect. Is the port 53 open in firewall?

Anyway, what 'dig @127.0.0.1 seed.cryptodistributed.org' does report being issued locally at this host?

[12sided-dice]

On the dns seeder:
$ dig @127.0.0.1 seed.cryptodistributed.org

;<<>> DiG 9.9.5-3-Ubuntu <<>> @127.0.0.1 seed.cryptodistributed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61122
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEDUOSECTION:
; EDNS: version; 0, flags:; udp: 4096
;; QUESTION SECTION:
; seed.cryptodistributed.org.        IN        A

;; Query time: 20 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 19 20:23:31 EDT 2014
;; MSG SIZE rcvd: 55

On a client VPS:
$ dig @104.131.20.192 seed.cryptodistributed.org

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> @104.131.20.192 seed.cryptodistributed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 35619
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;seed.cryptodistributed.org.   IN   A

;; Query time: 227 msec
;; SERVER: 104.131.20.192#53(104.131.20.192)
;; WHEN: Fri Sep 19 20:38:17 EDT 2014
;; MSG SIZE  rcvd: 55

Master zone file checks:

Forward zones look good:

$ named-checkzone cryptodistributed.org /etc/bind/zones/db.cryptodistributed.org
zone autun.hom /IN: loaded serial   2
Ok

$ named-checkzone cryptodistributed.org /etc/bind/zones/db.cryptodistributed.org
zone autun.hom /IN: loaded serial   2
Ok

I think I may have found the problem, it appears  that I've made a mistake in my reverse zone file:

$ names-checkzone cryptodistributed.org /etc/bind/zones/db.104.131.55
zone cryptodistributed.org/IN: NS 'ns1.cryptodistributed.org' has no address records (A or AAAA)
zone cryptodistributed.org/IN: NS 'ns2.cryptodistributed.org' has no address records (A or AAAA)
zone cryptodistributed.org/IN: not loaded due to errors

$ named-checkzone 55.131.104.in-addr.arpa /etc/bind/zones/db.104.131.55
zone 55.131.104.in-addr.arpa/IN: loaded serial 10
OK

As I understand it, I should not need to create an A record in the reverse zone file as the PTR record fulfils this function.

/etc/bind/zones/db.104.131.55

$TTL    604800
@       IN      SOA     cryptodistributed.org. admin.cryptodistributed.org. (
                              10         ; 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.

Thoughts on where I've gone wrong?

[bee7]

On the dns seeder:
$ dig @127.0.0.1 seed.cryptodistributed.org

;<<>> DiG 9.9.5-3-Ubuntu <<>> @127.0.0.1 seed.cryptodistributed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61122
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEDUOSECTION:
; EDNS: version; 0, flags:; udp: 4096
;; QUESTION SECTION:
; seed.cryptodistributed.org.        IN        A

;; Query time: 20 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 19 20:23:31 EDT 2014
;; MSG SIZE rcvd: 55

so it returns no A records. Did you customize dnsseed to suit your coin?

[12sided-dice]

so it returns no A records. Did you customize dnsseed to suit your coin?

I'm using https://github.com/n00bsys0p/altcoin-seeder modified appropriately for my coin.

The changes are as follows;

bitcoin.cpp

Line 299
-  CService ip("litecointools.com", 9333, true);
+ CService ip("cryptodistributed.org", 9751, true);   // 9751 is the P2P Port for my Pfennig clone

combine.pl
Line 61 
- if ($addr =~ /\A(\d+)\.(\d+)\.(\d+)\.(\d+):9333/) {
+ if ($addr =~ /\A(\d+)\.(\d+)\.(\d+)\.(\d+):9751/) { 

db.h
Line 15
- #define REQUIRE_VERSION 70002
+#define REQUIRE_VERSION 70002  // Pfennig require version same as Bitcoin

Line 19
-  return testnet ? 0 : 470000;
+ return testnet ? 0 : 0;         // Set to 0 as genesis is only current checkpoint block

Line 122
-  if (clientVersion && clientVersion < 50000) { return 604800; }
+ if (clientVersion && clientVersion < 90201) { return 604800; }       // client version for Pfennig clone

main.cpp
Line 342
- static const string mainnet_seeds[] = {"dnsseed.litecointools.com", "dnsseed.litecoinpool.org", "dnsseed.ltc.xurious.com", ""};
- static const string testnet_seeds[] = {"testnet-seed.litecointools.com", ""};

+static const string mainnet_seeds[] = {"seed.cryptodistributed.org", ""};
+static const string testnet_seeds[] = {"testnet-seed.cryptodistributed.org", ""};

Line 351
-  db.Add(CService("kjy2eqzk4zwi5zd3.onion", 9333), true);
+ db.Add(CService("kjy2eqzk4zwi5zd3.onion", 9751), true); 

Line 380-383
- pchMessageStart[0] = 0xfc;
- pchMessageStart[1] = 0xc1;
- pchMessageStart[2] = 0xb7;
- pchMessageStart[3] = 0xdc;

+pchMessageStart[0] = 0x0b;
+pchMessageStart[1] = 0x11;
+pchMessageStart[2] = 0x09;
+pchMessageStart[3] = 0x07;   //testnet Pfennig magic numbers

protocol.cpp
+unsigned char pchMessageStart[4] = { 0xfb, 0xc0, 0xb6, 0xdb };
-unsigned char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };   // mainnet Pfennig Magic number

protocol.h
- return testnet ? 19333 : 9333;
+ return testnet ? 19751 : 9751;

[bee7]

Code:

telnet cryptodistributed.org 9751
Trying 104.131.53.44...
telnet: connect to address 104.131.53.44: Connection refused

Do you have a wallet running at cryptodistributed.org?

the dnsseed daemon pools the list of nodes from all nodes it could connect that are listed in bitcoin.cpp, line 299:

Code:

-  CService ip("litecointools.com", 9333, true);
+ CService ip("cryptodistributed.org", 9751, true);   // 9751 is the P2P Port for my Pfennig clone