path: root/06/92107f2c9363badcccc52f08da9ee3d96388d2

Return-Path: <ric@spagni.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F35CFB1D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 14 Jul 2015 19:07:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vn0-f52.google.com (mail-vn0-f52.google.com
	[209.85.216.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 80548163
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 14 Jul 2015 19:07:49 +0000 (UTC)
Received: by vnbf62 with SMTP id f62so2103847vnb.8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 14 Jul 2015 12:07:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to
	:content-type;
	bh=juaqOMKMJRSX7E03QHaTWFoSiH79mxiJJGl7Wps3H1c=;
	b=iL61P91/agO76CWVf/2MwSgiiztjC+DsSfVDZdh/KF1My+0RpBOLq52GYnWxfSwLOn
	W20udJJpBtN4pH4FLAFtrjq9fCYdCnwejqtxm64+zoNHE60pN6defm9HRborpt4PPFMH
	gAFBZnSa9PUZ5flCuRxEOhky7IkTyoAa5juzsnlhph4CE7mnvzpirUnzQwFrTCYUftXl
	3VkGGmemeveF/C4gpe4DTC2CZy9KZmTV0lseXx7/d6/cyMtQGI8luktFYE5KOnw59Iqx
	8ZLjzojuA/aKs61/LOIPQEIEPN0v4knNEFte1vFP9SdAVHYtUweR7cK2EWHT+CNtliXs
	z8+A==
X-Gm-Message-State: ALoCoQnUFomhT0rY+rw89LsVjY3sYG2Nx5EPmUz4U1MAckMEUBHYLujcb7CZ48NfWj5q4jfKj9l9
X-Received: by 10.52.2.193 with SMTP id 1mr172012vdw.44.1436900868403; Tue, 14
	Jul 2015 12:07:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.92.197 with HTTP; Tue, 14 Jul 2015 12:07:28 -0700 (PDT)
From: Riccardo Spagni <ric@spagni.net>
Date: Tue, 14 Jul 2015 21:07:28 +0200
Message-ID: <CADhj2oT_rgaf6LFgwMawwJKaA8384v5jQ=e-7T8GNY4gGZ2udQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=485b397dd1e5d6cc79051ada8db7
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2015 19:07:52 -0000

--485b397dd1e5d6cc79051ada8db7
Content-Type: text/plain; charset=UTF-8

> To break it down briefly, we have an open lookup standard based on
> both the namecoin blockchain as well as traditional DNSSEC.  (You can
> choose your own adventure of using namecoin based names or traditional
> ICANN names).


Good, that's roughly analogous with what OpenAlias defines.

We DO provide a service where we will register or host
> names on your behalf. However if you follow the format and host them
> yourself, everything will work just fine, and our open source lookup
> server and libraries will provide those results exactly the same as if
> the names were hosted with us.


Also good, much the same as https://cryptoname.co and https://xmr.link


> To that end, we have had conversations
> with several companies in the space who intend to host their own
> names, and we intend to work with them on the effort to ensure our
> documentation is sufficient to ensure they can successfully do so.
>
> In terms of comparisons to OpenAlias, I think there are a lot of
> similarities, but a few differences.  First the similarities:
>
>
> 1> We both use DNSSEC.
>
> 2> We both have the option of storing the address directly in the DNS
> record.
>
>
> Differences:
>
> 1> We do not use DNSCrypt.  I understand why you chose to, but we were
> concerned about broad interoperability and easy broad distribution of
> hosting, so decided not to use it.  We have other ways of achieving
> privacy, using HD Wallets and Payment Requests.
>

And this is the part where you guys look really, really incompetent (and I
don't mean that in a terribly demeaning way, it's just that you're in a
space where you want to be a domain expert, not make a series of
embarrassing and public faux pas).

DNSCrypt requires NO work on the part of the alias creator, DNS server,
SOA, or anything else. It is entirely client side, and allows for *private
lookups*. HD Wallets and Payment Requests are inconsequential, an ISP still
knows every DNS resolution their users are performing.

When using dnscrypt-proxy to perform private lookups they are done against
the 55 free and public DNSCrypt resolvers [1], provided by oVPN, OpenNIC,
OpenDNS, okTurtles, CloudNS, and various individuals. OpenAlias links to
and recommends four of these specifically, as they have the unique
combination of providing Namecoin lookups, supporting DNSSEC validation for
lightweight verification, and claiming not to store logs.

Therefore, DNSCrypt provides encrypted, private, secure, end-user lookups
with no implication on the creation side. That you are unaware of this
(when presumably you at least read the Wikipedia article on the topic) and
are not embracing it is quite surprising, to say the least.


> 2> We have the option of storing a URL rather than just a wallet
> address in the TXT record.  This allows a second level lookup against
> the URL to get back a unique HD Wallet address or Payment Request each
> time, further protecting user privacy and security.  Using Wallet
> Names with Payment Requests allows for the user experience of typing
> in an easy to remember name and getting back the "green lock" and who
> the validated recipient is.  This also provides an auto audit of the
> end to end DNS SEC process, in the case the path were somehow
> compromised, the signature on the payment request can provide an
> additional check.
>

OpenAlias supports this as well, except it does it better by allowing the
KV pairs to also contain a TLSA record before the request, which
effectively makes it a DANE-secured interaction. Your interaction requires
the trusting of multiple CAs, which is an inherent weakness.

3> We use a 2 tier lookup format.  The first lookup returns a list of
> currencies or payment types supported by the Wallet Name.  The second
> lookup goes to a record specific to that currency type to get the
> address to go to.  We believe this to be a more scalable solution in a
> world where someone can have both multiple digital currency types, but
> then also multiple types of colored coins, and wants a simple way to
> share a single name for all of those different addresses.  This allows
> the wallet to do the work behind the scene of choosing the currency it
> wants to send, and automatically getting back the right address to
> send to, without the user having to do anything different.
>

We do the same thing, except in a single call. Here's an example of a
record that has both XMR and BTC addresses:
https://api.openalias.org/donate.getmonero.org?view=full (here are the DNS
records for that:
http://mxtoolbox.com/SuperTool.aspx?action=txt%3adonate.getmonero.org&run=toolpage
)


> 4> We mandate DNSSEC while you make it optional.  We did this because
> we believe giving the user the option of NOT using DNSSEC is like
> letting them order a car with no brakes.  We weren't sure how we would
> explain to them why their money was gone when they really didn't
> understand the risks they were taking up front. We had a lot of
> discussion about it before coming to the decision we did, and I can
> see why you went the other way, although I do believe we made the
> right choice.
>

With OpenAlias a DNSSEC fail is a soft fail, and the user has to confirm
the address. The reasons are threefold:

1. At the moment only 83.5% of the TLDs are signed [2]. The unsigned ones
include some biggies like .sg, .za, and .to

2. Even if the zone *is* signed, DNSSEC deployment is hard. Unmanaged
DNSSEC deployment is out of scope for probably 99.9% of users, even the
usually-technically-ok Bitcoin crowd. Managed DNSSEC is available, but is
quite pricey. UltraDNS, Dyn, and GoDaddy (ikr?) are the three big
providers, and of those three only GoDaddy has a consumer-affordable
product.

3. ThomasV and I have done a stack of testing behind residential and
commercial routers where DNSSEC simply fails (eg. the router runs a really
outdated DNS server that doesn't provide RRSIGs in its response, or the ISP
doesn't care about DNSSEC). Unsurprisingly, this can be fixed by...you
guessed it...doing the lookup via DNSCrypt.

Until we are closer to the bulk of all TLDs being signed, and DNSSEC
becomes at least a little more ubiquitous, we can't lock out huge portions
of the Internet, because then we're not really providing a useful and
usable solution. All we can is make it more difficult to pay an unverified
domain.

Of course, if your aim is to force people to use you as a domain registrar,
then it makes total sense why you'd lock people out;)

Additionally, we just released another open source API server to help
> with the "other half" of the lookup problem.  Its in its infancy, and
> we are certainly taking feedback on it at this time.  It is called
> Addressimo <https://github.com/netkicorp/addressimo> and will serve
> unique HD Wallet addresses or Payment Requests for every lookup, thus
> allowing a user to have a private, secure way to share a Wallet Name
> that can be used to send them any digital currency.
>

Oh snap...https://github.com/openalias/openalias-api


> I'd love to talk here or offline about merging standards going
> forward.  As an FYI, Verisign has also delivered a standard to the
> IETF using DNSSEC to pass payment information here:
> https://tools.ietf.org/html/draft-wiley-paymentassoc-00  We have
> started discussions with them about merging standards as well.
>
>
> They actually have a really nice way in their standard to encode email
> addresses that more or less ensures that there won't be name space
> collision in the case that there is already a record "joe.user.com"
> and you want to create one for "joe@user.com" that we are looking at
> adding to what we are doing in the next update to our record formats.
>

OpenAlias (and your system) doesn't really have to worry about that, as TXT
records can live side-by-side with A / CNAME / MX etc. records. More
importantly, OpenAlias especially doesn't have to worry about it, because
OpenAlias TXT records have a prefix: "oa1:" for OpenAlias v1 records. The
risk of there being a legitimate TXT record that starts with oa1: and
*isn't* an OpenAlias record is, well, pretty negligible.

In any case, I'd much rather we had one effort going forward than
> multiples, so let's talk!
>

I agree, and you guys are in an ideal position to change to supporting the
OpenAlias standard (and enhancing it) without skipping a beat. We would
definitely appreciate and take your input and efforts, and that would make
OpenAlias v2 (oa2:) a standard built out in conjunction with Netki.

Not only do you get Electrum support without lifting a finger, but it will
go a long way to repairing your relationship with the open-source community
at large, several proponents of which have taken great umbrage at what you
were previously pushing as a closed-source, centralised system.

Riccardo

Footnotes:

[1] -
https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv
[2] - http://stats.research.icann.org/dns/tld_report/

--485b397dd1e5d6cc79051ada8db7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
To break it down briefly, we have an open lookup standard based on<br>
both the namecoin blockchain as well as traditional DNSSEC.=C2=A0 (You can<=
br>
choose your own adventure of using namecoin based names or traditional<br>
ICANN names).=C2=A0</blockquote><div>=C2=A0</div><div>Good, that&#39;s roug=
hly analogous with what OpenAlias defines.</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"> We DO provide a service where we will register or host<br>
names on your behalf. However if you follow the format and host them<br>
yourself, everything will work just fine, and our open source lookup<br>
server and libraries will provide those results exactly the same as if<br>
the names were hosted with us.=C2=A0 </blockquote><div><br></div><div>Also =
good, much the same as=C2=A0<a href=3D"https://cryptoname.co">https://crypt=
oname.co</a> and=C2=A0<a href=3D"https://xmr.link">https://xmr.link</a></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">To that end, we have had conversations<=
br>
with several companies in the space who intend to host their own<br>
names, and we intend to work with them on the effort to ensure our<br>
documentation is sufficient to ensure they can successfully do so.<br>
<br>
In terms of comparisons to OpenAlias, I think there are a lot of<br>
similarities, but a few differences.=C2=A0 First the similarities:<br>
<br>
<br>
1&gt; We both use DNSSEC.<br>
<br>
2&gt; We both have the option of storing the address directly in the DNS re=
cord.<br>
<br>
<br>
Differences:<br>
<br>
1&gt; We do not use DNSCrypt.=C2=A0 I understand why you chose to, but we w=
ere<br>
concerned about broad interoperability and easy broad distribution of<br>
hosting, so decided not to use it.=C2=A0 We have other ways of achieving<br=
>
privacy, using HD Wallets and Payment Requests.<br></blockquote><div><br></=
div><div>And this is the part where you guys look really, really incompeten=
t (and I don&#39;t mean that in a terribly demeaning way, it&#39;s just tha=
t you&#39;re in a space where you want to be a domain expert, not make a se=
ries of embarrassing and public faux pas).</div><div><br></div><div>DNSCryp=
t requires NO work on the part of the alias creator, DNS server, SOA, or an=
ything else. It is entirely client side, and allows for *private lookups*. =
HD Wallets and Payment Requests are inconsequential, an ISP still knows eve=
ry DNS resolution their users are performing.</div><div><br></div><div>When=
 using dnscrypt-proxy to perform private lookups they are done against the =
55 free and public DNSCrypt resolvers [1], provided by oVPN, OpenNIC, OpenD=
NS, okTurtles, CloudNS, and various individuals. OpenAlias links to and rec=
ommends four of these specifically, as they have the unique combination of =
providing Namecoin lookups, supporting DNSSEC validation for lightweight ve=
rification, and claiming not to store logs.</div><div><br></div><div>Theref=
ore, DNSCrypt provides encrypted, private, secure, end-user lookups with no=
 implication on the creation side. That you are unaware of this (when presu=
mably you at least read the Wikipedia article on the topic) and are not emb=
racing it is quite surprising, to say the least.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
2&gt; We have the option of storing a URL rather than just a wallet<br>
address in the TXT record.=C2=A0 This allows a second level lookup against<=
br>
the URL to get back a unique HD Wallet address or Payment Request each<br>
time, further protecting user privacy and security.=C2=A0 Using Wallet<br>
Names with Payment Requests allows for the user experience of typing<br>
in an easy to remember name and getting back the &quot;green lock&quot; and=
 who<br>
the validated recipient is.=C2=A0 This also provides an auto audit of the<b=
r>
end to end DNS SEC process, in the case the path were somehow<br>
compromised, the signature on the payment request can provide an<br>
additional check.<br></blockquote><div><br></div><div>OpenAlias supports th=
is as well, except it does it better by allowing the KV pairs to also conta=
in a TLSA record before the request, which effectively makes it a DANE-secu=
red interaction. Your interaction requires the trusting of multiple CAs, wh=
ich is an inherent weakness.</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3&gt; We use a 2 tier lookup format.=C2=A0 The first lookup returns a list =
of<br>
currencies or payment types supported by the Wallet Name.=C2=A0 The second<=
br>
lookup goes to a record specific to that currency type to get the<br>
address to go to.=C2=A0 We believe this to be a more scalable solution in a=
<br>
world where someone can have both multiple digital currency types, but<br>
then also multiple types of colored coins, and wants a simple way to<br>
share a single name for all of those different addresses.=C2=A0 This allows=
<br>
the wallet to do the work behind the scene of choosing the currency it<br>
wants to send, and automatically getting back the right address to<br>
send to, without the user having to do anything different.<br></blockquote>=
<div><br></div><div>We do the same thing, except in a single call. Here&#39=
;s an example of a record that has both XMR and BTC addresses:=C2=A0<a href=
=3D"https://api.openalias.org/donate.getmonero.org?view=3Dfull">https://api=
.openalias.org/donate.getmonero.org?view=3Dfull</a> (here are the DNS recor=
ds for that:=C2=A0<a href=3D"http://mxtoolbox.com/SuperTool.aspx?action=3Dt=
xt%3adonate.getmonero.org&amp;run=3Dtoolpage">http://mxtoolbox.com/SuperToo=
l.aspx?action=3Dtxt%3adonate.getmonero.org&amp;run=3Dtoolpage</a>)</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
4&gt; We mandate DNSSEC while you make it optional.=C2=A0 We did this becau=
se<br>
we believe giving the user the option of NOT using DNSSEC is like<br>
letting them order a car with no brakes.=C2=A0 We weren&#39;t sure how we w=
ould<br>
explain to them why their money was gone when they really didn&#39;t<br>
understand the risks they were taking up front. We had a lot of<br>
discussion about it before coming to the decision we did, and I can<br>
see why you went the other way, although I do believe we made the<br>
right choice.<br></blockquote><div><br></div><div>With OpenAlias a DNSSEC f=
ail is a soft fail, and the user has to confirm the address. The reasons ar=
e threefold:</div><div><br></div><div>1. At the moment only 83.5% of the TL=
Ds are signed [2]. The unsigned ones include some biggies like .sg, .za, an=
d .to</div><div><br></div><div>2. Even if the zone *is* signed, DNSSEC depl=
oyment is hard. Unmanaged DNSSEC deployment is out of scope for probably 99=
.9% of users, even the usually-technically-ok Bitcoin crowd. Managed DNSSEC=
 is available, but is quite pricey. UltraDNS, Dyn, and GoDaddy (ikr?) are t=
he three big providers, and of those three only GoDaddy has a consumer-affo=
rdable product.</div><div><br></div><div>3. ThomasV and I have done a stack=
 of testing behind residential and commercial routers where DNSSEC simply f=
ails (eg. the router runs a really outdated DNS server that doesn&#39;t pro=
vide RRSIGs in its response, or the ISP doesn&#39;t care about DNSSEC). Uns=
urprisingly, this can be fixed by...you guessed it...doing the lookup via D=
NSCrypt.</div><div><br></div><div>Until we are closer to the bulk of all TL=
Ds being signed, and DNSSEC becomes at least a little more ubiquitous, we c=
an&#39;t lock out huge portions of the Internet, because then we&#39;re not=
 really providing a useful and usable solution. All we can is make it more =
difficult to pay an unverified domain.</div><div><br></div><div>Of course, =
if your aim is to force people to use you as a domain registrar, then it ma=
kes total sense why you&#39;d lock people out;)</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex">
Additionally, we just released another open source API server to help<br>
with the &quot;other half&quot; of the lookup problem.=C2=A0 Its in its inf=
ancy, and<br>
we are certainly taking feedback on it at this time.=C2=A0 It is called<br>
Addressimo &lt;<a href=3D"https://github.com/netkicorp/addressimo" rel=3D"n=
oreferrer" target=3D"_blank">https://github.com/netkicorp/addressimo</a>&gt=
; and will serve<br>
unique HD Wallet addresses or Payment Requests for every lookup, thus<br>
allowing a user to have a private, secure way to share a Wallet Name<br>
that can be used to send them any digital currency.<br></blockquote><div><b=
r></div><div>Oh snap...<a href=3D"https://github.com/openalias/openalias-ap=
i">https://github.com/openalias/openalias-api</a><br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex">
I&#39;d love to talk here or offline about merging standards going<br>
forward.=C2=A0 As an FYI, Verisign has also delivered a standard to the<br>
IETF using DNSSEC to pass payment information here:<br>
<a href=3D"https://tools.ietf.org/html/draft-wiley-paymentassoc-00" rel=3D"=
noreferrer" target=3D"_blank">https://tools.ietf.org/html/draft-wiley-payme=
ntassoc-00</a>=C2=A0 We have<br>
started discussions with them about merging standards as well.<br>
<br>
<br>
They actually have a really nice way in their standard to encode email<br>
addresses that more or less ensures that there won&#39;t be name space<br>
collision in the case that there is already a record &quot;<a href=3D"http:=
//joe.user.com" rel=3D"noreferrer" target=3D"_blank">joe.user.com</a>&quot;=
<br>
and you want to create one for &quot;<a href=3D"mailto:joe@user.com">joe@us=
er.com</a>&quot; that we are looking at<br>
adding to what we are doing in the next update to our record formats.<br></=
blockquote><div><br></div><div>OpenAlias (and your system) doesn&#39;t real=
ly have to worry about that, as TXT records can live side-by-side with A / =
CNAME / MX etc. records. More importantly, OpenAlias especially doesn&#39;t=
 have to worry about it, because OpenAlias TXT records have a prefix: &quot=
;oa1:&quot; for OpenAlias v1 records. The risk of there being a legitimate =
TXT record that starts with oa1: and *isn&#39;t* an OpenAlias record is, we=
ll, pretty negligible.</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In any case, I&=
#39;d much rather we had one effort going forward than<br>
multiples, so let&#39;s talk!<br></blockquote><div><br></div><div>I agree, =
and you guys are in an ideal position to change to supporting the OpenAlias=
 standard (and enhancing it) without skipping a beat. We would definitely a=
ppreciate and take your input and efforts, and that would make OpenAlias v2=
 (oa2:) a standard built out in conjunction with Netki.</div><div><br></div=
><div>Not only do you get Electrum support without lifting a finger, but it=
 will go a long way to repairing your relationship with the open-source com=
munity at large, several proponents of which have taken great umbrage at wh=
at you were previously pushing as a closed-source, centralised system.</div=
><div><br></div><div>Riccardo</div><div><br></div><div>Footnotes:</div><div=
><br></div><div>[1] -=C2=A0<a href=3D"https://github.com/jedisct1/dnscrypt-=
proxy/blob/master/dnscrypt-resolvers.csv">https://github.com/jedisct1/dnscr=
ypt-proxy/blob/master/dnscrypt-resolvers.csv</a></div><div>[2] -=C2=A0<a hr=
ef=3D"http://stats.research.icann.org/dns/tld_report/">http://stats.researc=
h.icann.org/dns/tld_report/</a></div></div></div></div>

--485b397dd1e5d6cc79051ada8db7--