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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1Y2IwO-0005Zr-3P
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Dec 2014 12:15:24 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1Y2IwM-0003QB-B1
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Dec 2014 12:15:24 +0000
Received: from laptop-air (Unknown [192.168.168.160])
by mail.taplink.co with ESMTPSA
(version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256)
; Sat, 20 Dec 2014 03:14:44 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: bitcoin-development@lists.sourceforge.net
References: <CAB2qGxXDtxWxyLUCEZ9XQ4nP0U-Cj5Xiz9ac=vot1H+wzRCHrA@mail.gmail.com>
<54953A11.1060202@bluematt.me>
<20141220100816.GD7902@giles.gnomon.org.uk>
Date: Sat, 20 Dec 2014 03:14:28 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.xq5yue2cyldrnw@laptop-air>
In-Reply-To: <20141220100816.GD7902@giles.gnomon.org.uk>
User-Agent: Opera Mail/1.0 (Win32)
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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-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
X-Headers-End: 1Y2IwM-0003QB-B1
Subject: Re: [Bitcoin-development] Area of Focus
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: Sat, 20 Dec 2014 12:15:24 -0000
On Sat, Dec 20, 2014 at 08:57:53AM +0000, Matt Corallo wrote:
>> There was recently some discussion around dnsseeds. Currently some
>> dnsseeds are getting blocked by ISPs because the hosts they pick up
>> (which run bitcoin core nodes) often run rather web servers alongside
>> which serve malware or whatever else and thus end up on IP-based malware
>> blacklists.
On Sat, 20 Dec 2014 02:08:17 -0800, Roy Badami <roy@gnomon.org.uk> wrote:
> Why would we want to have anything to do with people who are hosting
> malware? Or do I misunderstand?
It sounds like Matt is saying the nodes the dnsseed is pointing to as
valid full nodes, that those IPs are hosting the malware. Since the
dnsseed picks up any stable nodes it can find without auditing, it's
perhaps not surprising some servers in the world are running a full node
and a malware server together.
I guess what confused me about this though, how are ISPs reading the
dnsseed's node list, scanning *those* IPs for malware, and then ending up
blocking the dnsseed? Seems like a pretty winding path to end up blocking
a DNS server?
Since when do ISPs null-route a DNS server for happening to resolve some
domains to IPs which happen to also be hosting some malware? Null-route
those endpoint IPs sure, but the DNS server too? I guess there was that
incident of Microsoft taking over No-IP.com -- are dnsseeds being blocked
ostensibly because they are acting as dyanamic DNS infrastructure for
malware sites?
|
