2.3. CORBA servers

This is a set of components which implement the backend of the Registry and which can run independently of each other. All of them use the same ORB implementation (omniORB) which takes care of the server side and process threading.

2.3.1. C++ daemons

These backend components are coded in C++.

Each of them is launched in a separate process and they may share a single configuration file.

2.3.1.1. fred-rifd

The registrar interface daemon.

This daemon implements operations over the database defined in the EPP protocol and it is used by the EPP service. Every EPP operation is mapped to a corresponding CORBA operation. Operations over objects are idempotent, i.e. if the same operation is invoked repeatedly, it does not change the state of object in the Registry.

The daemon is aware of all connected clients; if a client connects in a new session, a unique identifier is generated to identify the session in EPP communication and in the audit log.

All clients’ activity is recorded in the database including the original request and response XML files.

Object-altering operations make the system record the object in the history before the change is applied.

A database connection is opened during each EPP operation (and closed at the end). Therefore the pgpool tool is utilized to cache the connections, thus reducing the connection overhead.

2.3.1.2. fred-pifd

The public interface daemon.

This daemon implements operations over the database which make information about domains accessible to the public; it functions as the backend for the unix whois, web whois and RDAP.

2.3.1.3. fred-rsifd

The record statement interface daemon.

This daemon implements operations over the database which allow generation of signed PDF documents with information about registrable objects; it functions as another backend for Daphne, web whois and Domain Browser extension.

2.3.1.4. fred-adifd

The administration interface daemon.

This daemon implements administration operations over the database which allow to browse any information in the Registry (including the history and audit log) and to add and modify some of it.

It functions as the backend for Daphne, the web administration service.

2.3.1.5. fred-akmd

The automated keyset management daemon.

This daemon implements operations over the database that support automatic management of keysets (loading domains with name servers, updating DNSSEC, notifying contacts); it functions as the backend for the AKM client.

2.3.1.6. fred-accifd

The accounting daemon.

This daemon implements operations for pairing processed payments of registrars with credit and invoices.

2.3.1.7. fred-msgd

The messaging daemon.

This daemon implements operations for generating and sending text messages (SMS) and printed letters.

2.3.1.8. fred-logd

The audit logging daemon or “logger”.

This daemon creates audit trail of all user activity that passes through FRED applications and modules (i.e. CORBA clients, see the Diagram of FRED components).

2.3.1.9. fred-mifd

The daemon of the MojeID extension.

This daemon implements operations for the MojeID extension.

2.3.1.10. fred-dbifd

The daemon of the Domain Browser extension.

This daemon implements operations for the Domain Browser extension.

2.3.2. PYFRED daemon(s)

These backend components are coded in Python.

The PYFRED is a framework which provides common functions to several modules that act as standalone CORBA servers and implement various operations over the database.

The common functions provided by the framework encompass:

  • process logging,

  • database connection management,

  • parsing of a configuration file,

  • ORB initialization and registration of objects with the CORBA naming service,

  • launching of periodic tasks registered by the modules.

The modules can run either in a single process or in several processes and they may share a single configuration file.

2.3.2.1. GenZone

The zone generator daemon.

This daemon implements operations over the database used during zone file generation.

A generation is requested by the client application that can run on another machine. The client receives a portion of data of a fixed size, first, and then orders the remaining data in small chunks. (The total size of a zone file can reach hundreds of MB.)

2.3.2.2. Mailer

The mailer daemon.

This daemon implements the part of the notification system that delivers messages through email. It integrates a templating system for email assembly, operations for sending and archivation of outgoing email and search in archived messages.

Note

The mailer does not send email by itself, it just hands all email over to a mail transfer agent.

Attachments are either constructed from templates or retrieved from the file manager.

The mailer is used by the CORBA servers fred-rifd, fred-adifd, TechCheck, and also by the CORBA clients WebAdmin and MojeID extension.

2.3.2.3. FileManager

The file manager daemon.

This daemon implements operations for managing files, namely the upload, download and search of managed files. Each file is stored in the file system as such and only its metadata are recorded in the database.

The file manager is used by mailer, web whois service and file manager client.

2.3.2.4. TechCheck

The technical checks daemon.

This daemon implements operations for performing technical tests on name server sets.

The tests are either launched periodically and a report is sent to the corresponding technical contact of the nsset by email, or they are requested by registrars and the reports are included in EPP poll messages.

The technical tests are scaled by severity and the tests of higher severity can be performed only if the tests of lower severity were successful.

Both planned checks and results are stored in the database.