NeoDNS : A new DNS like the one we know

The goal

We wish to design a new DNS solution which offers the following:

1. Ease of migration: the solution must be able to coexists with the existing DNS and PKI. Adopting NeoDNS should not break backwards compatibility.
2. Authentication of domains: users must be able to verify that they are talking to the legitimate service, without a globally trusted central authorit(y|ies). We relax this requirement and simple demand that an attempt at impersonation should become publicly known.
3. Performant: minimal overhead when compared with the existing systems.

Assumptions

It is assumed that the reader:

1. Has some knowledge about PKI and DNS
2. An understanding of blockchains in general

Terminology

Ease of migration

Since we want a system which can coexist with the existing infrastructure, NeoDNS must provide the following operations:

• Registrations
• Key updates (of the public key associated with the domain)
• Revocations

All these must be provided/controlled by the existing organization responsible for any given TLD (Talos). NeoDNS places no artificial restrictions and the list above can easily be extended.

A public ledger

In NeoDNS, every TLD has a public ledger, maintained by Talos.

With every update (any of the above actions) an entry is appended to this ledger. The ledger is broken up into blocks. A block contains all updates in the last 30 minutes.

Back to the blockchain

Rather than stuffing these into a blockchain directly, the latest additions to the ledger are hashed, together with the hash of the last update block. Thus creating a chain of update blocks.

This hash is added to a public blockchain (e.g the Bitcoin blockchain). Information for locating the hash is served by Talos together with the ledger (this information could also be included in the following block). Talos must insert a new checkpoint in the blockchain every 30 min and there is one ledger block for every checkpoint.

Note: Above we write 30 min, in reality this corresponds to a number of blocks in the blockchain (~3 for Bitcoin). We use 30 min for illustrative purposes.

Authentication : The obvious

Adding authentication on-top is straightforward.

Public keys are added to the DNS records stored in the public ledger. These keys are not added to the legacy DNS entries, but may also be validated against the existing PKI.

When Alice generates a new key for alice.com, she requests that Talos updates the ledger to reflect this. In addition she contacts a CA to have the key signed and thus maintains backwards compatibility.

Bob keeps a copy of the blockchain and the public ledger (downloaded from Talos). When visiting a site Bob queries the local copy of the public ledger (verified against the blockchain) and finds the corresponding public key.

Authentication : Trusted entities

This obvious approach, has obvious problems:

1. Bob needs to follow the blockchain. If he goes offline, he needs to download the entire blockchain and TLD ledger before visiting any site.

2. Bob needs to store a large amount of data. The ledger is potentially large and he needs to store one for every TLD he wishes to use (potentially hundreds).

This can be solved by offloading the work to a trusted entity (Trent).

Bob may have multiple trusted entities. He may switch them at any time (or operate his own) and they are not globally trusted by all users. He may choose to:

1. Cross check these against each other (since they should all return the same key)
2. Have one for each TLD (an entity may only follow a subset of TLDs)
3. Rotate these for privacy reasons.

Below it is assumed (for simplicity) that Bob only has one (Trent)

Contacting Alice

Assume that Bob (an end user) wishes to access “alice.com”:

1. Bob makes a request to Trent who tracks the .com TLD ledger
2. Trent therefore has a local copy of the blockchain (e.g Bitcoin full node) and the ledger published by Talos. She continually verifies that these two are in agreement with each other.
3. She searches though this ledger to find the entry for “alice.com”
4. She returns the public key and address to Bob
5. Bob initiates a secure connection to alice.com, using the public and address supplied by Trent.

Migration

This can run parallel to existing DNS and does not require dedicating TLDs to the system.

• Talos may implement NeoDNS if he pleases (or opt-out)
• Talos does not need to contact ICANN to implement NeoDNS
• Talos still retains full control of the TLD (including revocations)

Attacks

Trent

Trent may serve Bob an illegitimate public key and ip address. If Trent is malicious all security is lost. This may be mitigated by cross checking multiple Trusted Entities, with the cost of reduced performance.

Talos

Malicious updates

Suppose Talos is coerced into replacing the public key for “alice.com”. There is no direct protection against this, but it becomes instantly known to the world since this needs to be published in the ledger and committed to the blockchain, before being considered valid by Trent and served to Bob.

NeoDNS forces transparency for the DNS/PKI provider, but does not stop a malicious actor from coercing Talos – however the compromise becomes public knowledge.

Modifying history

Suppose Talos is coerced into modifying previous entries in the TLD ledger. This would get detected by the Trusted Entities (even if they start tracking at a later time), since the hashes in the block chain would not match the TLD ledger.

Alternate ledger

Talos may add more than 1 hash value per TLD ledger block. This allows him to maintain 2 alternate ledgers and potentially switch at a later date.

If we wish to mitigate this, we can do so by requiring that Talos sign the ledger block hashes. This increases the size of the blockchain, but allows Trent to ensure that Talos appends exactly one value to the blockchain.

Alternativly we can piggy-back of the underlaying cryptocurrency and require that the OP_RETURN transaction (holding the hash) is funded from a specific address.

Blockchain miners

50 Percent attack

Since the ledger is secured via blockchain, the scheme is vulnerable to a 50 percent attack if a majority of the blockchain computation power is operated by malicious miners.

Most notably they may cause a complete DoS.

However, if the scheme is based on Bitcoin, the underlying cryptocurrency has greater problems than DoS in this scenario.