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 ) id 1X9JC3-0001dh-NS for bitcoin-development@lists.sourceforge.net; Mon, 21 Jul 2014 19:24:15 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.84 as permitted sender) client-ip=62.13.149.84; envelope-from=pete@petertodd.org; helo=outmail149084.authsmtp.net; Received: from outmail149084.authsmtp.net ([62.13.149.84]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1X9JC2-0005Rt-It for bitcoin-development@lists.sourceforge.net; Mon, 21 Jul 2014 19:24:15 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s6LJO6eg083570; Mon, 21 Jul 2014 20:24:06 +0100 (BST) Received: from petertodd.org (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s6LJNxP5010294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 21 Jul 2014 20:24:02 +0100 (BST) Date: Mon, 21 Jul 2014 15:24:01 -0400 From: Peter Todd To: Wladimir Message-ID: <20140721192401.GA16764@petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 931789f5-110c-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bwdMdAMUEkAYAgsB AmIbWVReUll7WWA7 bAxPbAVDY01GQQRq WVdMSlVNFUsrB2B7 eFZ+VxlzdwdPfDBy bERqXj5SX0V9fU8r R1NVFG1VeGZhPWQC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4zGTo9 TAFKEzI1VWEjfG0o IhEqMTYB X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1X9JC2-0005Rt-It Cc: kevin , Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:24:15 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2014 at 03:43:42PM +0200, Wladimir wrote: > We've established a few basic rules for the DNS seeds as used in the > Bitcoin Core software. See below. >=20 > 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. >=20 > Expectations for DNSSeed operators > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 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. Might be worthwhile to also write an "Expectations for DNSSeed users" outlining what security properties the seeds actually have, and what kind of attacks are possible. Many users would be better served with seeds that offer authenticated and encrypted connections to the seeds for instance. (esp. if they're using authed/encrypted connections to nodes, e.g. Tor hidden services) > 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. Along the lines of my above point, for Bitcoin Core users of the DNSSeeds what constitutes a "functioning" Bitcoin node is much more broad than what other users might need. > 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. Note that singling out a group of hosts to receive different results with DNS is especially difficult as you'll be usually singling out different ISP's rather than hosts themselves. That said if we ever start operating HTTPS or similar seeds this expectation will become even more relevant for them. > 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. >=20 > Behavior outside of these expectations may be reasonable in some > situations but should be discussed in public in advance. I'll let others refine the exact wording. but I broadly agree with these rules. For the testnet DNS seeds - IE my one - my thoughts are the rules should be identical. Most of the above is related to privacy rather than security, which apply equally well on testnet. While there have been suggestions to use the testnet seeds for testing vulnerabilities, the public discussion clause should suffice to allow those exceptions. I also suspect that vulnerabilities are likely to be dismissed by a large part of the community if demonstrated with DNSSeed operator co-operation. --=20 'peter'[:-1]@petertodd.org 00000000000000003dcfcd420fbf9e5b6bdab43ac772960351475dec125382ef --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJTzWjNXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAyMjk5OTE1MjlmMDc5YjYzYjk0MTc1MWE4ZWFlZTAzNWY0 ODc4YzlhYTY1ZTVmNDIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsp6wgAvYPVuOXLlWSCcrBoJAv0xeFf e78zi+EDb+ebsoJmtqRN58gFmTFHchgQKUAsfCt9vSZim3ir0EVEOvmT99wDAZkn sXRgrdRZkvTXfH2U6HP4E1i+YvWfE8c2tKB3lk96ItsaD/h78lVXB41HRGxN0rLy 0BbV4JF4NVSnAV9l6wHQjMpYYHVsRf4UNNpvEpnip5sa+uE2EWHkZgdIiqw1x5ti JAOK2Y+UXm2F92J0saU1pL3gFE0uvMWiSNoErvDptgMEEFYUjmOwmTnynhLxeXwq GEpkDIqYLcEEZLT2gilUR255XzPdkWu3xAz/0nX2ti0EPl0tDbeYim/XrhYyRw== =bZ4G -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g--