[continued]



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)


We looked at doing this in a single lookup as you did.  With one or two currencies this can be potentially more efficient.  As the number of supported currencies and addresses under a single name grows, however, this solution becomes potentially more problematic.  Please follow the use cases below:

Use case 1:  Wallet Name = "bob.foo.bar" or OpenAlias = "bob.foo.bar"

The only currency supported is bitcoin, and there are no colored coin formats supported.

OpenAlias case: 

1 packet lookup to "bob.foo.bar"
1 packet response with bitcoin address

= 2 packets


Wallet Name case:

1 packet lookup to "_wallet.bob.foo.bar"
1 packet response with supported address types
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 4 packets

Wallet Name Case 1a:

The wallet doing the lookup knows it wants bitcoin, so it skips the supported addresses lookup

1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 2 packets

In this use case we might create more traffic, but it could also be reduced by doing smart lookups.


Use case 2:  Wallet Name = "bob.foo.bar" or OpenAlias = "bob.foo.bar"

Many currencies and colored coin addresses are supported under the same name, lets say 100.  When you count different currencies and colored coin types, it could easily be hundreds, or over a thousand.


OpenAlias case: 

1 packet lookup to "bob.foo.bar"
100 packet responses with various addresses

= 101 packets


Wallet Name case:

1 packet lookup to "_wallet.bob.foo.bar"
1 packet response with supported address types
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 4 packets

Wallet Name Case 2a:

The wallet doing the lookup knows it wants bitcoin, so it skips the supported addresses lookup

1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 2 packets


While you may end doing "less lookups" under Open Alias, as it scales, you end up causing a significant amount of extra, unnecessary traffic.  

In addition to the obvious impact of being orders of magnitude more wasteful than necessary, it also creates privacy "leakage" by returning someone 100 different addresses when they only asked for one.  

Finally, because a single packet UDP transaction for a DNS lookup can create possibly hundreds of packets in response, the service can essentially become an amplifier for DDoS attacks.  (If I spoof the source address of my target with a query to a lookup that issues hundreds of packets in response to one packet, and I can have a real impact :( )


 
 
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

I think this is a good point, and one we weighed.  When we were making our original decisions.  Given the importance of ensuring that the lookups return the correct value, and the known vulnerabilities in DNS without DNSSEC, coupled with the fact that ICANN has mandated all zones and registries move to DNSSEC, our belief was and is that it was worth the trade off that there were cases where existing domains would not work. 


It is important to note, that ICANN has "required" for some years that registrars and registries support DNSSEC on the domains they register.  I personally believe we shouldn't delay use of DNSSEC until their registries had come up to current required Internet standards.  (Here are ICANN's registrar requirements showing the DNSSEC requirement, btw: https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#operation)

That said, what do others in the industry think?  We are basing our current standard on our believed best practices, and defaulted to "first, lose no money", given the irreversibility of bitcoin. 

 
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.


I think "DNSSEC is hard" is a bit of a boogey man that's not really true.  We are working on developing registrar by registrar instructions of how to do this, and we have typically found that if you are setting up DNS by yourself, adding DNSSEC doesn't take a lot of additional time, maybe an hour or so depending on your registrar. 

This known concern, however, is why when we launched our product (based on our standard record formats) that we wanted to launch it with a variety of options for people.  

In addition to these options there are also other hosting providers, and certain registrars that will allow you to setup DNSSEC on their DNS platforms.


1> One could choose the "0 click" installation process of just getting a free Wallet Name underneath their provider's name space.  This option has been free to end users in all cases so far, and I expect it always will be in the future (although that is up to the partner, so some may choose to charge).

2> If they wanted some provider independence, but someone to manage things for them, they can register a name through us and manage everything via our web interface.  This can cost them as little as $1.95/yr through us.  

3> Finally, for the "do it yourselfer" who wants full control themselves, they can simply follow the formats on our developer page and do the whole thing themselves.  If they do this by registering their own ".bit" this will cost them less than $0.25.  If they have an existing domain name, even less.




 

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.

That's some interesting data, and runs counter to the research of the IETF DNS working group.  If you are willing to share your data, I can put you in touch with the appropriate folks there to share your research.  I'd also love to see it!

 

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;)

I'd argue that we aren't locking "huge portions" of the Internet.  You are correct that about 15% of TLD's are not yet signed, even though they were required to be by ICANN.  

As I said above, I believe the requirement to not lose money and the fact that other options are available for those running on TLD's that are out of compliance, is worth the trade off that some existing names won't work until their TLD's come into compliance with current Internet standards.

And, as we covered above, we don't force anyone to use our registrar, nor any of our services in order for Wallet Names to work for them.  We never have.  It's just not who we are.



 

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.


