2. Configuration

This chapter contains an overview of executable files that are a part of the FRED and the location and names of their default configuration files.

There are also some configurable database values, which you should consider revising.

Note

The descriptions of configurable values are contained in the default configuration files.

2.1. Security notice

Important

Always adapt access control information (especially user names and passwords) for the use on production!

2.2. Executables

The overview of executable files should give you an idea about the names of the FRED components that actually can be launched, and about the settings that must be configured on the system level. The mentions of the default configuration files are there to guide you to locations where these settings are made.

The default configuration files are located in @PREFIX@/etc/fred.

2.2.1. CORBA servers

The CORBA servers are located in a system-binaries directory (@PREFIX@/sbin).

Systemd startup scripts are included with FRED packages (e.g. /lib/systemd/system/fred-rifd.service). A startup command is introduced with ExecStart= in the scripts.

2.2.1.1. C++ daemons

These daemons provide operations via the IDL interface implemented in C++.

In the default deployment scheme, all daemons run on a single machine and they share an all-in-one configuration file named server.conf.

In the deployment scheme adopted in the CZ.NIC, separate configuration files are used for each daemon, therefore they are listed with the daemons below and marked [CZ.NIC].

Note

If you decide to deploy servers on several machines, you must specify the common configuration settings on each machine, namely the sections: [database], [nameservice], [log] and [registry], plus the daemon-specific settings for each daemon that runs on that machine.

  • fred-adifd – administration interface daemon – operations for administration (WebAdmin)

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-adifd.conf

  • fred-rifd – registrar interface daemon – operations for the EPP-protocol Apache module (mod-eppd)

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-rifd.conf

  • fred-pifd – public interface daemon – operations for Unix whois, web whois, RDAP and contact verification

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-pifd.conf

  • fred-rsifd – record statement interface daemon – operations for the provision of registry record statements

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-rsifd.conf

  • fred-akmd – automated keyset management daemon – operations for managing keysets automatically

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-akmd.conf

  • fred-accifd – accounting daemon – operations for payment pairing

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-accifd.conf

  • fred-msgd – messaging daemon – operations for sending SMS text messages and paper letters

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-msgd.conf

  • fred-logd – logging daemon (logger) – operations for the logging of user activity

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-logd.conf

  • fred-mifd – mojeID daemon (extension) – operations for the mojeID service

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-mifd.conf

  • fred-dbifd – domain browser daemon (extension) – operations for the Domain Browser web application

    • standalone configuration file [CZ.NIC]: /etc/fred/fred-dbifd.conf

Configuration parameters can also be passed as command-line arguments to the daemons, see <daemon> --help.

ORB parameters

Additionally, each daemon accepts ORB parameters which it hands over to its ORB.

Important

OmniORB minimum

You need to override the following omniORB settings when running FRED servers:

  • native character encoding – to encode/decode text data for transmission with UTF-8; this can be set on the command-line as <daemon> -ORBnativeCharCodeSet UTF-8 or in the ORB configuration file (possibly /etc/omniORB.cfg) as the nativeCharCodeSet variable,

  • endpoint address – to specify a port on which a server listens for CORBA calls; a unique port must be specified for each server; this must be set on the command-line, such as
    <daemon> -ORBendPoint giop:tcp::<port>.

To list all possible ORB parameters, run omniNames -help; see also omniORB configuration for a more detailed explanation of the ORB parameters.

2.2.1.2. Python daemon(s)

This daemon provides operations via the IDL interface implemented in Python.

In the default deployment scheme, the daemon loads all modules and runs in a single process (on a single machine) and all modules share an all-in-one configuration file named pyfred.conf.

In the deployment scheme adopted in the CZ.NIC, separate configuration files are used for each daemon, therefore they are listed with the daemons below and marked [CZ.NIC].

  • fred-pyfred – a framework that integrates several Python CORBA servers as modules:

    • genzone – operations for generating zone files,

      • standalone configuration file [CZ.NIC]: /etc/fred/pyfred-genzone.conf

    • mailer – operations for email assembly and dispatch,

      • standalone configuration file [CZ.NIC]: /etc/fred/pyfred-mailer.conf

    • filemanager – operations for managing files (mostly email attachments),

      • standalone configuration file [CZ.NIC]: /etc/fred/pyfred-filemanager.conf

    • techcheck – operations for running technical checks of name servers.

      • standalone configuration file [CZ.NIC]: /etc/fred/pyfred-techcheck.conf

