So generally it seems impossible to have both DNS seeds running on same IP
address. Too bad.
Ok, I'll switch to serving only testnet DNS on this server for now, as this
seems to be a much bigger problem than mainnet. Later I might buy second IP
to setup mainnet DNS also.
Best regards,
Alex Kotenk
On Fri, May 30, 2014 at 8:40 AM, Andreas Schildbach
wrote:
> I maybe have made this suggestion in the past, but why don't we teach
> the seeder (or maybe even plain bitcoind) how to write a zone file and
> then use matured DNS servers to serve this zone?
>
> I admit I never ran my own DNS so I'm n
On Fri, May 30, 2014 at 5:40 PM, Andreas Schildbach
wrote:
> I maybe have made this suggestion in the past, but why don't we teach
> the seeder (or maybe even plain bitcoind) how to write a zone file and
> then use matured DNS servers to serve this zone?
>
> I admit I never ran my own DNS so I'm n
A simple hack would be to crontab up a couple of dig scripts that every
minute 'dig' (dig's output is in bind zonefile format) the bitcoin-seed
and write the results to two zonefiles that bind can then serve.
Basically
dig @127.0.0.1 -p 5353 > zonefile1.zone
dig @127.0.0.1 -p 5354 > zonefile2.z
I maybe have made this suggestion in the past, but why don't we teach
the seeder (or maybe even plain bitcoind) how to write a zone file and
then use matured DNS servers to serve this zone?
I admit I never ran my own DNS so I'm not sure if that can work -- but
to me it sounds like the easiest appr
I don't think it would be too hard to add support for a option to the
seeder "for non-matching requests, forward to other DNS server at
IP:PORT", so you could cascade them.
On Fri, May 30, 2014 at 4:51 PM, Robert McKay wrote:
> No, I don't think so. The problem is the 'aa' flag is missing (see th
No, I don't think so. The problem is the 'aa' flag is missing (see the
'flags' section in dig). Perhaps if you could suppress the authority
records the recursor would give up and just accept the non-authorative
answer, but that isn't a good solution even if it might work for some
resolvers.
Ro
Hmm, you might be right, as queries
dig @node.alexykot.me testnet-seed.alexykot.me
and
dig @node.alexykot.me -p 18353 testnet-seed.alexykot.me
are giving different authority sections.
Hmm, but if I setup custom SOA record for it - it should work, right?
What SOA name should it be actually, ass
Hi Alex,
I think the problem is with my suggestion to use bind forwarding..
basically bind is stripping off the authorative answer bit in the
reply.. this causes the recursor to go into a loop chasing the authority
server which again returns a non-authoritve answer with itself as the
authority
Hi Peter
I've setup DNS seeds myself a week ago, at testnet-seed.alexykot.me and
bitcoin-seed.alexykot.me, but there is a problem with DNS settings that we
with Andreas couldn't sort out quickly.
The problem itself is that I can reach my nameserver and get dnsseed
response if I query it directly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 May 2014 02:19:39 GMT+03:00, Andreas Schildbach
wrote:
>> Hey, really sorry I don't have the time to fix this issue, been
>> travelling for a few weeks for my consulting job. If you want to
>> step up and volunteer please feel free.
>
>I'm
On 05/27/2014 12:39 AM, Peter Todd wrote:
> On 27 May 2014 01:12:05 GMT+03:00, Andreas Schildbach
> wrote:
>> You're very quick to point at others. Especially since they run
>> software that had the time to mature for about 30 years, and the
>> protocol didn't really change since then...
>
>> T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27 May 2014 01:12:05 GMT+03:00, Andreas Schildbach
wrote:
>You're very quick to point at others. Especially since they run
>software
>that had the time to mature for about 30 years, and the protocol didn't
>really change since then...
>
>The l
You're very quick to point at others. Especially since they run software
that had the time to mature for about 30 years, and the protocol didn't
really change since then...
The last time it didn't work, the bug -- non RFC-conformance -- was on
the bitcoin seeders side. ISPs do weird things with DN
On Sun, May 25, 2014 at 09:12:10PM +0200, Andreas Schildbach wrote:
> Thanks for looking at the issue.
>
> Unfortunately, it still fails for me:
>
> $ nslookup testnet-seed.bitcoin.petertodd.org
> Server: 127.0.1.1
> Address: 127.0.1.1#53
>
> ** server can't find testnet-seed.
Works fine for me
; <<>> DiG 9.8.1-P1 <<>> ANY testnet-seed.bitcoin.petertodd.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40809
;; flags: qr rd ra; QUERY: 1, ANSWER: 22, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;testnet-seed.bitcoin.pete
Thanks for looking at the issue.
Unfortunately, it still fails for me:
$ nslookup testnet-seed.bitcoin.petertodd.org
Server: 127.0.1.1
Address:127.0.1.1#53
** server can't find testnet-seed.bitcoin.petertodd.org: SERVFAIL
Like I said, can you look at the logfiles how the request
FWIW
That said, keep in mind the github discussion(1) that was had: if all
the DNS seeds being down breaks your application, your application is
broken and insecure. The only exception is initial startup, and even
then you should have fallbacks such as hardcoded node lists and manual
peer entry. I
18 matches
Mail list logo
