Basics of registry operations

Registry Operations

This chapter walks you through the day-to-day operation of a FRED-based registry – from exploring a pre-configured demo environment, through hands-on work with registry objects, to the administrative and periodic tasks that keep the registry running.

The demo environment

FRED ships with a demo installation that lets you explore a fully functional registry without having to configure anything from scratch. The demo is the recommended starting point for new administrators.

You can download the demo image and run it on a local virtual machine from https://fred-demo.nic.cz/.

For comprehensive setup instructions, SSH connection details, and service access information, see the FRED demo. Once your environment is running, continue below.

Hands-on with registry objects

Registry objects – domains, contacts, nssets and keysets – are the core data that FRED manages. This section shows how to create and inspect them using each of the available interfaces.

Creating and managing objects via EPP

Registrars interact with FRED exclusively through the EPP interface on TCP port 700 (TLS). The full command reference is in the EPP Reference Manual.

A minimal session follows the pattern:

  1. Connect and authenticate – open a TLS connection, send a login command with your handle and password.

  2. Operate – send create, info, update, delete or renew commands for the object types you are accredited for.

  3. Log out – send logout to close the session.

Tip

For interactive testing during the demo, use the eppic client that is bundled with FRED:

fred@localhost:~$ eppic

The default configuration connects to the demo registry with the REG-DEMO credentials. This can be changed by editing the /etc/eppic/eppic.conf file or by passing command-line arguments.

More information about eppic, including installation and configuration, is available in EPPIC repository.

FRED-eppic examples

create-contact --id=CID-DEMO1 --postal-info.name='Jan Novak' --postal-info.addr.street-1='Milešovská 1136/5' --postal-info.addr.city='Praha' \
 --postal-info.addr.pc='130 00' --postal-info.addr.cc='CZ' --email='jan.novak@example.cz'

create-domain --name=example-domain.demo --registrant=CID-DEMO1

create-nsset --id=NSID-DEMO1 --nss-1.name=ns1.test.demo --tech-1=CID-DEMO1

create-keyset --id=KSID-DEMO1 --dnskeys-1.flags=257 --dnskeys-1.protocol=3 --dnskeys-1.alg=5 --dnskeys-1.pub-key=kfdajdfa --tech-1=CID-DEMO1

update-domain --name=example-domain.demo --nsset=NSID-DEMO1 --keyset=KSID-DEMO1

info-domain --name=example-domain.demo

Tip

To view all commands and their arguments, or details about a specific command, run:

REG-DEMO@localhost > help

REG-DEMO@localhost > help --command=create-domain

For a full description of a typical registrar session, see the EPP client workflow concept.

Viewing objects through WHOIS and RDAP

FRED exposes every non-restricted registry object through three read-only public interfaces.

Unix WHOIS

A plain-text query/response protocol, is useful for scripting and quick lookups.

whois -h localhost example-domain.demo

WebWHOIS

A browser-based interface that renders the same data in HTML. You can access it at the location provided in fred-demo services list or example below.

https://localhost:8444/domain/example-domain.demo/

RDAP (Registration Data Access Protocol)

A new protocol that supersedes WHOIS for machine-readable lookups; standard tools like curl or wget can be used to query it. The output is in JSON format and includes metadata about the objects, such as their state, history, linked objects, etc.

FRED supports domain, nameserver, entity, nsset and keyset queries:

curl https://localhost:8446/domain/example-domain.demo --insecure

curl https://localhost:8446/entity/CID-DEMO1 --insecure

curl https://localhost:8446/fred_nsset/NSID-DEMO1 --insecure

curl https://localhost:8446/fred_keyset/KSID-DEMO1 --insecure

curl https://localhost:8446/entity/REG-DEMO --insecure

Note

In case of the demo environment, the --insecure flag is required to bypass TLS certificate verification, since the demo uses self-signed certificates.

Full endpoint documentation: RDAP API Reference.

Administering objects in FERDA

FERDA is the web-based administration interface used by registry staff running as a Docker container. It connects to FRED’s administration interface (ADIF) and provides the following modules:

  • Registry – search and inspect all registry objects, their linked objects and history.

    • Registrars – view and edit registrar details, manage their EPP and zone access.

    • Notifications – view and manage additional notifications about expiration and deletion of domains.

  • Messages – view all messages generated by the registry.

  • Reports – generate custom reports on registry data and activity.

  • Logger – view the audit log of all operations performed from multiple services

  • Requests – approve or reject requests from the public interface, such as block/unblock requests or authinfo requests.