2.2.2. Web administration server

  • fred-webadmin – server for the web administration of the FRED

Default config.file: @PREFIX@/etc/fred/webadmin_cfg.py

2.2.3. CLI utilities

Located in @PREFIX@/bin

  • cdnskey-scanner – CDNSKEY resource record mining utility (no config. file)

  • filemanager_client – Inserting a new file into the system (uses pyfred.conf)

  • fred-akm – Automated keyset management client (/etc/fred/fred-akm.conf)

  • fred-admin – Automated administration tasks (server.conf), especially those performed periodically, see also Periodic tasks

  • fred-client – Tool for registrars (/etc/fred/fred-client.conf)

  • fred-doc2pdf – Rendering the standard input (RML) into the PDF (/etc/fred/fred-doc2pdf.conf)

  • genzone_client – Generating zones (/etc/fred/genzone.conf)

  • mailer_client – Sending email (pyfred.conf)

  • simple_stats.py – Statistics (???)

  • techcheck_client – Launching technical checks (pyfred.conf)

  • transproc – Processing the transcripts of bank transactions (/etc/fred/transproc.conf)

2.2.3.1. Database management

  • fred-dbmanager (in @PREFIX@/sbin) – Basic database management script (no config. file)

  • create_parts and drop_parts (in @PREFIX@/bin) – Logger partitions maintenance scripts (example config in @PREFIX@/share/doc/fred-logger-maintenance/examples/logger.conf.example)

2.2.4. Apache modules

Configuration of FRED Apache modules and FRED sites can be found in Apache configuration subdirectories, usually under /etc/apache2/.

2.2.5. Django PAIN

Configuration of this Django utility is in the settings.py and described within project source.

2.3. Database tables

Some parts of the Registry behaviour can be configured by modifying or adding values in certain database tables.

Important

If you reconfigure the system using database tables, remember to examine changes in the database component before upgrading the FRED!

Sometimes we need to edit the database configuration for ourselves and these changes are added to a database upgrade script, which would overwrite your settings. Therefore you should either backup your current database tables to recover your settings after the upgrade, or adapt the upgrade script directly, so that you don’t lose your settings.

2.3.1. Life cycle parameters

A part of database configuration relates to the life cycle of registrable objects. It states e.g. when to send a notification to a contact before their domain expires or for how long a domain is protected before it can be re-registered.

There is a table dedicated to this kind of configuration called enum_parameters. The parameters in this table can be changed using the following command:

fred-admin --enum_parameter_change --parameter_name=<name> --parameter_value=<value>

Parameters that affect all types of registrable objects:

  • regular_day_procedure_period – an hour in the day when the regular procedure is run (24-hour system, 0 means 00:00, 14 means 14:00 etc.), default: 0

  • regular_day_procedure_zone – time zone for periodic tasks, default: Europe/Prague

    Important

    It is necessary to adapt the time zone to your area!

    The format of a value is the standardized PostgreSQL name of a time zone which can be found either in the Postgres table pg_timezone_names (the name column) or in this Wikipedia list (the TZ column).

  • roid_suffix – suffix used in repository object identifiers (see also ROID), which are assigned to registrable objects by the Registry, default: EPP

Parameters that affect only domains:

  • expiration_dns_protection_period – for how many days after expiration is a domain still generated in a zone, integer, default: 30

  • expiration_letter_warning_period – how many days after expiration is the owner warned about domain deletion, integer, default: 34

  • expiration_notify_period – how many days before a domain expiration is the owner notified about the expiration, negative integer, default: -30

  • expiration_registration_protection_period – for how many days after expiration is a domain protected before it is deleted and can be re-registered, integer, default: 61

  • outzone_unguarded_email_warning_period – for how many days after expiration may customer support enter additional email addresses in Daphne before the system starts sending warnings about domain exclusion from the zone to them, integer, default: 25

  • regular_day_outzone_procedure_period – an hour in the day when the outzone procedure is run (24-hour system, 0 means 00:00, 14 means 14:00 etc.), default: 14

  • validation_notify1_period ENUM domains – how many days before validation expiry the owner should be notified for the first time, negative integer, default: -30

  • validation_notify2_period ENUM domains – how many days before validation expiry the owner should be notified for the second time, negative integer, default: -15

