2.3. 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

Important

The fred-rsifd daemon has been removed in FRED 2.48.0 and replaced by the fred-statementor library.

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.

Important

The fred-msgd daemon has been replaced by messenger and its dependent services in FRED 2.48.0.

The fred-msgd daemon has been replaced by following services:

  • Sending the messages is replaced by fred-messenger.

  • File creation (PDF, XML, CSV) is replaced by django-secretary. The doc2pdf package is not used anymore in any part of messaging process.

  • Communication with fred-fileman (e.g. storing attachments) is now via library, file-client is not used anymore.

Generating specific messages is handled by these clients:

  • fred-notify-contact-data-reminder – runs daily, sends annual message to contacts.

  • fred-notify-object-state-changes – runs after regular object procedure (twice a day), sends notification about changes in object states.

  • fred-notify-object-events – runs every 5 minutes, sends notification about used commands (create, update, delete, renew, transfer), typically done via EPP.

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. Clients, see the Diagram of FRED components).

Important

The fred-logd daemon has been replaced in FRED 2.48.0 by the binaries fred-logger-services and fred-logger-corba. Both are independent services that only use the same core library librogger. Fred-logger-services implements gRPC interface, fred-logger-corba implements CORBA interface and is intended for old CORBA-based clients.

2.3.1.9. fred-logger-services

This deamon replaces the fred-logd deamon, but the fred-logger-services's clients are gRPC apps, not CORBA apps (a different communication protocol is used). We are developing a wrapper from Corba to gRPC for CORBA clients that will simplify transition of clients to only one logger service implementation.

2.3.1.10. fred-mifd

The daemon of the MojeID extension.

This daemon implements operations for the MojeID extension.

2.3.1.11. fred-dbifd

The daemon of the Domain Browser extension.

This daemon implements operations for the Domain Browser extension.

2.3.1.12. fred-registry-services

This deamon provides features via gRPC interface for getting information about objects in registry, for searching among registry entries, and, in the future, also for managing (creating, deleting, updating) objects in registry. It works directly with the FRED database.

2.3.2. fred-messenger

FRED services for sending, generation and archivation of documents. You can see its dependencies on a simplified diagram:

Diagram of FRED messaging components

2.3.3. django-secretary

Service for generating documents and template management.

2.3.4. fred-fileman

Service for file management.

2.3.5. 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.5.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.5.2. Mailer

Important

Since FRED 2.48.0 the mailer daemon is deprecated and is no longer used. It has been replaced by messenger and its dependent services.

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.5.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.5.4. TechCheck

Important

Since FRED 2.48.0 the TechCheck daemon is deprecated and is no longer used. It has been replaced by messenger and its dependent services.

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.