DNS-zones

Realtime Register now offers brand new DNS-management options. In addition to our free to use nameservers that can be used with DNS-templates and zones on domain level, we have launched our Premium DNS-services.

Our Premium DNS-services added additional options to manage your (customer's) domains DNS settings in our portal and through our API. In addition to the already available DNS-templates and DNS-zones on domain level, we have now added functionality to manage zones separately from domains in your Realtime Register account. All the new functionality is available through our portal and API. In our Portal, we've added a new menu option; Zones. The DNS-zones are divided into two sub-categories; Premium DNS-zones and Basic DNS-zones.

Basic vs Premium DNS

Premium DNS-zones use Rcodezero DNS services and Basic DNS-zones use the free to use Realtime Register namservers. Key differences between Premium & Basic DNS services available for all Realtime Register resellers are outlined in the table below.

Managed & Unmanaged DNS-zones

Domains and DNS zones are inherently linked in their configuration and lifecycle, therefore Realtime Register offers a way to manage the DNS zone in conjunction with domains. In this case the DNS zone is “Managed”. We also support DNS zones that are provisioned independent of the domain, these zones are “Unmanaged”. Key differences between managed and unmanged DNS-zones are outlined below.

• An unmanaged zone can be adopted by a domain though create/update/transfer domain by specifying the zone. The zone cannot be modified in the same action.
• A managed zone can be unlinked from the domain through update domain.

Documentation on where to find DNS-zone management in our portal can be found in the DNS-zones knowledge base article. Documentation on DNS-zone management through our API can be found in our API-documentation

Vanity/Custom NS

Alternative to the name server hostname provided by Realtime Register, you can configure your own custom/vanity name server hostnames.

For this to work the resolution of these hostnames needs to be setup correctly.

1

Add A / AAAA records to the zone containing the name servershostnames.(e.g. yourname.com)

ns1.yourname.com. IN A 192.174.68.15  
ns1.yourname.com. IN AAAA 2001:67c:1bc::15 
ns2.yourname.com. IN A 176.97.158.15 
ns2.yourname.com. IN AAAA 2001:67c:10b8::15
	

2

Create host object for the hostnames with the IPv4 and IPv6 addresses(e.g. ns1.yourname.com & ns2.yourname.com)

The addresses are:

1. Host 1: (e.g. ns1.yourname.com)
   A / IPv4: 192.174.68.15
   AAAA / IPv6: 2001:67c:1bc::15
2. Host 2: (e.g. ns2.yourname.com)
   A / IPv4: 176.97.158.15
   AAAA / IPv6: 2001:67c:10b8::15

Important

Consider securing the superordinate domain (e.g yourname.com) with registry lock to protect against unintended or malicious changes to the domain that may affect all domains using these name servers.

---

DNSSEC operations

With DNSSEC any changes made to the name server, key data or zone need to consider the implications to DNSSEC validation or risk resolution failure due to validation failures. 

Since DNS contains cache on many levels the time to live of these caches also needs to be taken in consideration. Also note that lowering the TTL of a zone only becomes fully effective after the caches with the previous TTL have expired. For any DNSSEC related changes take the highest TTL of all records.

In some cases, we can detect unsafe DNSSEC changes and will prevent these changes from being made directly. For example; moving a DNSSEC signed domain directly to the basic DNS service would result in validation failures and is not allowed. In this case DNSSEC needs to be disabled first, then wait for caches to expire and finally change to the basic DNS service. The wait time is not enforced, so at your own risk it is possible to issue the two changes directly after each other.

Moving a DNSSEC signed domain to a to be created DNS zone with DNSSEC is also considered unsafe.Since the zone is new, its key cannot have been pre-published in the existing zone.

In cases where a domain is not DNSSEC signed and is moved to a DNSSEC signed zone, or a domain has a DNSSEC signed zone and zone signing is disabled, we handle the separate steps automatically with consideration of cache timeouts.

In other cases where we cannot determine the safety of the operation, we allow the change and rely on your compliance to the procedures.

Management type	Managed	Unmanaged
Enable DNSSEC	Update domain: enable DNSSEC signing	Update zone:enable DNSSEC signing Add key to domain via key rollover
Disable DNSSEC	Update domain: disable DNSSEC signing	Update zone: disable DNSSEC signing Wait for DNS caches to expire Update domain: removekey
Key rollover	Fully automatic	Wait for key rollover notification (mail or queue) Add new key to the domain, remove old key Acknowledgedomain update (portal or api) Back to 1.
Incoming secure NS change (domain transfer or update)	Create unmanaged zone with DNSSEC enabled ! The signing algorithm of the old and new zones must be the same, Realtime Register Premium DNS currently uses 13 Retrieve the DNSKEY from the new zone Add the DNSKEY of the new zone to the old zone and re-sign if necessary  Add the DNSKEY of the existing zone to the new zone Add the DNSKEY of the new zone to the DNSSEC data of the domain, do not remove or modify the existing DNSKEY of the current zone. Wait for the DNS cache of the old zone and parent zone to expire. (24 hours normally safe) Update (or transfer) the domain with the option to adopt the zone Wait for the DNS cache of the old zone and parent zone to expire. (24 hours normally safe) Remove the old DNSKEY zone, the old DNSKEY will be automatically removed from the domain	Create unmanaged zone with DNSSEC enabled ! The signing algorithm of the old and new zones must be the same, Realtime Register Premium DNS currently uses 13 Retrieve the DNSKEY from the new zone Add the DNSKEY of the new zone to the old zone and re-sign if necessary  Add the DNSKEY of the existing zone to the new zone Add the DNSKEY of the new zone to the DNSSEC data of the domain, do not remove or modify the existing DNSKEY of the current zone. Wait for the DNS cache of the old zone and parent zone to expire. (24 hours normally safe) Update (or transfer) the domain to the new name servers Wait for the DNS cache of the old zone and parent zone to expire. (24 hours normally safe) Remove the old DNSKEY from the domain, and zone
Outgoing secure NS change (domain transfer or update)	Obtain DNSKEY from new provider ! The signing algorithm of the old and new zones must be the same, Realtime Register Premium DNS currently uses 13 Unlink zone from template if needed Add the new DNSKEY to the existing zone Decouple the zone from the domain Add the DNSKEY of the new zone to the DNSSEC data of the domain, do not remove or modify the existing DNSKEY of the current zone. Wait for the DNS cache of the old zone and parent zone to expire. (24 hours normally safe) Update (or transfer) the domain to the new name servers Wait for the DNS cache of the old zone and parent zone to expire. (24 hours normally safe) Remove the old DNSKEY from the domain The old zone is automatically	Obtain DNSKEY from new provider ! The signing algorithm of the old and new zones must be the same, Realtime Register Premium DNS currently uses 13 Unlink zone from template if needed Add the new DNSKEY to the existing zone Add the DNSKEY of the new zone to the DNSSEC data of the domain, do not remove or modify the existing DNSKEY of the current zone. Wait for the DNS cache of the old zone and parent zone to expire. (24 hours normally safe) Update (or transfer) the domain to the new name servers Wait for the DNS cache of the old zone and parent zone to expire. (24 hours normally safe) Remove the old DNSKEY from the domain Delete the old zone

Migration between different signing DNS providers is complicated and requires careful consideration. The easiest method is to disable DNSSEC, wait, update/transfer, wait, enable DNSSEC.

Master / Slave on PREMIUM service

Alternative to the provisioning trough records or templates zones can be provisioned from a (hidden) master, the DNS service then operates in slave mode.

• NS: Name servers are determined by the NS records provisioned on the master, they cannot be changed from the zone

• A zone can be converted to master by removing the current master and not specifying a template or records. The current records are kept as is and the link with the (hidden) master is removed. For managed zones this can also be done while converting to a different DNS service.
• If you wish you can include your own name servers (master or other slaves) in the provisioning. This cannot be done in combination with automatic DNSSEC signing since the signed zone is not replicated to your additional name servers.
• Zones are also synchronised from the DNS service to Realtime Register, this synchronisation is seperateand slower than the synchonisationfrom the master to the DNS service. To check the syncronisation status to the DNS service, query the SOA record and check the serial.

Updates

On zone changes, the master name server has to send DNS NOTIFYs to the control server. Then the control server fetches the SOA record from the master name server and if the serial is increased, a zone transfer is initiated and the updated zone data is distributed to the anycast name servers. If NOTIFYs are not sent, the control name server checks for zone updates every "refresh" seconds, according to the value of the "refresh" field in the zone's SOA record. To reduce SOA-query load on the control name server, a refresh value of 24h is used if the original value is lower than 24h. In all cases, it is mandatory for the master name server to increase the serial on zone changes. Otherwise, the changes will be ignored. 

NOTIFY: Configure your master name server to send NOTIFYs to the following IP addresses: 

NOTIFY target IPv4  83.136.34.50

NOTIFY target IPv6  2a02:850:8::50

Zone Transfer: Allow for the following networks zone transfer and query access: 

Transfer Sources IPv4  83.136.34.50

Transfer Sources IPv6  2a02:850:8::50

DNSSEC

With master/slave configuration DNSSEC can be enabled in two ways;

Automatic DNSSEC signing

• Enable dnssec signing on the zone
• Use the key provisioned on the zone (automatic for manage zones)
• Every time the zone’s signatures need to be refreshed (re-signing of the zone), the zone’s serial will be increased. Thus, for signed zones the zone’s serial announced by the Anycast nodes will be bigger than the serial on the customer’s hidden master. But, a higher serial on the anycast node is not an indication that the zone is up to date. Therefore, every time the serial is increased on the hidden master, the new serial should be higher than the serial on the anycast node. The solution is to use the Unix epochat the time of the zone update as the zone serial. This eases debugging and ensures proper zone updates even after un-signing a zone. 

DNSSEC signing on master

• Leave dnssec signing on zone disabled
• Sign zone on master
• Provision key on domain, also for managed zones this cannot be done automatically

---