DNSSEC scenario for Small ccTLD

From CoCCA Registry Services (NZ) Limited

Jump to: navigation, search


Understand DNSSEC Recods

DNS Security (DNSSEC) is designed to authenticate DNS response data, There are a lot of article describe the DNSSEC and how it work, in this wiki we will just introduce high level description how we can sign the TLD and publish the DS record at ROOT servers. first we need to understand the DNSSEC records:

- keys to sign the zone (ksk/zsk), which used to create a "signed" zone.

- The key data in the zone:

  1- DNSKEY - public key
  2- RSIG   - record digest
  3- NSEC- proof of non-existence (NSEC3). 

- keys to go to the parent registry (DS)

  1- Signature RR that the recursive verifies against.

CoCCA as Registry System, responsible for Zone Generation, and provide solution at Registry level to accept public keys and DS records from domain registrar, then publishing them into generated zone, for registry or TLD we should responsible for key pair generation and maintenance zone signing with out private key, then public key publishing. there are a lot of tools to generate the DNSSEC records, like Bind tools dnssec-keygen to generate the zone signing key. and key signing key, but still the issues is the key storage, key management. we can use openDNSSEC as tools to generate the DNSSEC tools, and it is provide a soft HSM, which we can use it as a key storage and management. - this mean for ccTLD if they want to sign there ccTLD they should first chose the suitable tools to generate the DNSSEC Records, this include also key storage and management, then they can generate the DS records and as Root management to add it at the Root servers, the ccTLD can use the https://rzm.iana.org to send request to add the DS records.

DNSSEC support in CoCCA Registry

CoCCA support the DNSSEC, CoCCA as a registry system allow registrar to publish the DS record for registerd domain via CoCCA GUI, then the CoCCA will include those DS records with next zone file generation, the CoCCA provide easy GUI to upload DS and we can include Key Data including Protocol, Algorithm, Pub. Key , ... .

we can see the following image which illustrate how we can add DS records for a specific domain:


Suggested scenario using CoCCA Registry with OpenDNSSEC

DNSSEC can be implemented in two scenarios:

First scenario

Signing static zone files, in this scenario the DNSSEC engine will be at the same master DNS server in most cases, then we will use it to sign those files every change happen to the zone file (when RR changed), then tell bind9 to use new signed zone, this mean the signing of zone will be when zone record updated, and usually this scenario used for static zone (less frequently changes), and consider as not fully automated signing solution and not recommend for TLD, but can be used for sub zones like nic.TLD. In this scenario we will follow the following steps:

  - Using installed DNSSEC engine (openDNSSEC) usually installed at same Master DNS server.
  - Add new zone to DNSSEC engine zone list then Sign the new zone, which will generate the DNSSEC records.
  - Generate DS records for new added Zone.
  - Configure DS records for new zone in CoCCA Registry system for sub zones like nic.TLD.
  - Configure Bind at nic.TLD name servers to use signed zone.

Second scenario

Signing using inline signing scenario, in this scenario any changes at the unsigned zone (like add new RR lead to change serial number on SOA RR) will notify the DNSSEC engine, Which already configured to listen on port 53, and pull zones from master using TSIG keys, then signing the zone (new RR), then notify the slave DNS server to pull zone from DNSSEC engine. In this scenario we will follow the following steps:

  - Using installed DNSSEC engine (openDNSSEC) at same Hidden master server for TLD or sub zone like nic.TLD.
  - Configure openDNSSEC to use DNS adapter and listening at port 53, and receive notify from Bind at Hidden Master Server, then send notify 
    to secondary DNS server (authoritative DNS for this zone).
  - Configure Bind at Hidden Master Server to allow openDNSSEC transfer zone using TSIG, and notify it when any changes done to zones 
    (changed serial number).
  - Add new zone to DNSSEC engine zone list with DNS adapter and Sign the new zone.
  - Generate DS records for new added Zone.
  - Configure DS records for new zone in CoCCA Registry system for sub zones like nic.TLD, OR we should send it to Root zone managment if 
    the TLD is signned.
  - Most cases we recommended to use this scenario for TLD.

