Denarius NVS and DNS

Denarius Domain Names

Are you afraid that your website could be suspended by authorities? With “the screws tightening” around the world, your fears might well be justified.

DDNS (Denarius DNS) is the way out.

Completely decentralized, DDNS is safe from any kind of censorship. No other user can modify your record — only the record creator can manipulate its content.

DDNS websites can be easily resolved with the help of several upcoming browser extensions, by using DDNS Gateways, or via DNS proxies.

DDNS is a decentralized domain name system supporting the full range of DNS records. DDNS operates under the “dns:” service abbreviation in the Denarius NVS.

Denarius’s secure and distributed blockchain, domain name records are completely decentralized and uncensorable. They cannot be altered, revoked, or suspended by any random authority. Only the record owner, i.e. the one who controls the private key to the associated D payment address, can modify or transfer it to another owner. These actions can be performed using the Denarius Name Registrar in the Denarius native wallet, or via the name_new or name_update commands in the Denarius JSON RPC.

DNS records can easily be retrieved from any Denarius wallet via the Denarius API using JSON-RPC or the command line, or via the standard RFC1034 DNS protocol built into every Denarius native wallet.


Information on Denarius NVS


Denarius provides a service for storing name->value pairs in its blockchain (Name-Value Storage, or NVS). The initial concept was inherited from the NameCoin cryptocurrency yet while NameCoin is mostly focused on supporting decentralized domain zone *.bit in their extension, Denarius provides a universal, extensible service to store and maintain name->value pairs without imposing a narrow specialization.

Denarius also supports a distributed alternative DNS service too (DDNS), and each Denarius wallet contains a built-in simple DNS server, supporting the standard RFC1034 UDP DNS protocol.



Denarius NVS overview

Denarius stores data in the blockchain by a set of name->value pairs:

  • name – label for the stored data, up to a length of 512 bytes.
  • value – the data itself, up to a length of 20*1024 (20kb).

Denarius allocates up to 20kB for value, enough to fit public keys for most modern cryptographic applications. We consider a cryptocurrency blockchain to be an extremely reliable place to publish and maintain public keys for many cryptographic applications such as SSH/SSL certificates. Like regular payment transactions, NVS pairs stored in the blockchain also get confirmations during block generation, and are virtually immune to being altered in a Man-In-the-Middle attack.

Since the blockchain is a trusted data store protected from unauthorized modification it is a great foundation for the deployment of cryptographic Public Key Infrastructure (PKI), Proof-of-Data (POD), immutable recordkeeping, timestamps, IPFS, and other distributed services.

The Denarius blockchain will accept NVS pairs without any restrictions to the data format of either the name or value. However, for standardization purposes we recommend the following format for names:


For example:


Each NVS pair has its owner. Each owner is specified by the Denarius payment address stored together with the pair. Only the owner of the payment address is able to modify or delete the pair, or transfer ownership to another address. When a new pair is created, a new payment address for the pair is created in the local wallet.

You can manage Denarius NVS entries either through the Denarius wallet QT, or denariusd JSON RPC.



Denarius Service abbreviations

While you are free to create your own services using Denarius’s NVS, we recommend using the following supported service abbreviations: 

dns: – Denarius DNS – DDNS

ssh: – Denarius SSH – DSSH (Coming soon)

gpg: – Denarius GPG – DGPG (Coming Soon)



Managing Denarius NVS entries with the QT

The “Manage Names” tab will include the following elements:

  • name: If this NVS entry will be used with a particular service abbreviation (dns:, ssl:, ssh:, etc) then characters allowed by the appropriate service prefix should be used. e.g.
  • days: How many days to register the name (between 1 and 9999). Upon expiration, the name can be taken by another user.
  • Operation type:
    • NAME_NEW – create a new name.
    • NAME_UPDATE – update values, change owner, or extend the registration.
    • NAME_DELETE – delete a name.
  • value: To be filled with the content to be associated with the name. The percentage indicator shows how much of the 20kb maximum space is used. This field can contain ANY type of data, although conventions should be observed when the name-value pair is to be used by a particular service. e.g.
A=|TXT=example txt record
  • Import: This button allows you to choose any file (not more than 20kb), to be inserted in the value field.
  • new address: To enter the D-address you wish to transfer the name to. Applicable only for the NAME_UPDATE operation.
  • Submit: This button confirms the operation and submits the data to the Denarius blockchain.
  • Names in your wallet: This table displays a list of your names. Yellow fields indicate the name is pending or when less than a month remains before expiry. Red fields indicate expired names.
  • Filters:
    • Owned by me – displays only names owned by the wallet.
    • Owned by others – displays names transferred to others.
    • Expired – displays expired names previously owned by the wallet.