Note

All write operations performed in FERDA are recorded in the FRED audit log database and can be reviewed in the Logger module of FERDA.

For more reference see FERDA webadmin features.

Zone file generation

FRED periodically reads the registry data directly from the database and generates a zone file that contains all domains that are not marked with the serverOutzoneManual, unguarded or nssetMissing flag.

Running the generator

sudo /usr/sbin/fred-zone-generator --config /etc/fred/fred-zone-generator.conf

The output path and file name are configured in the generator’s configuration file (/etc/fred/fred-zone-generator.conf).

Displaying the zone file

fred@fred-demo:~$ less db.demo

$TTL 18000 ;default TTL for all records in zone

demo.   IN      SOA     some.ns.test.demo.      hostmaster.domain.demo. (1780910078 900 300 604800 900)
        IN      NS      other.ns.test.demo.

test-domain.demo.       IN      NS      ns1.test-domain.demo.
test-domain.demo.       IN      NS      ns2.test-domain.demo.
ns1.test-domain.demo.   IN      A       111.222.111.222
ns2.test-domain.demo.   IN      A       222.111.222.111

Loading the zone into a DNS server

Zone file generation is where FRED’s responsibility ends and you have to publish the generated file to the DNS server, such as BIND or KNOT DNS.

For more reference see Zone generation.

Registry management

The following section shows an examples of regular tasks during the registry initialization and administration.

Creating a new zone

In order to manage domains in certain zone you must first create it.

sudo fred-admin --zone_add \
    --zone_fqdn=example \
    --ex_period_min=12 \
    --ex_period_max=120 \
    --ttl=18000 \
    --hostmaster=hostmaster@mail.example \
    --ns_fqdn=ns.nic.example

sudo fred-admin --zone_ns_add \
    --zone_fqdn=example \
    --ns_fqdn=ns.nic.example

Note

Only one price can be active for a given operation and zone at one time.

Important

Choose --ex_period_min carefully: it defines the smallest unit of registration/renewal periods (e.g. 12 means whole years only).

Zone parameters cannot be changed after creation except by direct database intervention.

Note

It is also possible to add a second level domain as a zone, for example second.example.

For more reference see Preparing a zone.

Creating a registrar

sudo fred-admin --registrar_add \
    --handle=REG-EXAMPLE --reg_name="Example Registrar Ltd." \
    --organization="Example Registrar Ltd." \
    --dic="12345678" \
    --street1="Milešovská 1136/5" \
    --city="Praha" \
    --country=CZ \
    --email=support@example-registrar.cz \
    --url=http://www.example-registrar.cz

Note

Registrar details (name, address, contact information) can be edited later through the FERDA web interface.

Important

Registrars created with the --system flag are designated as system registrars. This applies to the demo’s REG-SYSTEM and REG-DEMO, any operations performed through system registrars are never billed and bypass the billing subsystem entirely. This ensures that internal registry operations, automated background processes, and administrative actions remain unaffected by credit limits or pricing rules.

Managing registrar access

Each registrar must have a client certificate and a password assigned before they can connect via EPP.

Assigning credentials

openssl x509 -noout -fingerprint -md5 \
    -in /usr/share/fred-eppic/ssl/test-cert.pem | cut -d= -f2

Note

If you are using a different certificate than the default one for REG-DEMO registrar, make sure to adjust the path accordingly.

sudo fred-admin --registrar_acl_add \
    --handle=REG-EXAMPLE \
    --certificate="6A:AC:49:24:F8:32:1E:B7:A1:83:B5:D4:CB:74:29:98" \
    --password=password

Warning

Certificate fingerprint must be written in uppercase.

Granting zone access

A registrar must be explicitly permitted to manage objects in given zone:

sudo fred-admin --registrar_add_zone \
    --zone_fqdn=example \
    --handle=REG-EXAMPLE \
    --from_date="2026-01-01"

For more reference about creating registrar and adding their credentials, see Preparing registrars.

Blocking and unblocking a registrar

Registry administrators can suspend a registrar’s EPP access at any time via the fred-admin CLI.