The small ccTLD which operate CoCCA Registry software can implement the DNSSEC using openDNSSEC, the ccTLD can use the OpenDNSSEC in different scenario, one of those scenarios is inline-signing scenario as the following figure illustrate:

Install and Configure the scenario components

In most ccTLD which deployed CoCCA Registry System, the Bind service has been installed at the the same server, the CoCCA registry system is responsible to generate the ccTLD zone file from Registry database, then copy it to Bind zone directory as the Zone File Processing Defaults configuration in CoCCA system, then it reload the bind process to take new zone update.


In normal case, the installed bind9 works as a Hidden master DNS server for unsigned zones, and allow the other server to XFR those zones, when the CoCCA software reload Bind, Bind will send NOTIFY messages to all slave servers. in our DNSSEC scenario we will forward the bind notify to DNSSEC engine, in our cas openDNSSEC, instead forward it to slave, then the openDNSSEC will sign the zones, then the openDNSSEC -will send the signed zones to slaves.

The previous figure, including OpenDNSSEC server with the following rule: - OpenDNSSEC will work as inline-signer - OpenDNSSEC should configure to listen on port 53. - OpenDNSSEC XFR the unsigned zone from Registry Master DNS server which installed at CoCCA system Server, it will receive the DNS NOTIFY

 message from  Registry Master DNS by DNS inbound adapter.

- The Signer engine in OpenDNSSEC according to DNSSEC record and signing policy, will sign the zones. - The OpenDNSSEC will send NOTIFY to second Hidden Master server (or slave server), the second Hidden Master server will transfer the signed

 zone from openDNSSEC, the slave will be responsible for signed zones.

- Second Hidden Master server will allow signed zone to propagate to other slave DNS servers.


- the recommanded setting are to install OpendDNSSEC on separate Server, which can secure for illegal access, and we should backup every key

 before we can use it, this can be done by configure openDNSSEC to require Backup before any Key signing and publish.

- Not recommended, The OpenDNSSEC can be installed at the same machine of Master Hidden DNS server (CoCCA Registry server), this required an

 IP for OpenDNSSEC engine to listen on port 53, while Bind at the Registry system will listen on port 53 using different IP.

- The OpenDNSSEC can be installed at the same machine of Slave DNS server for signed zone (or Master Hidden DNS server for signed zone),

 this required also an IP for OpenDNSSEC engine to listen on port 53, while Bind at Slave DNS server will listen on port 53 using different IP.

All Configuration:

We should configure all component, including Registry System, OpenDNSSEC and Slave DNS server for signed zone. We will assume the following IP in our scenario: - Bind Service at Registry system listen on IP: on Port 53. - OpenDNSSEC DNS adapter listener listen on IP : on port 53. - Slave DNS for Signned zone Listen on IP: on port 53.

We will Use the following zone in our test scenario : dnsseclab.coccaregistry.org.

First CoCCA Registry System :

