1. General features¶
The main goal of the FRED is to administer authoritative information on domains, domain ownership and owners which is then distributed via the DNS (zone file) as well as served in response to public queries (whois). To accomplish this, the system allows to input the relevant information into its database through the registration process and comprises the means to administrate existing data.
The relevant information obtained by the registration process is grouped into so-called registrable objects.
To ensure the authenticity of the data, only authorized entities (registrars) can perform registrations and modify existing data in the Registry.
1.1. Registry–Registrar–Registrant model¶
The most important feature of the FRED is its database structured according to the Registry–Registrar–Registrant model. Registrars communicate with the Registry on behalf of registrants (domain owners).
Strong ownership model ensures that each registrable object in the database is owned by one registrar (called the “designated registrar”) and no other registrar [1] may modify it.
A registrant is allowed to change the designated registrar of an object by means of the transfer process.
The registrable objects are the following:
domain (regular or ENUM),
contact (in roles of domain owners, administrative contacts or technical contacts),
nsset (a group of name servers), and
keyset (a group of DNSSEC keys).
All registration requests are resolved immediately if the requested object is free.
The history of all changes regarding any object is accessible through an administration interface.
Objects can be shared, i.e. one contact can be used multiple times with domains, nssets or keysets. Similarly, one nsset or keyset can be linked to several domains.
1.2. Zone file generation¶
The FRED can be used to automate the zone-file generation process.
It is possible to manage multiple different zones of any level. For each zone, the generator will create zone files with SOA, NS, A, AAAA, and DS records as specified in the database.
1.3. EPP protocol¶
The registrars communicate with the Registry using the EPP protocol (RFC 5730) with extensions for individual objects. The extensions are slightly modified versions of the standard specifications for domains (RFC 5731) and contacts (RFC 5733).
The FRED contains unique extensions for nssets and keysets.
Beside the standard commands, there are further auxiliary functions, such as information about credit or bulk list operations.
EPP communication is secured by the standard login-and-password authentication together with the verification of a client SSL certificate.
To ease EPP communication, the FRED distribution contains a Python client library and a command-line client application.
1.4. Whois & RDAP¶
There are two versions of the WHOIS service.
The first version is a classical Unix WHOIS service as specified in RFC 1834. This service features recursive results for all associated objects and inverse queries.
The second version is a web WHOIS application. The web version supports hyperlinked and more detailed results. There is even a possibility to enable CAPTCHA protection against robots.
Both versions contain the security feature of hiding personal information of contacts.
Additionally, the FRED contains a prototype implementation of the RDAP protocol which allows client applications to obtain results in a more recent, machine-readable format (JSON).
1.5. GDPR compliance¶
GDPR is an EU regulation, which must be complied with, once the Registry operator deals with personal information of natural persons that are based in the EU.
The FRED has adapted its policies to hide most of the personal information and it does not share personal information with third-party entities (especially the public via FRED’s public interfaces) without explicit consent from end users (natural persons), with the exception of name, organization, and, if a contact is not verified, address.
The consent for disclosure of some contact information can be given as disclosure preference flags through the EPP. (See Policies & rules of disclosure for details.)
End users (natural persons) may place a public request any time to find out what personal information is stored in the Registry about them.
1.6. Notifications¶
The registrars and registrants are notified about important situations in the Registry.
The registrars are notified using the EPP mechanism of poll messages.
The registrants are notified using email or printed letters. All mail is constructed from predefined configurable templates. All outgoing mail is stored in a searchable archive. The email messages produced by the system comply with the RFC 2387 standard.
Notification conditions include domain expiration, domain disabling, domain unregistration or any object modification via EPP.
All time periods for domain disabling and unregistration are configurable.
1.7. Technical checks¶
Technical checks are informative tests performed on registered name servers to diagnose potential domain delegation problems.
The technical checks are invoked regularly in a configurable interval and their results are sent using email to contacts associated with name servers.
They can also be invoked on demand by a registrar using the EPP interface. In this case, results are sent back to the registrar via the EPP poll mechanism.
The tests include existence and reachability of name servers, presence of delegated domains on name servers or the authoritative flag of DNS answers for such domains.
1.8. Multi-language support & IDN¶
The FRED is UTF8-aware within all its subsystems. Supported languages are very easily extensible by means of a standard process of language-catalogues manipulation.
Internationalized Domain Names (IDN) are supported in the system core as a configuration option that can be turned on, so that domains in UTF-8 can be registered and displayed, however there are limitations:
there is no way of restricting the character set,
there are no bindings of IDN and non-IDN domains.
1.9. DNSSEC support¶
The DNS Security Extensions are supported by the FRED out-of-the-box.
The software supports creating, storing and manipulating DNSSEC keys in the Registry while leaving the zone-signing process to external tools. It gives the Registry operator the flexibility to choose any suitable DNSSEC tools to meet the desired security and performance.
1.10. Invoicing and banking CZ-specific¶
The FRED implements both the prepaid-invoicing and postpaid-invoicing model which can be selected for each billed operation.
Payments collected by an external system can be paired with FRED using the Accounting interface. When a payment is paired, an advance invoice is issued and credit is extended to the matching registrar by a corresponding amount. The credit is then decreased upon each domain registration or renewal. The price of registration and renewal is configurable per zone.
At some point in time, it’s possible to create an accounting invoice for a particular registrar containing a list of all its registrations and renewals and the total amount of money subtracted from the credit.
Note
Work with the billing subsystem may be tricky because it is tightly tied to the context of the financial and commercial laws of the Czech Republic (esp. the VAT handling and invoice essentials).
Therefore it may not be fully (or at all) suitable for your environment.
More about billing in FRED.
There is also a new concept of billing being developed, see The Future of Payments & Invoices.
1.11. ENUM¶
A standard protocol for electronic mapping of phone numbers to domains which allows to associate an IP phone with a classic phone number and store these phone number domains in DNS.
In comparison to regular domains, ENUM domains have an additional attribute, the validation expiration date, as a means of verification of number ownership.
ENUM is defined in RFC 3761.
1.12. Contact verification CZ-specific¶
There is a method to minimize occurrence of fake contact data by performing checks on random contacts.
The chosen contact undergoes an automatic check, first, which verifies the formal syntax of the data and tries to find the address in the street register.
In case of problems, the contact is handed over for a manual check by Registry staff that tries to communicate with the contact.
If there is no response, the contact and its domains are deleted.
1.13. Contact merger¶
There is a method to minimize duplicate contact records in the Registry automatically. However, only contacts which are identical and mergeable by strict rules, are merged.
1.14. Object locking¶
Object locking (also known as Registry lock) stands for enhanced security settings of registrable objects that a registrant can request from the Registry directly.
To submit a request to lock an object, a registrant uses the Public Request website form. However, an extra electronically signed email or an officially signed letter must follow to confirm that the registrant is authorized for such request.
The request is processed manually by Registry staff after verifying the authorization.
To unlock an object, the process is the same.
1.15. Domain name & handle format validation¶
The FRED implements several standard rules for domain name format validation:
forbid consecutive hyphens,
forbid empty domain name,
enforce RFC 1035 preferred syntax,
enforce single digit labels (for ENUM domains),
forbid IDN punycode encoding.
The rules can be configured per zone.
If the Registry operator requires additional restrictions, they can be implemented by providing forbidden keywords or patterns in the domain blacklist. The restrictions can be configured for any period of time given by a starting and ending date of validity.
The Registry operator can also configure the format of handles of contacts, nssets and keysets, and they can do it for each object type separately.
1.16. Automated keyset management¶
In order to simplify introduction and rotation of DNSSEC keys, the FRED implements two standards devised for key management automation: RFC 7344 and RFC 8078. By polling domains’ name servers for CDNSKEY records, the Registry can easily link DNSSEC-enabled domains into the global chain of trust and respond to key updates flexibly. This method does not require registrars to be involved in any way because the publishing of the CDNSKEY records relies on DNS operators.
1.17. Generation of verified record statements¶
A record statement is a generated confirmation of a state of a registrable object in a certain moment (current or historical). The statement can be used as legal evidence for the police or in court. It is a PDF document signed with an official digital signature.
If a statement is requested through the public interface (web whois), some contact information will be hidden according to disclosure settings of that contact. A statement can be also issued privately through the administration interface (Daphne) or Domain Browser and in those cases all contact information is disclosed in the statement.
1.18. Audit log¶
FRED creates an audit trail of activity of all user services (EPP, WHOIS, RDAP, WebAdmin). Log records include user names and IP addresses, from which service requests come.
An audit trail is required as the basis for information security audits and it can also serve as a supporting mechanism for access control, prevention of criminal activity, evidence in a trial, or just an auxiliary tool in problem solving.
The specialized schema of the log database allows the records to be maintained month by month.
