1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1X9E37-0001Iv-A2
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Jul 2014 13:54:41 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.46 as permitted sender)
client-ip=209.85.219.46;
envelope-from=decker.christian@gmail.com;
helo=mail-oa0-f46.google.com;
Received: from mail-oa0-f46.google.com ([209.85.219.46])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X9E36-000220-BV
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Jul 2014 13:54:41 +0000
Received: by mail-oa0-f46.google.com with SMTP id m1so7414650oag.33
for <bitcoin-development@lists.sourceforge.net>;
Mon, 21 Jul 2014 06:54:32 -0700 (PDT)
X-Received: by 10.60.52.5 with SMTP id p5mr37360217oeo.55.1405950871879; Mon,
21 Jul 2014 06:54:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.3.161 with HTTP; Mon, 21 Jul 2014 06:53:51 -0700 (PDT)
In-Reply-To: <CA+s+GJA1aLqOamoYTHRNsF3bGb=pKwNHXGYzQ6GSTgQnic+yCA@mail.gmail.com>
References: <CA+s+GJA1aLqOamoYTHRNsF3bGb=pKwNHXGYzQ6GSTgQnic+yCA@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Mon, 21 Jul 2014 14:53:51 +0100
Message-ID: <CALxbBHW1kf6gDoO22GETwb6kRJ92qxS6MSNx64+kT2TiwH5iTQ@mail.gmail.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(decker.christian[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
information
X-Headers-End: 1X9E36-000220-BV
Cc: kevin <bit.kevin@gmail.com>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Policy for DNS seeds
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 13:54:41 -0000
How about research projects into node distribution? Specifically I
wonder whether the collection and analysis of DNS query origin is
allowed when queries are anonymized and aggregated. This would prevent
the identification of a single user, which I assume is the rationale
for point 4.
Other than that I'm perfectly fine with accepting the rules for
seed.bitcoinstats.com
Regards,
Christian
--
Christian Decker
On Mon, Jul 21, 2014 at 2:43 PM, Wladimir <laanwj@gmail.com> wrote:
> We've established a few basic rules for the DNS seeds as used in the
> Bitcoin Core software. See below.
>
> If you run one of the DNS seeds please reply to this and let us know
> whether you agree to these terms. if you think some requirements are
> unreasonable let us know too. If we haven't heard from you by
> 2014-08-04 we will remove your DNS seed from the list of defaults.
>
> Expectations for DNSSeed operators
> ====================================
>
> Bitcoin Core attempts to minimize the level of trust in DNS seeds,
> but DNS seeds still pose a small amount of risk for the network.
> Other implementations of Bitcoin software may also use the same
> seeds and may be more exposed. In light of this exposure this
> document establishes some basic expectations for the expectations
> for the operation of dnsseeds.
>
> 0. A DNSseed operating organization or person is expected
> to follow good host security practices and maintain control of
> their serving infrastructure and not sell or transfer control of their
> infrastructure. Any hosting services contracted by the operator are
> equally expected to uphold these expectations.
>
> 1. The DNSseed results must consist exclusively of fairly selected and
> functioning Bitcoin nodes from the public network to the best of the
> operators understanding and capability.
>
> 2. For the avoidance of doubt, the results may be randomized but must not
> single-out any group of hosts to receive different results unless due to an
> urgent technical necessity and disclosed.
>
> 3. The results may not be served with a DNS TTL of less than one minute.
>
> 4. Any logging of DNS queries should be only that which is necessary
> for the operation of the service or urgent health of the Bitcoin
> network and must not be retained longer than necessary or disclosed
> to any third party.
>
> 5. Information gathered as a result of the operators node-spidering
> (not from DNS queries) may be freely published or retained, but only
> if this data was not made more complete by biasing node connectivity
> (a violation of expectation (1)).
>
> 6. Operators are encouraged, but not required, to publicly document
> the details of their operating practices.
>
> 7. A reachable email contact address must be published for inquiries
> related to the DNSseed operation.
>
> If these expectations cannot be satisfied the operator should
> discontinue providing services and contact the active Bitcoin
> Core development team as well as posting on bitcoin-development.
>
> Behavior outside of these expectations may be reasonable in some
> situations but should be discussed in public in advance.
>
> ========
>
> See
> https://github.com/bitcoin/bitcoin/pull/4566
>
> Wladimir
|
