It's important to realize that a domain name can represent either a host machine OR a sub-domain. Name-serving a sub-domain is done by delegating the job to name servers for that sub-domain. This is done by specifying name servers for sub-domain in the parent domain's zone file.
I'm not familiar with how to delegate sub-domains at GoDaddy, but I bet your issues are at least partly in this detail.
Also, you're not showing whether your seeder is in fact finding good nodes to give when it gets a request. (In this example, we see 21/223 available)
#./dnsseeder -h myseeder.mycoin.com -n 184.254.106.32 -m [email protected]
Supporting whitelisted filters: 0x1,0x5,0x9,0xd
Loading dnsseed.dat...done
Starting 4 DNS threads for myseeder.mycoin.com on 184.254.106.32 (port 53).......done
Starting seeder...done
[18-03-10 18:09:09] 21/223 available (223 tried in 277s, 0 new, 0 active), 119 banned; 0 DNS requests, 0 db queries
In general, the important points are to choose a host which will run the DNS Seeder software, and then delegate name service for a coin's sub-domain to it. For examples:
Machine Sub-Domain
--------------------------------------------------------------------
m1.platform.com hosts name service for: myseeder.mycoin.com
explorer.bitmark.io hosts name service for: biji.bitmark.one
jp.bitmark.io hosts name service for: shido.bitmark.one
In this example, we are looking at a fragment of the zone file for the domain "bitmark.one".
We are delegating name service for the "biji.bitmark.one" sub-domain to the name server at 'explorer.bitmark.io' and delegating name service for the "shido.bitmark.one" sub-domain to the name server at 'jp.bitmark.io'.
;; Thanks to: http://www.zytrax.com/books/dns/ch9/delegate.html
;; for info clarifying the concept of DNS delegation !
$ORIGIN bitmark.one.
www IN A 204.68.122.6
biji IN NS explorer.bitmark.io.
shido IN NS jp.bitmark.io.
If we use dig to find which are the name server(s) for shido.bitmark.one (query type NS) we get the IP of its name server, 139.162.122.138 :
# dig -t NS shido.bitmark.one
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t NS shido.bitmark.one
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21880
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;shido.bitmark.one. IN NS
;; ANSWER SECTION:
shido.bitmark.one. 21577 IN NS 139.162.122.138.
;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Mar 10 09:00:44 PST 2018
;; MSG SIZE rcvd: 75
and just to confirm who will answer for shido.bitmark.one, we see that the ip 139.162.122.138 is jp.bitmark.io
# ping jp.bitmark.io
PING jp.bitmark.io (139.162.122.138) 56(84) bytes of data.
64 bytes from jp.bitmark.io (139.162.122.138): icmp_seq=1 ttl=52 time=101 ms
...
When we query shido.bitmark.one, which is running the DNS Seeder software, for addresses (query type A), we get:
# dig -t A shido.bitmark.one
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t A shido.bitmark.one
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17729
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;shido.bitmark.one. IN A
;; ANSWER SECTION:
shido.bitmark.one. 59 IN A 178.238.224.213
shido.bitmark.one. 59 IN A 80.211.182.224
shido.bitmark.one. 59 IN A 76.85.169.188
shido.bitmark.one. 59 IN A 139.162.122.138
shido.bitmark.one. 59 IN A 145.239.29.193
shido.bitmark.one. 59 IN A 46.105.62.121
shido.bitmark.one. 59 IN A 139.162.128.92
shido.bitmark.one. 59 IN A 173.255.252.140
shido.bitmark.one. 59 IN A 108.61.86.198
shido.bitmark.one. 59 IN A 80.241.214.77
;; Query time: 159 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Mar 10 09:09:12 PST 2018
;; MSG SIZE rcvd: 222
Which is what we want: a list of active coin nodes in our coin's P2P network.
It's good to remember when setting up DNS Seeding that propagation of entries in the DNS system can take time - sometimes a matter of several hours or even days. So when testing and probing, you may want to substitute actual IP addresses for DNS names wherever its possible without affecting the testing, to avoid uneccessary DNS lookups that could provide false results because DNS entries have not yet propagated throughout.
