I'm running several bitcoin-seeders. Under Ubuntu 14.04 & 16.04, they run fine and answer queries. On Ubuntu 18.04, however, dnsseed does not detect the queries sent to it. I know the machine is receiving the query because DNS requests are monitored with dnstop, and every DNS query sent with 'dig' is sensed by dnstop and reported, but dnsseed shows "0 DNS Requests".
There is no firewall running and apparmor has been disabled. What tests could be run or troubleshooting strategy followed to find the problem ?

Under Ubuntu 16.04:

Loading dnsseed.dat...done Starting 4 DNS threads for ra.zmark.org on (port 5353).......done Starting seeder...done [18-10-24 19:27:41] 274/37963 available (1258 tried in 1000s, 38980 new, 1536
active), 0 banned; 3 DNS requests, 3 db queries

Under Ubuntu 18.04:

Supporting whitelisted filters: 0x1,0x5,0x9,0xd Loading
dnsseed.dat...done Starting 4 DNS threads for shido.bitmark.one on (port 5353).......done Starting seeder...done Starting 96 crawler threads...done [18-10-24 19:25:23] 3593/87930 available
(64497 tried in 3805s, 21897 new, 1536 active), 1 banned; 0 DNS
requests, 0 db queries


Queries: 0 new, 1363 total                                                                                                                                Wed Oct 24 19:39:03 2018
Replies: 0 new, 191 total

Query Name                     Count      %   cum%
-------------------------- --------- ------ ------
shido.bitmark.one               1169   85.8   85.8
bitseed.xf2.org                  117    8.6   94.4
org.members.linode.com            24    1.8   96.1
seed.bitcoin.sipa.be              20    1.5   97.6
dnsseed.bitcoin.dashjr.org        14    1.0   98.6
dnsseed.bluematt.me               12    0.9   99.5
motd.ubuntu.com                    5    0.4   99.9
github.com                         2    0.1  100.0
  • 1
    I'm voting to close this question as off-topic because this is about being a Linux devop, not anything specific to Bitcoin. – Anonymous Oct 25 '18 at 1:47
  • This is about bitcoin-seeder, a very specific application which is critical infrastructure to bitcoin & others altcoins. – dbkeys Oct 25 '18 at 12:12
  • It is certainly about "the open-source Bitcoin client or other Bitcoin software" as specifically listed on "What topics can I ask about here." – dbkeys Oct 25 '18 at 12:19
  • But it seems the issue is with your networking setup, not with the seeder software – Pieter Wuille Oct 27 '18 at 18:20
  • Pieter, thanks for your comment. That is my thought too, but since there is no firewall rule blocking, and 'dnstop' detects the queries, I don't know where to look for the block, which is why I'm seeking pointers or clues for a problem detection strategy ... – dbkeys Oct 28 '18 at 16:21

The problem stems from the way Ubuntu 18 handles DNS resolution.

My clue was comparing the output of netstat -an | grep "LISTEN " on a machine with a working dnsseed vs the Ubuntu 18 machine with a non-responding dnsseed

The Ubuntu 18 machine showed

 tcp        0      0 *               LISTEN  

(which the other did not). Finding this line rather odd, a search for "DNS" revealed that Ubuntu 18 is handling DNS resolution requests in a particular way (which I have not deciphered), but I found a work-around, which proves dnsseed is not at issue.

dnsseed will answer on Ubuntu 18 on non-standard DNS ports (other than port 53), so the workaround is to use iptables' network address translation feature (NAT) to intercept incoming DNS queries on port 53 and translate them to some other port (using port 5353 in this example) where dnsseed will "see" them.

    dnsseed   -h shido.bitmark.one   -n   -p 5353       -m marker@bitmark.io
    iptables -t nat -A PREROUTING -i eth0 -p tcp --dport $srcPort -j REDIRECT --to-port $dstPort
    iptables -t nat -A PREROUTING -i eth0 -p udp --dport $srcPort -j REDIRECT --to-port $dstPort

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.