Managing Denarius NVS entries with the daemon


Below is the list of Denarius JSON RPC commands for managing NVS entries. Parameters in square brackets [ ] are optional.

name_new <name> <value> <days> [toaddress]

Create a new Denarius NVS pair and publish it into the blockchain.

  • days : initial lease time in days. (Max ~100 Years)
  • toaddress : address to register new name to

name_update <name> <value> <days> [toaddress]

Update the value for an existing name.

  • days : adds lease days. (Max ~100 Years)
  • toaddress : transfer name ownership to another Denarius address.

name_delete <name>

Delete a Denarius NVS pair from the blockchain.

name_show <name>

Retrieve a Denarius NVS pair and transaction info for specified name:

name_list [<name>]

List all matching NVS pairs belonging to the current wallet and those that were owned in the past. If name is not specified, then it lists all names:

name_scan [start-name] [max-returned]

List Denarius NVS pairs existing in the blockchain, returning max-returned entries (default 500):

  • start-name : An integer. Skip this number of names. This is useful to download the list in chunks.

sendtoname <name> <amount> [comment] [comment-to]

Send an D payment to the address associated with the specified . For instance, send a donation to the owner of a DDNS address of a website you visit:

  • amount : D amount, rounded to the nearest 0.01.
  • comment and comment-to : will be stored in the local wallet, not in the blockchain.

name_filter [regexp] [maxage=0] [from=0] [nb=0] 

Scan and filter names.

  • regexp : apply regexp on names, empty means all names.
  • maxage : look in last maxage blocks.
  • from : show results from number from.
  • nb : show nb results, 0 means all.
  • stat : show some stats instead of results. 

Denarius NVS Name Fees

The cost to do any NVS operations on the Denarius blockchain is roughly 1 D.

0.9 D goes to miners in the network to help support the network by doing any name operation

0.1 D goes to the address for the name operation and is non-spendable

Denarius NVS name as a payment alias

It is possible to send D currency directly to a name, without knowing the address.

To create a name alias for payment address, just create an NVS pair with a specified unique name and any value. We recommend entering a text description as the value.

All payments made to that name will be sent to the appropriate payment address, to which the name is registered. e.g:

name_new "@buzz" "Donation name registration for an awesome person" 365

You can then send @buzz D payments with the JSON RPC command:

sendtoname @buzz (amount)

Denarius DNS (DDNS)

DDNS is a system for decentralized domain names supporting a full range of DNS Records. DDNS operates under the “dns:” service abbreviation in the Denarius NVS.

Because of Denarius’s secure and distributed blockchain the domain name records are completely decentralized and uncensorable and cannot be altered, revoked or suspended by any authority. Only a record’s owner can modify or transfer it to another owner, and a record’s owner is determined by whoever controls the private key to the associated payment address.

Only DDNS record owners can manage their records: change values, lease times, or delete them or transfer ownership to another D address. These actions can be performed using the Denarius NVS in the Denarius native wallet QT, or via the name_new or name_update JSON RPC commands in the Denarius JSON RPC API.

DDNS records can easily be retrieved from any Denarius wallet using JSONRPC or the QT, a standard RFC1034 DNS protocol is built in to every Denarius wallet.


Supported DNS zones

Technically, DDNS can support any DNS-zone or TLD. However, for seamless integration into a standard DNS tree, and to prevent collisions with existing DNS-zones, we currently recommend creating DDNS records only in the zones: *.d, *.dnr, *.king, *.ipfs, *.sys, *.denarii.

Current root zones supported by DDNS, and their intended purpose:

Zone Intended Purpose
.d websites associated with Denarius
.dnr websites associated with the old Denarius ticker
.denarii websites associated with the prophecy
.king fun domain
.ipfs IPFS (Interplanetary File System) Hosted Sites
.sys System and Software Type Sites

Accessing DDNS zones

There are several ways that DDNS domains can be reached:


Browser extensions

Several 3rd-party browser plugins exist which allow you to easily visit DDNS domains:

  • None available currently, WIP

OpenNIC & OpenDNS

  • Not available yet

Proxy servers

3rd-party proxy servers can provide access to DDNS zones:

  • None currently available, WIP




Creating and maintaining a DNS record

Denarius’s built-in DNS server supports the following DNS record types:

Record abbreviation Service description
A IP V4 address
AAAA IP V6 address
NS Name server record
PTR Pointer record
CNAME Canonical name record
MX Mail exchange record
TXT Free form text message
SD Subdomains (see below)

Note: SOA, WKS, and SRV records are not directly supported by Denarius’s built-in DNS server.