Important

The system does not verify that the time intervals follow one another correctly. Double check with the life cycle!

Parameters that affect only non-domain objects:

  • handle_registration_protection_period – for how many months is a handle (of a contact, nsset or keyset) protected before it can be re-registered, default: 2

  • object_registration_protection_period – how many months an object (nsset, keyset) must be unedited and unassigned to be considered idle and marked for deletion, default: 6

2.3.2. Domain name format validation

The implemented rules for domain-name formatting are enumerated in the table enum_domain_name_validation_checker. The Registry operator can turn them on or off by adding or removing an association in the table zone_domain_name_validation_checker_map, such as:

Example of SQL insertion of format association with a zone
INSERT INTO zone_domain_name_validation_checker_map (checker_id, zone_id)
   values (2, 1);

where checker_id is an id of a formatting rule and zone_id is an id of a zone.

For a domain name to be valid, it must comply with all rules assigned to its zone.

Further restrictions on domain names may be required by the domain blacklist.

2.3.3. Handle format validation

The format of handles can be prescribed for non-domain object types—contacts, nssets and keysets—with settings in two database tables:

  • regex_handle_validation_checker – contains all patterns but does not specify which of them have to be matched,

  • regex_object_type_handle_validation_checker_map – determines which patterns will have to be matched for which object types.

To configure a new allowed pattern, connect to the database and insert a new regular expression into the regex_handle_validation_checker table, such as:

Example of SQL insertion of a handle format pattern
INSERT INTO regex_handle_validation_checker (regex, description)
   values ('^[Cc]', 'must start with the letter c or C');

Now, associate the new pattern to object types using the map table, such as:

Example of SQL insertion of format association with an object type
INSERT INTO regex_object_type_handle_validation_checker_map (type_id, checker_id)
   values (1, 3);

where checker_id is the id of our new pattern and type_id is the id of the desired object type from the enum_object_type table, in our case contact. A regex pattern can be associated with several object types. In our example, the pattern will make sure that contact handles start with the letter c or C.

In case an invalid regular expression was set up in the database, then the corresponding check_object, create_object and info_object operations will respond with the 2400 Command failed result code.

For a handle to be valid, it must match all patterns assigned to its object type.

If a handle is not valid according to db settings, the EPP client receives a response with the 2005 Parameter value syntax error result code.

Important

It may be necessary to adapt the XML schemas of EPP as well. Handle formats are defined in the fredcom-1.2.1.xsd file with the following simple types:

  • objIDCreateType – handles of objects being created – must correspond with the current db setting,

  • objIDType – handles of objects occurring elsewhere – must correspond with the current setting and allow all historical db settings so that handles conforming previous formatting rules can still be used,

  • objIDChgType – same as objIDType but allowing an empty string.

If a handle is not valid according to XML schemas, the EPP client receives a response with the 2001 Command syntax error result code due to failed XML validation.

2.3.4. Restricting domain names

A forbidden pattern for domain names can be configured by inserting a new pattern with a validity period (i.e. when the pattern is applicable) into the domain_blacklist table, such as:

Example of SQL insertion in domain blacklist (minimum query)
INSERT INTO domain_blacklist (regexp, valid_from, reason)
   VALUES ('^..\.cz$', '2017-07-01 07:00:00', 'forbid 2-char length in cz zone');

The syntax for these patterns is POSIX regular expressions and pattern matching is case insensitive (the ~* operator).

Temporal validity (valid_fromvalid_to) must be specified for each pattern, however the valid_to datetime can be left empty and then the validity is unbounded (the pattern is applicable forever).