Preparing billing

The billing subsystem tracks credit, charges registrars for EPP operations and generates invoices. It is disabled by default.

To enable charging, set the following in configuration files /etc/fred/server.conf ([rifd] section) and /etc/fred/fred-rifd.conf:

epp_operations_charging = true

and restart the services:

sudo systemctl restart 'fred-*'

When billing is enabled, perform these initialization steps:

1. Create a price list

Prices are defined per operation, per zone, with optional validity periods:

sudo fred-admin --price_add --operation='CreateDomain' \
    --zone_fqdn=example \
    --valid_from='2026-01-01 00:00:00' \
    --operation_price=0 --period=1

sudo fred-admin --price_add --operation='RenewDomain' \
    --zone_fqdn=example \
    --valid_from='2026-01-01 00:00:00' \
    --operation_price=160 --period=1

Note

CreateDomain is intentionally set to zero, because the first domain renewal is made upon domain registration, that means that a registration of a new domain is in fact billed as 2 operations: CreateDomain + RenewDomain whereas a renewal of an existing domain is billed only as one operation RenewDomain.

2. Set up invoice numbering

sudo fred-admin --add_invoice_number_prefix \
    --prefix=26 --zone_fqdn=example \
    --invoice_type_name=advance

sudo fred-admin --add_invoice_number_prefix \
    --prefix=25 --zone_fqdn=example \
    --invoice_type_name=account

sudo fred-admin --create_invoice_prefixes --for_current_year

3. Assign initial credit to registrars

psql --expanded -U fred -c "SELECT id as registrar_id FROM registrar WHERE handle = 'REG-EXAMPLE';"

psql --expanded -U fred -c "SELECT id as zone_id FROM zone WHERE fqdn = 'example';"

sudo fred-admin --invoice_credit \
    --zone_id=<zone-id> --registrar_id=<registrar-id> \
    --price=15000

For the complete billing reference, including VAT configuration, see Preparing billing.

Object states

Every registrable object (domain, contact, nsset, keyset) carries a set of flags that together form its current state. States determine which operations are allowed for the object and whether it appears in the DNS zone.

Flags fall into two categories:

Automatic flags

Set and cleared by FRED based on time and other conditions, for example:

  • expirationWarning / expired / unguarded – domain registration expiry flow

  • deleteCandidate – object scheduled for removal

  • outzone – domain excluded from the zone file

Manual flags (prohibitions)

Set by the registrant (user locks) or by the registry administrator (administrative blocks), for example:

  • serverUpdateProhibited – prevents EPP updates by the registrar

  • serverDeleteProhibited – prevents deletion

  • serverTransferProhibited – prevents transfer to another registrar

  • serverInzoneManual – explicitly allows generation to the zone

  • serverOutzoneManual – prevents domain to be generated to zone

  • serverBlocked – prevents public requests for object’s update and transfer

Object states can be inspected via WHOIS, RDAP, WebWHOIS and FERDA.

See also

Life cycle of registrable objects – full state diagrams, transition rules and prohibitions for each object type.

Periodic tasks

In the demo image, no automatic tasks are configured. You have to either configure them or run each task whenever you need to.

Several registry operations should be scheduled to run automatically. The table below lists the most important ones; all tasks are invoked automatically via cron.

Task

Typical schedule

Purpose

fred-zone-generator

every 30 min

Generate a fresh zone file for each configured zone.

fred-admin --object_regular_procedure

00:00 and 12:00

Update object states, send expiry notifications and delete objects that have reached deleteCandidate.

fred-notify-object-state-changes

immediately after above

Dispatch notifications about state changes (required since FRED 2.48.0).

fred-admin --poll_create_request_fee_messages

daily (night)

Generate EPP poll messages about request-quota usage.

fred-notify-contact-data-reminder

daily

Send annual reminders to contacts to verify their data.

fred-admin --process_public_requests

every 5 min

Process requests from the public interface, such as block/unblock requests or authinfo requests.

Important

The object_regular_procedure job is critical for registry correctness. If it does not run, object states will not advance and expired domains will not be deleted on schedule.

For the complete cron configuration and all available options, see Periodic tasks.

Note

If you are running the demo environment, periodic tasks are not set up by default. You can run them manually as needed, for example:

sudo fred-admin --object_regular_procedure