To insert a DNS record into the Denarius blockchain, create (or update) a name->value pair under the “dns:” service abbreviation in the Denarius NVS as follows:

"name" : "dns:<your_name_here>"
"value" : "<list of NS-records>"

For example:

"name" : "dns:example.d"
"value" : "A=,|AAAA=2607:f8b0:4004:806::1001||TTL=4001"

In this example the domain example.d is specified by:

  • two A-records ( and;
  • one AAAA-record (2607:f8b0:4004:806::1001);
  • one NS-record (;
  • a TTL record.

The records are separated by the default separator vertical bar or pipe (“|”). If necessary, you can redefine the separator by prefixing the value with \~\<new separator character>. For example, if you wish to use a hash character “#” as a separator instead of a pipe you can assign it with “\~#” at the start of the value as follows:

"value" : "~#A=,"

Note, if you use the space character ” ” as a separator, you will not be able use it inside the fields. Therefore, you should select an appropriate symbol as a separator for your records instead.

As described above, each record can contain multiple values. In the provided example, the A-record contains two values, separated by a comma “,”. You can also redefine the value separator with \~\<new separator character>. The following example demonstrates how to redefine the separator two times: slash “/” as record separator, and asterisk “*” as value separators for multiple TXT-records:

"value" : "~/TXT=~*This is text, Hello!*2nd text/,,"

In the last example we’ve demonstrated the usage of a MX record. The value of MX contains a mail exchanger reference and priority, separated by a colon “:”. If priority is omitted, the default value is 1.

Also, intentionally omitted in the last example is a TTL record. The default value for TTL is 24 hours.



Naming requirements

Domain names may be formed from the set of lowercase alphanumeric ASCII characters (a-z, 0-9). In addition the hyphen (“-“) is permitted if it is surrounded by characters, digits or hyphens, although it is not to start or end a name. Only lowercase letters are valid.

Internationalized domain names

Internationalized domain names (Arabic, Chinese, Cyrillic, etc) are technically possible using punycode.

For example, if we want the following internationalized domain name:


Then we must transcribe it using a punycode converter and register the result:



A general challenge with distributed DNS is that anyone can allocate any unique name, allowing someone to register a subdomain for a domain that they do not own. To remedy this situation, DDNS has special ways to manage subdomains:

  • A subdomain (SD) record in the DNS parent’s NVS value, permits lookup and resolution of the subdomain directly within the Denarius DNS subsystem e.g. SD=www,ftp,mx
  • A nameserver (NS) record in the DNS parent’s NVS value, allows reference to external nameserver(s) managed by the domain owner, to provide authoritative lookup and resolution of the subdomain external to Denarius DNS e.g.

Subdomain resolution is applied in the following order, recursively to all third-level subdomains and deeper:

  1. First, check SD record in the parent’s DNS value for reference to the requested subdomain. If a reference for the subdomain is found then look up the subdomain within the Denarius NVS subsystem.
  2. Next, check for nameserver (NS) record in the parent’s DNS value. If found, generate reference to external nameserver.
  3. If no resolution results from SD or NS records, return as per parent domain (i.e. ignore subdomain prefix).

NOTE: When utilizing external nameservers, please take care with correct name resolution in those servers, including any gateway-suffixes.


Example 1 – parent contains SD and NS records

[1] dns:example.d -> A=|SD=www,gopher|
[2] dns:www.example.d -> A=

In this case, subdomains will resolve as follows:

  • example.d will be resolved by record [1], and return A=
  • www.example.d will be approved by record [1], resolved by record [2] and return A=
  • gopher.example.d will be approved by record [1], and not resolved, since NVS does not contain an appropriate DNS record. This will return NXDOMAIN.
  • mail.example.d will not be approved by record [1], but the NS record will generate a reference to external server, which may or may not resolve this subdomain.

Thus a single record [1] supports flexible hybrid resolving:

  • www is resolved by Denarius NVS.
  • gopher is blocked.
  • all others are resolved by delegated


Example 2 – parent contains SD record only

[1] dns:example.d -> A=|SD=www,gopher
[2] dns:www.example.d -> A=

In this case, subdomains will resolve as follows:

  • example.d will be resolved by record [1], and return A=
  • www.example.d will be approved by record [1], resolved by record [2] and return A=
  • gopher.example.d will be approved by record [1], and not resolved, since NVS does not contain an appropriate DNS record. This will return NXDOMAIN.
  • mail.example.d will not be approved by record [1], and (because of missing NS record) prefix “mail” will be ignored and resolve the same as example.d.


Example 3 – parent contains NS record only

[1] dns:example.d -> A=|
[2] dns:www.example.d -> A=

In this case, subdomains will resolve as follows:

  • example.d will be resolved by record [1], and return A=
  • www.example.d will not be approved by record [1], and will generate a reference to external server, which may or may not resolve this subdomain.
  • Record [2] will be ignored, and will not participate in DNS resolution.
  • mail.example.d will not be approved by record [1], and will generate a reference to external server, which may or may not resolve this subdomain.


Example 4 – parent contains no references to subdomain

[1] dns:example.d -> "A="
[2] dns:mx.example.d -> "A="

In this case, subdomains will resolve as follows:

  • example.d -> “A=”
  • mx.example.d -> “A=”
  • www.example.d -> “A=”
  • upload.ftp.example.d -> “A=”

Because record [1] does not contain any SD or NS records, all subdomains will be resolved to the “parent domain” example.d. Record [2] will be ignored, and will not participate in DNS resolution.




Integration into a regular DNS tree

First, activate the RFC1034 DNS server in Denarius by specifing two optional parameters in the denarius.conf config file, DDNS and DDNSport:

ddns=1 # Run D DNS server. Default is 0 (don't run)
ddnsport=NNN # Port for D DNS, default is 5333

To integrate Denarius DNS server into a regular DNS tree, you can use full-service DNS or caching DNS. The standard Windows DNS-client is unable to perform this work, so you should use an additional DNS proxy server to do it on Windows. Below we will show some examples.






Single PC, Acrylic DNS proxy

Running the Denarius wallet and everything else on a single PC is the most simple case. For this we recommend to install the lightweight Acrylic DNS Proxy onto your PC. Acrylic will improve the performance of your PC by resolving DNS requests with the local cache, decreasing latencies with browsing or any other Internet activity.

For installation and initial configuration in Windows, see the guide on the Acrylic website. After installation you should configure Acrylic to integrate Denarius domain zones. A config file example is available online. To configure, you should forward all requests to DDNS zones (*.d, *.dnr, *.denarii, *.king, *.sys, *.ipfs) to the local Denarius wallet, and all requests to other zones to the default DNS provider. This can be configured in the Acrylic config file as follows:

SecondaryServerAddress= SecondaryServerPort=53 SecondaryServerProtocol=UDP SecondaryServerDoHProtocolPath= SecondaryServerDoHProtocolHost= SecondaryServerDoHProtocolConnectionType=System SecondaryServerDoHProtocolReuseConnections=Yes SecondaryServerDoHProtocolUseWinHttp=Yes SecondaryServerSocks5ProtocolProxyAddress= SecondaryServerSocks5ProtocolProxyPort= SecondaryServerDomainNameAffinityMask=^*.d;^*.dnr;^*.denarii;^*.sys;^*.king;^*.ipfs;* SecondaryServerQueryTypeAffinityMask= IgnoreFailureResponsesFromSecondaryServer=No IgnoreNegativeResponsesFromSecondaryServer=No ; ; The configuration of your tertiary Denarius DNS server. ; For more details refer to the primary DNS server configuration comments. ; TertiaryServerAddress= TertiaryServerPort=5333 TertiaryServerProtocol=UDP TertiaryServerDoHProtocolPath= TertiaryServerDoHProtocolHost= TertiaryServerDoHProtocolConnectionType=System TertiaryServerDoHProtocolReuseConnections=Yes TertiaryServerDoHProtocolUseWinHttp=Yes TertiaryServerSocks5ProtocolProxyAddress= TertiaryServerSocks5ProtocolProxyPort= TertiaryServerDomainNameAffinityMask=*.d;*.denarii;*.dnr;*.sys;*.king;*.ipfs TertiaryServerQueryTypeAffinityMask= IgnoreFailureResponsesFromTertiaryServer=No IgnoreNegativeResponsesFromTertiaryServer=No

In Windows, the default path to the Acrylic config file is: C:\Program Files (x86)\Acrylic DNS Proxy\

You can download this AcrylicConfiguration.ini file (, pre-configured to use Cloudflare and Google as the primary & secondary DNS-provider (for regular DNS-tree), and a local Denarius wallet as the ternary provider, for domain zones *.d*.dnr*.denarii*.king, *.sys, *.ipfs.





Single PC, BIND DNS proxy

Instead of installing a DNS proxy, you also have the option to install a full service DNS server. Fortunately, the full DNS server “BIND” is available for Windows, and is free. You can find many tutorials on the internet that show how to install BIND onto Windows. For example, see this manual.

After installation you should tell BIND to forward D-zones to the local Denarius wallet by adding to the BIND configuration file named.conf as follows:

zone "d" {
 type forward;
 forward only;
 forwarders { port 5333; // Local Denarius wallet
zone "dnr" {
 type forward;
 forward only;
 forwarders { port 5333; // Local Denarius wallet
zone "denarii" {
 type forward;
 forward only;
 forwarders { port 5333; // Local Denarius wallet
zone "ipfs" {
 type forward;
 forward only;
 forwarders { port 5333; // Local Denarius wallet
zone "king" {
 type forward;
 forward only;
 forwarders { port 5333; // Local Denarius wallet
zone "sys" {
 type forward;
 forward only;
 forwarders { port 5333; // Local Denarius wallet

Local network, BIND DNS proxy

If you have a server with a static IP address in your LAN, you can install BIND onto your server, and point your desktop PC’s primary DNS address to your BIND server. On the server you can run a headless Denarius wallet to which BIND will forward requests to the appropriate zones. In this case configuration of BIND is exactly the same as above.

Also you can run the Denarius wallet on any PC of your LAN, instead of on the BIND server. If so, you should change the forwarding address in the BIND configuration from to the IP address of that PC. Of course that PC should have a static LAN IP.




Local network, DNSMASQ proxy

Modern routers usually contain a built-in proxy DNS in their firmware. Usually this is DNSMASQ. Some router firmware like DD-WRT and OpenWrt (as well as others) allow you to configure the built-in DNS proxy (for instance, see DD-WRT DNSMASQ manual[] or OpenWrt DNSMASQ manual).

In this case the wallet should be run on a PC with a static LAN IP and DNSMASQ from the router would send DNS requests to that PC. Following are examples of the configuration lines needed to add into dnsmasq.conf. In this example the PC running Denarius has the LAN IP address


Public Internet, direct gateway

The ability also exists to make a public gateway from a regular DNS tree into DDNS. In this case, you can lease any public domain or subdomain, and point the NS records for this domain to a machine that is running the Denarius wallet with an active DNS server on port 53 (see in the next paragraph for how to define the port). Once you do this, all regular NS requests to that domain will be resolved by the DNS server, and answers will be retrieved from the Denarius NVS database in the Denarius wallet.

Thus, if you register any name with Denarius DNS, the name would be resolved by any Denarius DNS gateway. And your site site.d will be available through any such gateway, by links such as, or

To configure a new domain as a public Denarius DNS gateway, you need to specify DNS servers as authoritative for your zone (domain). For the domain, we specified two Name Servers (NS), authoritative for this domain with our domain registrar:


You can check this info using whois.

On each of these nameservers runs an Denarius wallet with an active DNS server which serves the gateway and local zone for DNS specific config parameters for the file denarius.conf are as follows:

If you are only running a DNS gateway for your local computer (with Acrylic or BIND) or for your LAN, it is enough to specify just a single parameter in denarius.conf:

# enable D dns

This will activate Denarius’s DNS server and run it on default port 5333, as allowed for DNS forwarding by DNS proxies (Acrylic, BIND, dnsmasq, etc).

To run as a public DNS gateway, you need to specify some additional parameters:

# Gateway suffix. This suffix will be ignored when a request is passed to the internal gateway.
# Requests for other domain suffixes will be ignored.

# NS Server port 53 is the default NS port and must be used if the server is public and "not forward only".

# Filter for allowed zones. Protection for "cool hackers", who try to lookup any external domains through our server
# or attack someone else by DNS amplification mechanism. Currently, only the four D-zones are allowed.

# Optional path for a file that contains names in the local gateway's NS zone (like
# Must be full path. Example:

The local config file (DDNSlocal.conf above) contains pairs in the format “name=value”. An empty name assumes “gateway as is”. The values use the same format as DDNS values in the blockchain. For example, the local file for is as follows:

# This is local zone config
# For built-in Denarius DNS

=A=|TXT=Denarius site
www=A=|TXT=Denarius www-site


Virtual webhosts (vhosts)

When you run virtual hosts, you will be required to modify your web server’s config to correctly distinguish your hostname with as many possible gateway-suffixes as you wish (or without suffix if name resolved by LAN or locally). This is easy to do by creating a vname-alias with an asterisk “*” as the suffix. The following example shows the appropriate Apache web server config for the virtual server exchange.d. Note the ServerAlias line:

<VirtualHost *:80>
  DocumentRoot "/var/www/exchange.d/html"
  ServerName exchanged
  ServerAlias exchange.d*
  ErrorLog  "/var/log/exchange.d-error_log"
  CustomLog "/var/log/exchange.d-access_log" common
  ScriptAlias /cgi-bin/ "/usr/local/libexec/cgi-bin/"