BANS method / Public DNS based wallet address

Abstract

The purpose of this method is to provide ability to link blockchain wallet or smart contract addresses with existing public domain names.

Motivation

The main motivation was to provide an easiest way of DNS re-usage in case of blockchain addresses resolving compare with Ethereum ENS. To use ENS users should register a .eth domain name for themselves by participating in an auction process, mediated by the blockchain.

BANS will allow you to use any short and user friendly domain names that could be found by everyone thought the simple procedure using DNS over HTTPS and DNSSec technics.

Background

The main goal is to provide secured and anonymous features to link and retrieve your custom blockchain address based on public domain name you own.

DNSSec (Domain Name System Security Extensions) a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality (if not Tor DNS servers).

If we keep calling DNS the phone book of the Internet, we could say that DNSSec is the protocol that ensures a number in the phone book (or blockchain address) actually belongs to the contact listed. It uses public-key cryptography to this end, and (in short):

• lets the DNS server signs records with a private key
• allows the DNS resolvers to verify the signatures with a public key

You could find an answers on security related questions from the following sources provided by Mozilla, Cloudflare and IETF:

1. RFC 3658
2. What is DNS over HTTPS
3. Mozilla Tests DNS over HTTPS
4. How-does-DNSSEC-work

Proposal

The main thing is that we should follow a unified specification scheme. You could also find an interactive example here (code examples included).

We could integrate BANS address retrieval process during Yoroi SEND UX:

It’s possible by Cloudflare https API method (you could use for ex. Google DNS Cloud API methods instead): curl -H 'acloudflare-dns.com/dns-query?name=bans.ada.0.kxp.one&type=TXT' name=bans.ada.0.kxp.one parameter is based on specification scheme.

response would be:

{"Status": 0,"TC": false,"RD": true, "RA": true, "AD": false,"CD": false,"Question":[{"name": "bans.ada.0.kxp.one.", "type": 16}],"Answer":[{"name": "bans.ada.0.kxp.one.", "type": 16, "TTL": 300, "data": "\"Ae2tdPwUPEZ7f7RgToFi4EbUozdBNEYs34kRvSKPc33PUD93QUPT9JmxXwq\""}]

We should validate DNSSec support to provide the best level of security. If AD flag is true, it means that every record in the answer was verified with DNSSec.

Note that kxp.one is not completely support DNSSec right now and its just an example. We need DS record support by registrar to achieve the best level of security. AD flag should be true. AD = Authenticated Data (for DNSSEC only; indicates that the data was authenticated)

We could also check DS record. Example: dig +short DS cloudflare.com response: 2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D6 3826F2B9 - The DS record stands for Delegation Signer, and it contains a hash of your public key as well as metadata about the key, such as what algorithm is uses.

Then we could validate data field as supported ADA wallet address. If user is OK with retrieved (presented below the input field) address - allow him to send funds on it.

else if not BANS related info with the provided domain name - show a common error message:

We could also provide a description about BANS method support in GENERAL SETTINGS screen (for example: in Features tab).

In the end we will get a very transparent BANS feature integration with a good profit of usage.

[SebastienGllmt]

Thanks for submitting a feature request for triage. Could you submit these as PRs instead of issues going forward? Thanks!

Thoughts:

• Address in DNS means the address will always be the same (instead of one address / transaction) so there is a privacy loss to this feature. You could try and resolve this by having the BANS field change either periodically or every time a transaction occurs but caching will make this either not work as expected or be inefficient.
• We would need to pay for a security audit of this feature so there is a non-trivial cost to adding this
• I would expect low usage of this feature since most users would not have support for this on their machine and most system admins would not want to go through the work setting up their servers to do this safely. This is not necessarily a reason to turn down the feature but it’s something to consider.

I would like to see:

1. How this compares to other standards such as BIP-70
2. Explanation for why to use this over OpenAlias
3. Motivation for creating a new record type instead of using TXT (which is already supported by all servers and clients)

If there is a good reason to pick BANS over other standards, then I would rather see this as a CIP before we implement it ourselves in Yoroi

[HM999]

Seems reasonable to me.

I think adding existing real world identities is as legitimate, or perhaps more legitimate than using SCs to create a new one like ENS Identities on Ethereum.

re: The risk is someone spoofs the mapping somehow to point to another address. There is information in the articles but is there an infosec person in IOHK that can confirm the ways someone might do that and how possible it actually is?

When designing the UI, be mindful that almost certainly Yoroi will want to add different identity -> address mappings in the future.