Should already configured and Bind installed at the same server, for any issues about install and configure CoCCA registry it can found at this wiki. The only required configuration is to allow OpenDNSSEC IP to transfer and receive notification form BIND which installed at Registry System. Open named.conf file then add required config for allowed openDNSSEC transfer the zone and receive notify when serial number or zone updated.

   zone "dnsseclab.coccaregistry.org" IN {
       type master;
       file "/etc/namedb/dnsseclab.coccaregistry.org/db.dnsseclab.coccaregistry.org";
       allow-transfer {; };
       also-notify {; };

OpenDNSSEC configuration :

After install opendnssec, using opendssec wiki, then configure OpenDNSSEC, the most important thing is how to add zone and how to configure the ADDNS.XML file.

The important files are: - Conf.xml where overall configuration of OpenDNSSEC is defined, including repositories, which OpenDNSSEC stores Keys, in our case we will use SoftHSM.

The Most important config in conf.xml file in our case is the : Listener , it is an element that is needed when you use DNS adapters, in this tag we can specify a number of interfaces the Signer Engine has to listen to for DNS traffic, such as queries, NOTIFY messages and zone transfer requests.


Then you can restart opendnssec then excute netstat to see if the opendnssec begin listen on port 53:

ods-control stop /start

netstat -npla|grep :53

The result should similar :

 udp        0      0  *                               26294/ods-signerd 

The second important Tag is : NotifyCommand , that will tell the Signer Engine to call this command when the zone has been signed, “this is suitable of case the OpenDNSSEC and Slave DNS for signed zone on the same server”. <NotifyCommand>/usr/sbin/rndc reload %zone</NotifyCommand>

- Addns.xml, is the config file where you define zone transfer settings or so called DNS adapters, in our case the addns.xml file will be as the following:


Notice: we can use TSIG with addns.xml config as the following:

 < TSIG>
  <Name> key_name </Name>
  <Secret>Key Value</Secret>

- kasp.xml is an important file, where we define policies used to sign zones, security parameters (algorithm, key size) and timing parameters,

 we can use the default policy, or copy default policy then rename and modify it, we rename it to dnssec_cocca.

- zonelist.xml, contain list of zones that OpenDNSSEC will sign, we will add our zone to the zonelist.xml as the following:

     <Zone name="dnsseclab.coccaregistry.org">
                               <Adapter type="DNS">/etc/opendnssec/addns.xml</Adapter>
                               <Adapter type="DNS">/etc/opendnssec/addns.xml</Adapter>

OpenDNSSEC will not use any files as a source, but rather sign the zone it will get from hidden master which located at the Registry system, and will not store signed zone in files, it will forward it to slave DNS for signed zone.

Notice: - If this is fresh install of openDNSSEC, the next setup is to initialized the opendnssec database, using the following command:

ods-ksmutil setup

- If we already initialized the openDNSSEC, we should use the following command to add zone:

ods-ksmutil zone add -z dnsseclab.coccaregistry.org -j DNS -q DNS -i /etc/opendnssec/addns.xml -o /etc/opendnssec/addns.xml --policy dnssec_cocca

Or We can just edit the file zonelist.xml then add the new zone, then excute the following command: ods-ksmutil update zonelist - Before using the DNSKEY and publish the DS records we should ensure backing up the Keys to recover in case lost or compromised, from documentation:

“The OpenDNSSEC signer engine makes backup files to recover your zone data with no loss. These backup files will use up approximately three times the size of the signed zone on the HDD. The zones are also stored in memory. To keep track of updates, OpenDNSSEC maintains a previous, current and a new version of the zone.” We can add the <RequireBackup/> to configuration of softHSM. - After this step the openDNSSEC will sign the zone and generate the DNSKEY, the final step is to publish the DS records at the Parent, we can get the DS records using the following command:

ods-ksmutil key export --zone dnsseclab.coccaregistry.org --ds --keystate publish >DS_zone.txt

then you can publish the DS records at the parent coccaregistry.org zone file.


you can display all keys at your opendnssec with the following command:

ods-ksmutil key list -v

When the records indicated have been seen in DNS then:

ods-ksmutil key ds-seen --zone zone --keytag TagNumber

Then you can see the keys is now active:

ods-ksmutil key list

Notice: In emergency cases the manual keyrollover may be desired, you can do this using the ods-ksmutil command like this:

First step:
 Scheduled rollover, 
 ods-ksmutil key rollover --zone dnsseclab.coccaregistry.org --keytype KSK
 ods-ksmutil key rollover --zone dnsseclab.coccaregistry.org --keytype ZSK

Second step for KSKs - Publish the DS to the parent:
 ods-ksmutil key export --zone your_zone  --ds  >DS.txt

When the records indicated have been seen in Parent:
 ods-ksmutil key ds-seen --zone dnsseclab.coccaregistry.org --cka_id xxxxxxxxxxxxxxxxxx


   if you do not see the signed zone (opendnssec does not sigin it),then you can force the signer to sign:
   # ods-signer sign dnsseclab.coccaregistry.org

Personal tools