Name system
The Domain Name System and Certificate Authorities (TLS/SSL certificates) system are built as chain of corporations (or private services), each one doing a specific job. A hack or malicious behavior of any of those corporations may put a web application, or program that does web calls at risk. Hacks, censorships, inconsistencies in the DNS world happen almost everyday.
A typical DNS lookup request will go through those 5 private services : DNS resolver, Authoritative Name server (2nd level), Registry's name server (TLD, 1st level), root server, and connection with a certificate authority for the validation of TLS certificate.
First core principle : the blockchain
The dappy name system is the core of the dappy project. It is a no-DNS name system and relies on a public blockchain platform which is the ultimate source of truth. The point of using blockchain is to make management of records, and distribution of web applications more secure simple, and to rely less on centralized untrustworthy or fragile DNS services, registries, registrars and private databases.
A record is a JSON object stored on the blockchain, and linked to a unique set of characters that were available at the time it was purchased, like "mysite" or "soccergames". In a very similar fashion to DNS records, a dappy record has fields like "IPv4", "IPv6", "caCert" etc.
See IDNA section to know which character are available in the dappy name system, and the reasons for those choices.
The list of possible fields is of no interests here.
Second core principle : trustless lookup queries or co-resolution
The improvement dappy brings over DNS and other name systems is the trustless lookup mechanism,
In a web browser context
A user inputs "soccergames" in the search bar and hits "enter".
in a server-to-server context
A program will issue a POST or GET request to an API at "soccergames"
Could it be a web browser, nodeJS runtime or executable, when the instruction to perform a network call is given, the context does not know the IP address yet, neither the CA TLS certificate. It must performs lookups, some people may call this step service discovery, or resolution.
In the dappy system, service discovery happens the following way: many requests are sent to a network of independant companies or agents (the dappy network), each agent is part of the same blockchain platform and shard and therefore has the same data locally.
The responses are then reconciled. Depending on the distribution (aaaaaa, aaabbb or aaaaab), the multi-request may fail or succeed.
See multi-request
Public direct access to the root of the name system (TLD)
Dappy allow any company or individual to purchase a TLD (top level domain) at the root of the name system. And to build its own sovereign PKI (public key infrastructure) and subdomain system the way it wants.
Name system
Today this is not possible except for very special cases. A given company has to go through Verisign to get a .com second level domain , or has to go to AFNIC to get a .fr second level domain.
Note that we do not critic or condemn the way it works currently, we want to emphasize though that the dappy system is way more simple, horizontal, and relies very much less on private intermediaries and permissions.
Certificate Authority and TLS / PKI
Same goes for the encrytion certificates, in the DNS today they cannot be self signed and must be signed by a public Certificate Authority like Let's Encrypt or Comodo SSL.
Dappy allows sovereign PKI from the root of the name system, typically a root name will have its own self-signed certificate, it may also put a third party's certificate, and delegate the PKI to another company or departement.
It changes almost nothing from a server configuration perspective. In the web server file system, the TLS certificates referenced in NGINX or Apache will be self signed instead of issued by a Certificate Authority.
The lower levels (second, third level domain names) are under construction. We cannot tell yet what will be the exact relations between subdomains, root certificates and intermediate certificates. It is very likely that they will be verified from top to bottom.
DNS over HTTPS
The entire discovery mechanism is encrypted. Every communication to nodes of the dappy network is done over HTTP+TLS, the certificate being hardcoded in the browser or library that performs the call.
This file that is not used yet in dappy browser codebase may help you understand as well.
BeesJS library has been built for that exact purpose of co-resolution as well, it may help you understand the logic of co-resolution.
Less single point of failures, more secure system overall
The only single point of failures remaining may be the operating system of the user and/or the server or package manager distributing the browser or library in the first place.
All the unique DNS services are gone (registrars, DNS resolvers like 1.1.1.1 or 8.8.8.8, DNS providers like Verisign etc.) and are replaced by a horizontal network in which there is no leader / unique entry.
Those are the general principles, it could work with any smart contract platform, and any implementation of a name system as smart contract. If you want to know how this is done in the current implementation of dappy with RChain smart contract platform check rchain-token repository.
Last updated
