<p>The problem stems from the way Ubuntu 18 (and above) handle DNS resolution.</p>
<p>My clue was comparing the output of <code>netstat -an | grep &quot;LISTEN &quot;</code> on a machine with a working <em>dnsseed</em> vs the Ubuntu 18 machine with a non-responding <em>dnsseed</em></p>
<p>The Ubuntu 18 machine showed</p>
<pre><code> tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN  
</code></pre>
<p>(which the other did not). Finding this line rather odd, a search for &quot;DNS 127.0.0.53:53&quot; 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 <em>dnsseed</em> is not at issue.</p>
<p><em>dnsseed</em> 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 <em>dnsseed</em> will &quot;see&quot; them.</p>
<pre><code>    dnsseed   -h shido.bitmark.one   -n 139.162.122.138   -p 5353       -m marker@bitmark.io
    srcPort=53
    dstPort=5353
    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
</code></pre>

CC BY-SA 4.0
2018-11-05T18:13:30.983Z
2023-05-08T17:42:48.073Z
2023-05-08T17:42:48.073Z
dbkeys
<p>I'm running several <a href="https://github.com/sipa/bitcoin-seeder" rel="nofollow noreferrer">bitcoin-seeders</a>. Under Ubuntu 14.04 &amp; 16.04, they run fine and answer queries. 
On Ubuntu 18.04, however, <em>dnsseed</em> does not detect the queries sent to it.  I know the machine is receiving the query because DNS requests are monitored with <a href="http://dns.measurement-factory.com/tools/dnstop/" rel="nofollow noreferrer">dnstop</a>, and every DNS query sent with '<em>dig</em>' is sensed by dnstop and reported, but <em>dnsseed</em> shows "0 DNS Requests".<br>
There is no firewall running and apparmor has been disabled. What tests could be run or troubleshooting strategy followed to find the problem ?</p>

<p><strong>Under Ubuntu 16.04:</strong></p>

<pre><code>Loading dnsseed.dat...done Starting 4 DNS threads for ra.zmark.org on
173.255.252.140 (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
</code></pre>

<p><strong>Under Ubuntu 18.04:</strong></p>

<pre><code>Supporting whitelisted filters: 0x1,0x5,0x9,0xd Loading
dnsseed.dat...done Starting 4 DNS threads for shido.bitmark.one on
139.162.122.138 (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
</code></pre>

<p>dnstop:</p>

<pre><code>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
</code></pre>

CC BY-SA 4.0
2018-10-25T01:47:46.927Z
I'm voting to close this question as off-topic because this is about being a Linux devop, not anything specific to Bitcoin.
Claris
CC BY-SA 4.0
2018-10-25T12:12:37.873Z
This is about bitcoin-seeder, a very specific application which is critical infrastructure to  bitcoin & others altcoins.
dbkeys
CC BY-SA 4.0
2018-10-25T12:19:27.220Z
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
CC BY-SA 4.0
2018-10-27T18:20:06.097Z
But it seems the issue is with your networking setup, not with the seeder software
Pieter Wuille
CC BY-SA 4.0
2018-10-28T16:21:46.123Z
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
<seed><dns>
What could stop bitcoin-seeder from "hearing" DNS queries?
dbkeys
# What could stop bitcoin-seeder from "hearing" DNS queries?

(Asked by: username_0 on 2018-10-24)

I'm running several [bitcoin-seeders](https://github.com/sipa/bitcoin-seeder). 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](http://dns.measurement-factory.com/tools/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
173.255.252.140 (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
139.162.122.138 (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

```

dnstop:

```
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

```

**Tags:** seed, dns

> **Comments:**
> **username_1**: I'm voting to close this question as off-topic because this is about being a Linux devop, not anything specific to Bitcoin.  
> **username_0**: This is about bitcoin-seeder, a very specific application which is critical infrastructure to  bitcoin & others altcoins.  
> **username_0**: It is certainly about "the open-source Bitcoin client or other Bitcoin software" as specifically listed on "What topics can I ask about here."  
> **username_2**: But it seems the issue is with your networking setup, not with the seeder software  
> **username_0**: username_2, 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 ...  

---

## 1 answers

### Answer by username_0 on 2018-11-05. Score: 2

The problem stems from the way Ubuntu 18 (and above) handle 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 127.0.0.53:53           0.0.0.0:*               LISTEN  

```

(which the other did not). Finding this line rather odd, a search for "DNS 127.0.0.53:53" 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 139.162.122.138   -p 5353       -m marker@bitmark.io
    srcPort=53
    dstPort=5353
    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

```


---