These are actually vastly different pieces of software, at least from the description, and a first read of the code.  My understanding is the software you linked to here basically takes the DNS work out of lookups for people, as we released: https://github.com/netkicorp/wns-api-server  Its our Wallet Name Lookup server.  

Addressimo, as I described above, provides a different purpose.  Its a way for service providers, mobile wallet providers or end users to have an online server that can serve unique wallet addresses ala HD Wallets (BIP32) or signed Payment Requests (BIP0070).  This allows for an easy way to increase security and privacy by serving a unique address for every request, and/or sign the address (and other optional data) with an X509 private key to prove ownership of the address in a way independent of and supplemental to the DNSSEC chain (also can be DANE for yet another layer of security).  It also supports offline signing of the Payment Requests so the server doesn't have to have access to a private key, or need to be trusted.



 


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.


I'm a little confused by these closing statements.  Our system has, from the beginning been open in terms of the fact that anyone could both serve names or do lookups without ever touching our servers, talking to us, or us even knowing that they did it or that they even exist.  Our system has NEVER been one where folks were required to use us for any portion of the service, and from our first beta product launch our open source tools did all lookups against DNS records and the blockchain, never any proprietary servers or interfaces on our side.  

In terms of the format itself being open, we have already made several extensions and modifications to it as a result of conversations with industry participants in order to ensure that what we are building meets the needs of the community at large.  We will gladly continue to do so, it is how we ensure we are building something everyone needs!

I'd love to know where you got information that we were in some way a closed and centralized system so that we can have an opportunity to clarify that misconception.  


In terms of finding a common standard, as I said, I am thrilled to have the conversations, but there are some places, highlighted above, that would cause me to hesitate to "just implement" the Open Alias standard.  I can also see places where bringing the formats together to one standard could have strong benefits, for example:

I think formatting the record as a key value pair with versioning has merit, and would love to move it in to what we are doing (and likely will).

On the other side, I think the two level lookup provides a lot of value at scale over trying to send back a bunch of text records when only a small portion of the data is used.

I'd love to hear thoughts from others in the community on mandating DNSSEC and thoughts on DNSCrypt.  I have a strong opinion on both of those but would love to engage in thoughtful dialogue around what path best suits the need of the community.  


Looking forward to the discussion!

On Thu, Jul 16, 2015 at 5:55 PM, Justin Newton <justin@netki.com> wrote:
I am breaking this into a couple of pieces as my first response has been in a moderator queue for some time because it is too long.


TL;DR version - Wallet Name Service has always been a decentralized and distributed service that it no way requires you to ever touch the Netki infrastructure.  We want to work with the community, as we have been from the beginning, to come up with the best standard possible.  

Longer answers inline below.



On Tue, Jul 14, 2015 at 12:07 PM, Riccardo Spagni <ric@spagni.net> wrote:


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).


I appreciate the thought :)  I think where we differ is on where we believe the trade offs should be on perceived privacy versus censorship resistance and centralization.  


By having a limited number of proxies people need to go through to easily implement, be it the 4 you recommend, or 53, you actually have a very limited number of actors for an authority or hacker to go to in order to be able to install/force logging, or censorship.  This very centralization forces us back to a model where we need to trust a very small number of actors in order for the system to operate as designed.  This, to me, appears to be the opposite of the goals of the bitcoin ecosystem.  To ensure this point is clear, I strongly believe recommending people focus all lookups through 4 centralized "proxies" is a bad idea and counter to bitcoin's ideals.


The fact that hackers or state actors need to corrupt only a small number of servers/services in order to gain global visibility into all queries, I believe, breaks any perceived privacy gains from using DNSCrypt.  A very small number of hacks or subpoenas and everyone's records are fair game in one place.


For the highly privacy conscious they can, today do their DNS lookups over a non logging VPN connection without forcing everyone else through a handful of centralized servers.  Or they can use DNSCrypt optionally themselves.  All of our tools have always been open source and folks can modify them for their own desired uses, or submit pull requests with their own ideas.

We'd love to hear others thoughts on this.  While I believe that for now the centralization trade offs required to use DNSCrypt today (via a limited number of proxies) outweigh any perceived privacy benefits it provides, we are always open to what others in the community believe and have made modifications to how things work before as a result of feedback from industry participants.




 
 
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.

I think DANE is a great idea.  We were just discussing that with Andreas S., and are currently looking at whether we want to add this as optional versus mandatory, based on how widely available DANE is for folks using services like Cloudflare, Akamai, etc for their DNS, which many providers in the space today are.  

Of course, the security conscious could setup DANE on the URL we use AS IS.  There is no need to create a special kv pair for this as is done in OpenAlias.  As you know, DNSSEC and HTTPS support this today out of the box.

The CA validation, in our case, is an ADDITIONAL signature based validation to the DNSSEC chain, not a replacement for it.  


 [CONTINUED]




--

Justin W. Newton
Founder/CEO
NetKi, Inc.