The patterns can be used in various ways:

  • to list forbidden words, for example: pattern good|bad|ugly will refuse registrations of any domain names that contain one of the words “good”, “bad” or “ugly”,

  • to force length of domain names, for example: pattern ^..\.cz$ will refuse registrations of 2-character domain names in the cz TLD,

  • or any other that regular expressions can express.

For a domain name to be valid, it must not match any pattern that is currently applicable.

2.3.5. Adding a registrar memo to annual reminders

The email template for annual reminders of contacts allows to include a memo from the designated registrar in the email and a custom email address to which the contact can reply.

The Registry operator may insert this information into the reminder_registrar_parameter table:

  • registrar_id – identify the registrar,

  • template_memo – enter the memo in plain text; use the ~@~ sequence to separate language variants (local language first, English second); whitespace is preserved,

  • reply_to – enter an email address for the Reply-To header.

This must be done manually with an SQL insert.

2.4. Contact information disclosure

Disclosure of contact details must be configured in both the back end (fred-rifd) and the front end (Apache module mod-eppd).

mod-eppd

EPPdataCollectionPolicyAccess – sets the general approach and implies the logic for contact preference requests (create/update) and display (info):

  • all – the general approach is “Registry shows information”, registrars shall use flag='0' to signal contact preference to hide listed attributes,

  • none – the general approach is “Registry hides information”, registrars shall use flag='1' to signal contact preference to show listed attributes.

EPPcontactOperationDiscloseflags lists names of the elements that can be used in the disclose element of the corresponding operation.

Important

The *Discloseflags lists must allow the same elements that are allowed in the XSD schemas!

fred-rifd

contact_data_filter – a method of enforcing server’s disclosure policy:

  • set_unused_discloseflags – sets disclosure of attributes, for which there was no preference, to the configured defaults unconditionally

  • cznic_specific – controls conditional disclosure of address (see Hiding address), sets other disclosure settings, for which there was no preference, to the configured defaults unconditionally

The Registry operator may develop and assign custom methods.

Default disclosure settings default_disclose* are listed for create and update operations separately. If the attribute’s disclosure cannot be set in an operation, it must have a default setting listed here.

2.4.1. Example configurations

Pre-GDPR configuration with the CZ-specific filter (as in version 2.36)

mod-eppd
EPPdataCollectionPolicyAccess all
EPPcontactCreateDiscloseflags telephone fax email vat ident notifyemail
EPPcontactUpdateDiscloseflags address telephone fax email vat ident notifyemail
EPPcontactInfoDiscloseflags address telephone fax email vat ident notifyemail
fred-rifd
[rifd]
contact_data_filter = cznic_specific
[rifd::cznic_specific::create_contact]
default_disclosename = show
default_discloseorganization = show
default_discloseaddress = show
[rifd::cznic_specific::update_contact]
default_disclosename = show
default_discloseorganization = show

GDPR-compliant configuration with the CZ-specific filter (as in version 2.37)

mod-eppd
EPPdataCollectionPolicyAccess none
EPPcontactCreateDiscloseflags telephone fax email vat ident notifyemail
EPPcontactUpdateDiscloseflags address telephone fax email vat ident notifyemail
EPPcontactInfoDiscloseflags address telephone fax email vat ident notifyemail
fred-rifd
[rifd]
contact_data_filter = cznic_specific
[rifd::cznic_specific::create_contact]
default_disclosename = show
default_discloseorganization = show
default_discloseaddress = show
[rifd::cznic_specific::update_contact]
default_disclosename = show
default_discloseorganization = show

GDPR-compliant configuration without the CZ-specific filter

mod-eppd
EPPdataCollectionPolicyAccess none
EPPcontactCreateDiscloseflags telephone fax email vat ident notifyemail
EPPcontactUpdateDiscloseflags address telephone fax email vat ident notifyemail
EPPcontactInfoDiscloseflags address telephone fax email vat ident notifyemail
fred-rifd
[rifd]
contact_data_filter = set_unused_discloseflags
[rifd::set_unused_discloseflags::create_contact]
default_disclosename = show
default_discloseorganization = show
default_discloseaddress = show
[rifd::set_unused_discloseflags::update_contact]
default_disclosename = show
default_discloseorganization = show