dns seeds and SERVFAIL

[GoogleCodeExporter]

I'm aware that this might not be the best place to report this, but still I 
think its important enough to track it and perhaps there will be action points 
in bitcoinj.

A couple of DNS seeds do not answer. Specifically:

mainnet:
 seed.bitcoin.sipa.be - SERVFAIL
 dnsseed.bluematt.me - OK
 dnsseed.bitcoin.dashjr.org - SERVFAIL

testnet:
 testnet-seed.bitcoin.petertodd.org - SERVFAIL
 testnet-seed.bluematt.me - OK, but resolved to only one node

At least the sipa and petertodd seeds use sipas custom code. If you dig the 
server directly, it works as expected. Also, the problem seems to depend on the 
network your connected to or the dns server of that network.

If Matt shuts down his node or gets blocked, Bitcoin will cease to work for me. 
Not a pretty sight )-:

Original issue reported on code.google.com by andreas....@gmail.com on 14 Jul 2013 at 2:37

[GoogleCodeExporter]

Oh dear. They're still hosed. It looks like something may have simultaneously 
nuked any seed that runs sipas software. Thank god we have Matt Corallos 
implementation (bitcoinj based, I think).

The fact that this can happen definitely bumps up the priority of real addr 
handling, though the DNS seeds are still vital for on-boarding new users.

Original comment by hearn@google.com on 15 Jul 2013 at 8:46

[GoogleCodeExporter]

On IRC there was the idea that my dsl providers DNS server uses TCP to make its 
queries while dns-seeder does not support TCP yet. I'm planning to verify this 
idea.

Original comment by andreas....@gmail.com on 15 Jul 2013 at 8:54

[GoogleCodeExporter]

No. They're just down. I can't reach sipas DNS seed from Google either. Most 
likely there was some kind of simultaneous segfault or scaling issue reached in 
the code. We'll need to wait for Pieter to come online to find out what's going 
on.

Original comment by hearn@google.com on 15 Jul 2013 at 9:04

[GoogleCodeExporter]

BTW 

"dig +notcp +trace seed.bitcoin.sipa.be" also dies. I don't see any reason to 
believe it's TCP vs UDP related. Does it work for some people then?

Original comment by hearn@google.com on 15 Jul 2013 at 9:08

[GoogleCodeExporter]

OK, it's just sipas seed that's down. dnsseed.bitcoin.dashjr.org works for me. 
So maybe there are actually two unrelated issues going on in parallel? 
Confusing.

Original comment by hearn@google.com on 15 Jul 2013 at 9:13

[GoogleCodeExporter]

Just tried the following: Installed bind9 on a server with fixed IP and made it 
log all queries. Then added a blaa.schildbach.de NS entry to my providers dns. 
Now when I do "dig aaa.blaa.schildbach.de" I get the following very strange 
camelcasing in the log.

Jul 15 11:38:43 archon named[26118]: client 213.191.74.12#22546: query: 
aaaa.bLaA.sCHIldbACh.de IN A - (78.46.152.204)
Jul 15 11:38:43 archon named[26118]: client 213.191.74.12#22546: query (cache) 
'aaaa.bLaA.sCHIldbACh.de/A/IN' denied

When digging my server directly everything is lowercase as expected.

Note that the denied error is because I did not actually set up a zone.

Original comment by andreas....@gmail.com on 15 Jul 2013 at 9:42

[GoogleCodeExporter]

Note that my ISP does _not_ try to use TCP (would make a +T appear in the log).

Original comment by andreas....@gmail.com on 15 Jul 2013 at 9:44

[GoogleCodeExporter]

My DNS seed should be up again. This was an unrelated issue.

The upper/lowercase gibberish may explain something. Perhaps they're using this 
to add extra entropy to the query to guarantee a fresh result.

I'll check whether my seeder does case-insensitive matching.

Original comment by piet...@google.com on 15 Jul 2013 at 9:50

[GoogleCodeExporter]

dig @jun.dashjr.org dnsSeed.bitCoin.dasHjr.org fails
dig @jun.dashjr.org dnsseed.bitcoin.dashjr.org succeeds

Guess that proves there's a bug in sipa's code.

Original comment by andreas....@gmail.com on 15 Jul 2013 at 9:57

[GoogleCodeExporter]

Right. DNS is supposed to be case insensitive. I've never encountered this 
random re-casing of queries before. I think Pieter's guess is a good one, this 
has to be deliberate and must be some kind of cache-busting trick. Very odd.

OK, great, we got to the bottom of this - gonna close this as it's not a 
bitcoinj issue.

Original comment by hearn@google.com on 15 Jul 2013 at 10:04

• Changed state: Fixed